Как нанять сильного SRE: 5 качеств, которые я проверяю после 100+ собеседований

Почему SRE нанимать сложно

SRE-позиции закрывают месяцами. Это стык инженерии, эксплуатации и умения рассуждать о системах. Я провёл больше ста собеседований в трёх компаниях — и могу сказать, что стандартный процесс найма почти всегда проверяет не то.

Что я перестал проверять

Инструменты устаревают. Фундамент остаётся. Поэтому я выбрасываю из оценки:

• годы опыта с конкретным инструментом;
• сертификаты вроде CKA или AWS SA;
• заученные ответы про CAP-теорему;
• знание Terraform против Pulumi.

Сертификат говорит, что человек умеет готовиться к экзамену. Опыт с инструментом — что он видел его в бою. Но ни то, ни другое не предсказывает, как инженер поведёт себя, когда в три часа ночи падает прод.

Пять качеств, которые реально работают

1. Системная отладка

Каждому кандидату я даю один сценарий: «Пользователи пишут, что приложение тормозит. Твои действия?»

Плохой ответ — «Пойду проверю базу данных». Хороший — уточнить, что значит «тормозит»: какие эндпоинты, какие пользователи, с какого момента. Затем проверить золотые сигналы: latency, error rate, трафик, насыщенность. Сравнить с базой и сужать круг.

Сильные кандидаты мыслят системами, а не компонентами.

2. Умение работать в неопределённости

Инцидент — это всегда неполная картина. Падает, никто не знает почему, люди ждут. Я спрашиваю: «Расскажи о решении, которое ты принял при неполной информации». Слушаю, как человек ограничивал неизвестное, какие эвристики использовал, как сообщал о неопределённости и менял подход по ходу.

3. Письменная речь

SRE пишет постмортемы, runbook'и, дизайн-документы и статусы инцидентов. Если под давлением не можешь изложить мысль — будешь страдать. Я даю упражнение: написать обновление статуса для клиентов на три предложения. Хороший пример:

«Мы обнаружили проблему, которая затронула вход в систему примерно у 15% пользователей с 14:30 UTC. Команда нашла корневую причину и развернула фикс. Мы наблюдаем за подтверждением полного восстановления, ожидаем в течение 10 минут».

4. Настрой на автоматизацию

Спрашиваю: «Что ты автоматизировал последним и почему?». Важно не «что», а «почему». Идеальный ответ — про поиск повторяемой рутины, расчёт выгоды, выбор подходящего уровня автоматизации. И про то, когда автоматизировать не стоит.

5. Эмпатия

Это неожиданно для технической роли, но SRE — мост между разработкой, эксплуатацией и бизнесом. Эмпатия — это понимать, почему разработчик залил сомнительный PR (дедлайн), почему менеджер спрашивает «когда починим?» (он напуган, а не надоедает), и что джуниор, который уронил прод, уже чувствует себя ужасно.

Структура моего интервью

Процесс длинный, но предсказуемый. Четыре раунда, и каждому отведено своё окно.

• Раунд 1 — технический скрининг: проектируем мониторинг для платёжного сервиса, разбираем сценарий расследования задержек.
• Раунд 2 — симуляция инцидента: живой сценарий с фейковыми дашбордами, смотрим на системность мышления и коммуникацию.
• Раунд 3 — культура и коллаборация: разбор реального анонимизированного постмортема, конфликтный сценарий (команда разработки сопротивляется SLO).
• Раунд 4 — письменное упражнение: написать runbook и статус-апдейт.

Красные флаги

Обращаю внимание, когда кандидат:

• винит людей, а не системы;
• не может объяснить простыми словами;
• ни разу не говорит «я не знаю»;
• говорит только про инструменты, а не принципы;
• не интересуется разбором инцидентов.

Один из этих признаков — повод присмотреться. Два — почти всегда отказ.

Когда такой найм сработает

Подход годится для команд, которые уже поняли, что SRE — это про системы, а не про дежурства. Если ваша компания ищет «человека с кубером» и не планирует менять культуру, процесс будет выглядеть избыточным. Но тогда и результаты будут соответствующие.

Как применять это в своей команде

Не нужно ждать идеального профиля. Ищите людей с фундаментом и этими пятью качествами, а инструменты они доучат. Включайте в интервью живые сценарии и письменные задания — это дешевле, чем месяц онбординга не того человека.