Что на самом деле проверяют на собеседованиях DevOps-инженеров?

С кем вы на самом деле разговариваете

Для большинства DevOps-ролей технические раунды не проводит общий рекрутер. После начального скрининга (часто HR-специалист уточняет срок уведомления, зарплату, право на работу) сложные вопросы задают люди, с которыми вы будете работать: руководитель платформы или SRE, старший DevOps-инженер, иногда engineering manager, управляющий графиком дежурств. В регулируемых средах — финансы, здравоохранение, всё, что касается PCI или SOC 2 — на одном из раундов часто присутствует инженер по безопасности, потому что контроль доступа и audit trails — часть работы, а не второстепенная задача.

Это важно, потому что этих интервьюеров обычно будили в 3 часа ночи из-за проблем, которые вам предстоит решать. Они проверяют не то, можете ли вы дать определение «CI/CD» или перечислить сервисы AWS. Они проверяют, доверили бы они вам доступ к продакшену.

Техническая проверка: как она выглядит на практике

Большинство процессов отбора на эту роль включают один из трёх форматов, иногда два:

Домашнее или live-задание с реальной сломанной инфраструктурой. Вам могут дать репозиторий с Terraform-модулем, который не применяется, Dockerfile, собирающий образ на 2ГБ вместо 200МБ, или GitHub Actions/GitLab CI pipeline, который работает локально, но падает в раннере. Вас просят исправить это и объяснить логику, а не просто вставить рабочий diff. Интервьюеры обращают внимание, проверяете ли вы plan output перед apply, смотрите ли на exit codes и логи перед догадками, и объясняете ли почему исправление работает, а не только что оно работает.

Live-дебаг или парное программирование. Вы демонстрируете экран, вам дают Kubernetes-кластер (часто kind или minikube) с подом в CrashLoopBackOff или сервисом, возвращающим 502 за load balancer, и вы в реальном времени комментируете диагностику: kubectl describe pod, проверка resource limits, чтение events перед логами, проверка, проблема в приложении или в ingress. Ценность полностью в комментариях. Молчание во время набора команд — худший сигнал, чем неверная первая догадка с логичным следующим шагом.

Whiteboard или устный раунд проектирования системы. Спроектируйте deployment pipeline для сервиса с жёстким требованием uptime, или спроектируйте откат schema migration с нулевым downtime, или спроектируйте мониторинг для набора микросервисов. Оценивают компромиссы: blue-green против canary, почему вы выберете одну политику autoscaling, а не другую, что вы поместите в dashboard, а на что настроите алерты, как установите SLO и что будете делать, когда error budget закончится.

Вопросы, которые на самом деле проверяют компетентность

Несколько вопросов встречаются почти на каждом DevOps-собеседовании, и у каждого есть версия, отделяющая тех, кто делал работу, от тех, кто о ней читал.

«Расскажите об инциденте, который вы разбирали». Настоящий ответ называет симптом, диагностические шаги по порядку, реальную root cause, немедленное исправление и — критически важно — что изменилось после: новый алерт, runbook, изменение в deploy gate. Обычно также включает что-то, что пошло не так в самом реагировании, потому что инциденты редко проходят гладко. Если в истории нет postmortem и последующих действий, интервьюер спросит, что изменилось, и должен быть ответ.

«Как вы управляете секретами?» Они слушают, различаете ли вы секреты в version control (провал), секреты в environment variables (частичный ответ) и секреты, получаемые в runtime из чего-то вроде Vault, AWS Secrets Manager или SSM Parameter Store с ограниченными IAM-ролями и ротацией. Бонусные баллы, без подсказки, за упоминание, как ротировать credential, который уже утёк, потому что это вопрос за вопросом.

«В чём разница между вашим мониторингом и алертингом?» Проверяет, думаете ли вы в терминах SLI и SLO или только в dashboard. Сильный ответ разделяет, на что вы смотрите при расследовании (метрики, трейсы, логи — в идеале названные: Prometheus/Grafana, Datadog, ELK или Loki stack), от того, что должно кого-то будить, и объясняет, почему alert fatigue — это ошибка проектирования, а не неизбежность.

«Как бы вы откатили это?» Спрашивают почти о любом сценарии деплоя. Ответ требует конкретного механизма — предыдущий image tag, Helm revision, database migration, которая обратима или хотя бы forward-compatible, — а не «мы бы просто передеплоили старую версию», что предполагает, что старую версию всё ещё можно собрать и что сам откат ничего не сломает.

«Почему Terraform/Ansible/Puppet, а не альтернатива?» Меньше об инструменте, больше о понимании declarative против imperative state management, что такое drift и как его обнаружить и reconcile. Если команда использует GitOps (ArgoCD, Flux), ждите вопрос о том, что произойдёт, если кто-то изменит что-то напрямую в кластере, а не через Git, потому что это реальное ежедневное трение модели.

Как звучит поверхностный ответ

Для того, кто делает эту работу, поверхностный ответ имеет определённую форму. Он называет инструменты без решения: «мы использовали Kubernetes, Terraform и Jenkins» не говорит интервьюеру ничего о том, что вы выбрали и почему. Он пропускает failure mode: описание процесса деплоя без упоминания, что происходит при сбое, или настройка мониторинга без упоминания, что вы сейчас не отслеживаете. Он трактует «я бы перезапустил» как диагноз, а не временную меру — перезапуск пода может снять симптом, но если вы не можете сказать, что вызвало краш, интервьюер знает, что вы вернётесь к этому в 3 ночи. И он отвечает на вопросы system design одной архитектурой без рассмотренных альтернатив, что читается как заучивание одной диаграммы, а не взвешивание компромиссов на реальной системе с реальными ограничениями — стоимость, размер команды, существующий инструментарий.

Обратное тоже верно и стоит знать: чрезмерное объяснение каждой аббревиатуры или цитирование учебного определения blue-green deployment, когда спрашивают, как вы развернёте конкретный сервис, читается так же. Интервьюер хочет вашего рассуждения, применённого к их сценарию, а не общей лекции.

Что сделать перед собеседованием

Вернитесь к последним двум-трём реальным инцидентам, миграциям или изменениям инфраструктуры и запишите по порядку: симптом, шаги диагностики, исправление и что изменилось после. Если не можете заполнить последнюю часть, это стоит заметить до собеседования, а не во время.

Если в объявлении о вакансии упомянуты конкретные инструменты — Terraform вместо Pulumi, EKS вместо самоуправляемого Kubernetes, Datadog вместо open-source Prometheus — честно сверьте свой опыт с этим стеком. Где вы использовали эквивалент, но не точный инструмент, скажите об этом и объясните соответствие; интервьюеры обычно уважают «я использовал Chef, а не Puppet, но модель та же» гораздо больше, чем расплывчатое заявление о знакомстве, разваливающееся после одного уточняющего вопроса.

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