Как отвечать на собеседовании DevOps: разбор реального интервью

Перед нами не учебник, а расшифровка живой беседы. Инженер по имени Жибек с пятью годами опыта в AWS отвечала на вопросы по ходу отбора на позицию тимлида в Herc Rentals — с прицелом на роль player coach, то есть руководителя, который сам остаётся в технике. По этим ответам хорошо видно, что отличает кандидата, которого зовут на следующий этап: структура, числа и готовность честно обозначить границы своих знаний.

Почему эти ответы работают

Собеседование на DevOps редко проваливают из-за того, что человек не помнит команду kubectl describe pod. Проваливаются на структуре: рассказ начинается с «ну, я работал с облаком», и через минуту интервьюер уже не понимает, что кандидат умеет. У Жибек каждый ответ собран по одной схеме — контекст, действие, измеримый результат. Звучит сухо в описании, зато в разговоре попадает точно в цель.

Второе, что цепляет, — честность в вопросе про Azure и OCI. «Мой глубокий опыт — AWS, но концепции те же: VPC превращается в VNet, IAM — в Entra ID и RBAC, EKS — в AKS или OKE. Terraform работает везде, так что я научусь быстро, базу по Azure уже начала смотреть». Такой ответ снимает подозрение в приукрашивании и показывает умение переносить знания между платформами.

«Расскажите о себе»: шесть частей вместо биографии

Здесь почти все начинают с университета. Работает другая последовательность:

• кто вы и сколько лет в профессии;
• где работали — масштаб, а не перечень отделов;
• два результата с числами;
• сертификаты, если они подкрепляют сказанное;
• почему вам интересна именно эта вакансия.

У Жибек получается так: DevOps-инженер, больше пяти лет с AWS. С 2021 года в Yelp — четыре года на высоконагруженных потребительских приложениях: инфраструктура в AWS, Kubernetes на EKS, пайплайны в GitHub Actions. Blue green деплой с автоматическим откатом ускорил релизы на 35%. Плюс менторство джунов и runbook'и для команды. Дальше — Zulily: Terraform для dev, staging и production, EKS с автоскейлингом, безопасные пайплайны с шагом согласования. Сертификаты AWS Solutions Architect Associate и CKAD. И финальная строчка — про переход к роли player coach.

Ключевая деталь: цифра «35%» произносится один раз и в самом начале. Дальше она не повторяется — повтор превращает достижение в мантру.

Рабочий день: порядок действий важнее списка инструментов

Вопрос про рутину проверяет, понимаете ли вы, из чего складывается смена. Ответ Жибек начинается не с инструментов, а с риска: утро — дашборды CloudWatch и алерты, не сломалось ли что-то ночью. Потом стендап. Основная часть дня — изменения в Terraform: новые окружения, правки сети, новые сервисы. Между этим — ревью пул-реквестов, помощь разработчикам, у которых упал пайплайн или приложение плохо масштабируется на EKS. Инциденты в проде и разбор причин после них. Документация и runbook'и. Иногда встречи с безопасностью или прикладными командами.

Такой ответ показывает, что человек видит свою работу как цепочку «обнаружить — починить — записать», а не как набор любимых тулов.

Проект: один рассказ в деталях, второй — в запасе

Про проект спрашивают почти всегда, и почти всегда кандидат уходит в перечисление технологий. Жибек держит в голове две истории разной глубины.

Основная — про Amazon DocumentDB в Zulily. Команде нужна была приватная база, которую легко повторить во всех окружениях. Что сделано: модули Terraform для DocumentDB, приватные подсети, security groups и IAM, чтобы подключаться могли только одобренные приложения на EKS. Пайплайн в GitHub Actions с планом, ревью и согласованием перед production. Алерты CloudWatch на CPU, соединения и дисковое пространство. Результат: одинаковый сетап в dev, staging и production, никакого публичного доступа, новые окружения поднимаются заметно быстрее.

Вторая история, если попросят ещё, — из Yelp. Медленные и рискованные релизы. Кэширование и параллельные джобы в GitHub Actions, blue green деплой, автоматический откат при провале health check. Итог: релизы быстрее на те самые 35%, меньше неудачных выкладок.

Технический блок: что проверяют на самом деле

Вопросы звучат по-разному, а проверяют одно — понимаете ли вы компромиссы. Terraform state и удалённое хранение, структура под много окружений, дрейф конфигурации, landing zone, автоскейлинг Kubernetes, падающий под, Helm, стратегии выката, дизайн пайплайна, секреты, VPC, IAM, disaster recovery, стоимость облака, разбор аварии. Список длинный, но за ним стоят четыре темы: сеть, доступ, автоматизация и восстановление.

На вопрос про выбор IaC отвечайте через контекст компании, а не через вкусы:

Про state отвечают коротко: это файл, где Terraform хранит, что создал. Лежит в S3, чтобы у команды было одно состояние, а DynamoDB ставит блокировку, чтобы двое не меняли одновременно. Дрейф — когда кто-то поправил ресурс руками в консоли; лечится регулярным terraform plan и правкой в коде. Landing zone — готовая безопасная база для аккаунтов: структура, сеть, IAM, логирование, guardrails, в AWS это Control Tower и Organizations.

Отдельно про то, что путают чаще всего:

Авария в проде разбирается по шагам: сначала остановить влияние, при необходимости откатить, сообщить стейкхолдерам, найти причину по логам и метрикам, потом написать postmortem без поиска виноватых и закрыть дырку. Про disaster recovery спрашивают через RTO и RPO — сколько времени допустимо простоять и сколько данных можно потерять. Бэкапы, мультизона, копии в другом регионе и регулярные учения, а не документ на полке.

Вопросы для менеджера

Блок на руководящую роль ловит не знания, а принципы. Низкий перформер: разговор один на один рано, понять причину, поставить конкретные цели со сроком, поддерживать, следить за динамикой; если ничего не меняется — подключать HR. Приоритеты: сначала прод и безопасность, потом бизнес-задачи, согласованные с руководством, и обязательно видимая картина компромиссов. Спор двух инженеров про дизайн: дать обоим высказаться, сравнить по фактам — стоимость, риск, простота, при необходимости прогнать маленький тест и решить.

План на 90 дней Жибек раскладывает на три отрезка: первые 30 дней — слушать и изучать команду, системы, болевые точки; следующие 30 — быстрые победы вроде стандартов и runbook'ов; последние 30 — дорожная карта вместе с руководством. Метрики команды: частота деплоев, доля неудачных изменений, время восстановления, аптайм, расходы на облако и настроение людей.

Где кандидаты сыпятся

• Рассказ о себе длиной в пять минут без единой цифры.
• Проект описан через инструменты, а не через задачу и результат.
• На незнакомой теме выдумывают опыт вместо переноса концепций.
• Про инцидент говорят «починили», не упоминая разбор причин.
• Про AI либо молчат, либо делают вид, что не пользуются: Жибек прямо говорит, что черновики пайплайнов, ревью Terraform и документацию готовит с Claude, но всё проверяет и тестирует перед использованием.

Разница между этими ответами и провальными — не в глубине знаний. Она в привычке упаковывать опыт так, чтобы его можно было проверить: контекст, действие, цифра, вывод. Тренируется это за один вечер — берёте три своих проекта, выписываете по каждому задачу и результат в числах и проговариваете вслух. Дальше на собеседовании остаётся только не мешать самому себе.