Что спрашивают на DevOps-собеседовании, как отвечать про CI/CD, Kubernetes и инциденты и как отрепетировать разговор.
DevOps-собеседование меньше всего похоже на экзамен по инструментам. Список технологий знает любой, кто читал вакансии. Проверяют другое: как вы строите процесс, что делаете, когда всё сломалось, и умеете ли вы выбирать инструмент под задачу, а не по модности.
| Этап | Что проверяют |
|---|---|
| Скрининг | опыт, стек, ожидания по деньгам |
| Инфраструктура | Linux, сети, контейнеры, оркестрация |
| Практика | разбор инцидента, диагностика по логам |
| Процессы | CI/CD, релизы, безопасность, работа с командой |
Ответ «GitLab CI» — не ответ. Ждут путь: коммит → сборка → тесты → артефакт → деплой в среду, с откатом и с тем, что происходит при падении на каждом шаге. Хороший ответ содержит время сборки и предыдущий опыт улучшения.
Слои образа и их кэширование, multi-stage сборка, почему образ на 1 ГБ — это проблема, как передавать секреты, разница между CMD и ENTRYPOINT. Часто просят объяснить, почему контейнер приложения падает при старте.
Pod против Deployment, readiness и liveness пробы, рестарты и их причины, лимиты ресурсов и OOMKill, ConfigMap и Secret, Ingress. Практический вопрос: «под не поднимается — с чего начнёте».
Terraform против Ansible, state и блокировки, план перед применением, идемпотентность. Проверяют, понимаете ли вы, что сделает `apply` до его запуска.
Что происходит от браузера до приложения: DNS, балансировщик, TLS, прокси. Уровни LAN, проблемы с MTU, разница между L4 и L7. Здесь отсеивают тех, кто «всё делал через готовые пайплайны».
Метрики против логов против трассировки, что такое SLO и budget, почему «мониторинг есть, а инциденты не видны». Практический кейс: пользователи жалуются, а метрики в норме — что проверяете.
Порядок действий при падении прода, кто принимает решения, как коммуницировать, как писать постмортем без поиска виноватых. Это любимый вопрос интервьюеров: он показывает реальный опыт.
Работает структура: симптом → гипотезы → что проверяю → решение → профилактика.
«Пользователи сообщают о 502. Сначала смотрю на балансировщик: живы ли апстримы. Если живы — проверяю логи приложения и метрики latency. На прошлом проекте причина была в исчерпании пула соединений к БД: помогло увеличение пула и добавление таймаута. Профилактика — алерт на утилизацию пула, а не на 5xx».
— пример ответа из практики разбора интервью
Неделя по 30–40 минут: разобрать семь тем, вспомнить два-три реальных инцидента с цифрами и один раз пройти полный диалог. Кейс про инцидент важнее теории — на нём чаще всего отсеивают.
Если он есть в вакансии — да, хотя бы на уровне проб, лимитов и разбора падающего пода. Если инфраструктура на виртуальных машинах, спрашивают systemd, балансировку и деплой без оркестратора.
Да — Python, Go или Bash на уровне скриптов автоматизации. Полноценный live coding бывает реже, но разобрать чужой скрипт и найти в нём ошибку могут попросить.
Скажите прямо и покажите принцип: «с этим не работал, но задача решается так же, как X, — через декларативное описание и идемпотентный запуск». Интервьюер проверяет переносимость мышления, а не знание API.
Диапазоном, а не одним числом, с опорой на рынок. Подробный разбор — в статье переговоры о зарплате.
Опишите ситуацию одной фразой — «собеседование DevOps-инженер, Kubernetes и CI/CD, четыре года опыта» — и пройдите диалог в тренажёре. Тренер задаст вопросы по вашей роли и разберёт ответы после разговора.
Вспомните два своих инцидента и распишите по схеме: симптом — гипотезы — что проверили — решение — профилактика. Затем прогоните кейс вслух: откройте HintMeTalk AI, режим «Тренер», опишите вакансию одной фразой. После разбора видно, где вы начинаете чинить, не проверив гипотезу.
Разборы по другим ролям: Java, Python, frontend, системный аналитик.
Потренируйте этот навык в HintMeTalk AI
Открыть в приложении
HintMeTalk