Собеседование на SRE часто выглядит одинаково: белая доска, задачка на литкод, вопрос про балансировку нагрузки по заученному шаблону. Инженер, который провёл примерно триста таких интервью, называет это бессмысленным и задаёт совсем другие вопросы. Логика простая: SRE — это про поведение в момент, когда система уже горит, и проверить его можно только разговором о реальных случаях.
«Проведи меня через свой последний крупный инцидент»
Это тест на конкретику. Сильный инженер вспоминает графики, хронологию, момент, когда до него дошло, в чём дело, и что он сделал бы иначе. Он назовёт время до восстановления, долю упавших запросов, что показывали дашборды. Если ответ звучит как «ну, был сбой, мы его починили» — человека там, скорее всего, не было.
Готовиться стоит заранее: возьмите два своих худших дежурства и разложите каждое на таймлайн. Не «мы перезапустили сервис», а «в 02:14 упал p99, в 02:19 заметили, в 02:31 нашли рост ретраев, в 02:47 выкатили фикс». Детали и есть доказательство.
«Телефон звонит в три ночи. Опиши первые десять минут»
Здесь проверяют процессную дисциплину. Хороший ответ: подтвердить алерт, оценить влияние на пользователей, оповестить нужных людей, начать диагностику. Плохой — сразу лезть по SSH на первую попавшуюся машину и что-то там крутить.
Разница принципиальная. Первый подход не даёт утонуть в деталях, пока бизнес теряет деньги. Второй — классическая ловушка: три часа копания в логах одного инстанса, когда проблема была в конфиге балансировщика.
«Расскажи, как ты убил алерт»
Ключевое слово — «убил». Рассказ про добавленное правило не считается. Вопрос про то, понимает ли человек гигиену оповещений как отдельную дисциплину. Хороший пример: алерт срабатывал на пике трафика и каждый раз закрывался сам через десять минут — порог подняли или правило выкинули. Опытный дежурный держит список шумных правил и регулярно его чистит, потому что уставший от ложных срабатываний инженер перестаёт реагировать на настоящие.
«Чем SLI отличается от SLO?»
Проверка базы, причём без подвоха. SLI — это метрика, которую вы измеряете: доля успешных запросов, задержка. SLO — цель по этой метрике, договорённость о том, какой уровень считается нормальным. Кандидаты с солидным стажем путают эти понятия чаще, чем хотелось бы.
«Какой самый полезный инструмент ты написал для себя?»
Ответ должен быть маленьким, конкретным и скучным. Скрипт, который экономит пять минут в день и живёт в личном репозитории. Если в ответе звучит «внутренняя платформа» или «фреймворк для всего» — это мимо. Такие мелочи говорят о человеке больше, чем рассказ про архитектуру на миллион.
Чего в интервью быть не должно
«Разверни связный список на доске». SRE — не соревнование по программированию, и заучивание учебника по алгоритмам здесь ничего не доказывает. Вопрос в другом: сможет ли этот человек разобрать сломанную систему в три часа ночи, когда половина сервисов молчит, а дашборды врут.
| Вопрос | Что проверяет | Плохой ответ | Сильный ответ |
|---|---|---|---|
| Последний крупный инцидент | Был ли человек реально в эпицентре | «Был сбой, мы его починили» | Таймлайн, метрики, вывод на будущее |
| Три часа ночи, первые 10 минут | Процессную дисциплину | Сразу SSH на первый попавшийся хост | Подтвердить, оценить влияние, оповестить, диагностировать |
| Убитый алерт | Отношение к гигиене оповещений | Рассказ про новый алерт | Конкретное шумное правило и почему его убрали |
| SLI и SLO | Базу без подвоха | Путаница в терминах | Метрика отделена от цели |
| Полезный инструмент для себя | Способность строить мелочи | Внутренняя платформа, фреймворк | Скрипт на пять минут в день |
Как готовиться: короткий чек-лист
- Соберите две-три истории про инциденты с цифрами и хронологией.
- Отрепетируйте вслух первые десять минут дежурства — от подтверждения алерта до диагностики.
- Вспомните хотя бы один удалённый алерт и объясните, чем он мешал.
- Освежите определения SLI, SLO и SLA и разницу между ними — это спрашивают почти всегда.
- Найдите свой самый скучный полезный скрипт и будьте готовы объяснить, зачем он нужен.
Типичные ошибки
- Общие слова. «Мы улучшили мониторинг» без деталей читается как «я не участвовал».
- Прыжок к решению. Ответ начинается с «я зашёл на сервер» — значит, процесс не показан.
- Попытка удивить масштабом. Рассказ про собственную платформу на вопрос о личных скриптах звучит как отрыв от реальности.
- Зазубренные определения без примеров. SLI и SLO из памяти выдаст почти любой, а показать их на своём сервисе — единицы.
И ещё одно: не пытайтесь звучать умнее, чем есть. Интервьюер с опытом нескольких сотен собеседований чует воду за минуту. Лучше честно сказать «такого не делал, но вот как бы я подошёл» — это тоже полноценный ответ.
Смысл этих вопросов — не отсеять, а увидеть рабочего инженера. Того, кто был в настоящих сбоях, помнит цифры, умеет действовать по порядку и не боится признать, что где-то замешкался. Всё остальное на собеседовании — декорация.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.