Вопросы для подготовки к собеседованию на позицию Devops-инженера

Собеседование DevOps до сих пор уходит ниже контейнеров: загрузка Linux, PID, диски и сеть. Многие банки вопросов начинаются не с Kubernetes, а с железа и boot, потому что именно там ломается прод.

Рядом с этой базой на встречах уже спрашивают GitOps, OpenTofu, OpenTelemetry и SBOM. Это не два разных рынка. Это два слоя одного собеседования: сначала «держится ли машина», потом «как выкатываете и наблюдаете».

Ниже вопросы на собеседовании DevOps с разбором ответов. Разберём, что проверяют у junior devops, middle и senior: Linux, контейнеры, CI/CD, IaC и облако. Важно уметь сузить инцидент и назвать откат, а не перечислить тулы.

Как проходит собеседование DevOps

Как проходит собеседование DevOps, зависит от компании, но редко это один час «про себя». Обычно встреч несколько. Скрининг сверяет стек и готовность к ночным вызовам. Дальше техника, живая практика, дизайн контура и разговор про культуру.

HR часто спрашивает не только про Docker. На этом шаге всплывает on-call: кто дежурит, как часто будят, есть ли ротация. Если дежурства для вас красная зона, лучше выяснить это до технической серии, а не после оффера.

Технический круг почти всегда двуслойный. Сначала Linux, процессы, диски, сеть. Потом контейнеры, пайплайн, IaC и облако. Junior devops объясняет понятия и простой пайплайн. Middle дебажит под и ноду. Senior связывает откат, blast radius и то, кто имеет право менять прод.

Практика бывает скриптом, пайплайном или Terraform под Kubernetes. Иногда вместо домашнего задания дают живой разбор: CrashLoop или медленная нода. Культурный круг проверяет, как вы говорите в инциденте, а не как улыбаетесь.

Ниже общая карта этапов и того, что на каждом обычно проверяют.

На конкретной вакансии набор короче: техника плюс один кейс. Спросите у рекрутера нарезку до дня X. Когда стек уже ясен, сверьтесь с живыми вакансиями в подборке DevOps на HireHi.

Почему спрашивают и Linux, и GitOps

Почему на собеседовании девопс до сих пор разбирают inode и PID, если в вакансии уже Argo CD? Потому что контейнер не отменяет машину. Если нода не видит диск, GitOps не спасёт сервис.

Базовые вопросы уходят в boot, PID, systemd, диски и сеть. Для junior эту планку держат в том же объёме: Linux, Docker, простой пайплайн.

Вакансии посвежее добавляют второй слой: GitOps, OpenTofu, OpenTelemetry, SBOM и подпись образа. Это не замена Linux, а надстройка над ним.

Сильный ответ показывает оба слоя на одном инциденте. Сначала: жив ли узел, что с диском, что с DNS и TLS. Потом: какой артефакт выкатился, из какого Git-состояния, как откатиться. Если умеете только «что такое Pod», middle не закроете. Если умеете только Argo, вопросы по Linux вас снимут.

Чем Junior DevOps отличается от Middle и Senior

Чем Junior DevOps отличается от Middle и Senior на интервью, лучше смотреть по глубине темы, а не по годам в резюме. Лестница держится на том, насколько глубоко вы идёте в одну и ту же тему.

Junior объясняет устройство. Middle чинит и сопровождает. Senior проектирует отказ и границы. Senior на встрече проверяют дизайном и инцидентом, а не количеством знакомых слов.

Не натягивайте старший грейд списком тулов. Если в резюме Kubernetes, а в ответе нет probes и отката, это junior с чужими названиями.

Какие вопросы задают DevOps-инженеру

Какие вопросы задают DevOps-инженеру, удобно держать по доменам, а не как одну простыню. Так проще увидеть, где у вас дыра.

• Профессиональные: Linux и сети, контейнеры и Kubernetes, CI/CD, IaC, облака и GitOps.
• Опыт: дежурства, инциденты, откат, что вы реально чинили.
• Ситуационные: прод лежит, алерт врёт, канарейка ест CPU.
• Практические: ротация логов, пайплайн, Terraform под кластер, живой CrashLoop и медленная нода.

Вопросы на собеседовании devops редко идут строго по грейду. Один и тот же CrashLoop у junior это логи, у middle probes и память, у senior решение, катить ли рестарт на весь Deployment.

Профессиональные вопросы DevOps

Разберём вопросы по рабочим темам. Где глубина прыгает, отметим, что ждут от junior, middle и senior. Ответ должен чинить отказ, а не повторять определение.

Linux и сети: слой ниже контейнеров

Чем PID 0 отличается от PID 1 и зачем это спрашивают?

Что проверяют. Понимаете ли вы, кто сидит в корне дерева процессов, а не путаете номер с «просто первым процессом».

Как отвечать. PID 0 это idle и часть ядра, пользовательский мир его не видит как обычную программу. PID 1 это init, сейчас чаще systemd: он запускает систему и подбирает сирот. Если PID 1 умер, машина не «чуть подвисла», она потеряла родителя процессов.

Junior называет роли. Middle связывает это с контейнером: в контейнере ваш процесс часто становится PID 1 и должен корректно обрабатывать сигналы. Senior объясняет, почему zombie и почему entrypoint без init ломает останов.

Что происходит от включения сервера до login?

Что проверяют. Можете ли вы провести boot, а не сказать «ну, Linux загружается».

Как отвечать. Прошивка UEFI или BIOS находит диск. Загрузчик отдаёт ядро и initramfs. Ядро монтирует корень и запускает PID 1. Дальше цели systemd, сеть, sshd, login. На собеседовании devops этот рассказ нужен, чтобы потом отличать «не встаёт диск» от «не встаёт юнит».

Junior: последовательность блоков. Middle: emergency.target, почему не смонтировался root, чем journalctl -b полезен. Senior: как это ложится на облачный образ, cloud-init и почему «пересоздать ВМ» не заменяет понимание boot.

Чем inode отличается от имени файла?

Что проверяют. Отличаете ли метаданные объекта в ФС от пути, которым вы пользуетесь.

Как отвечать. Имя живёт в каталоге. Inode хранит размер, права, ссылки, указатели на блоки. Жёсткая ссылка это ещё одно имя на тот же inode. Симлинк это отдельный объект с путём внутри. «Диск полный, а df ещё есть место» часто про inodes, не про гигабайты.

Как читать Load Average, если CPU ещё не на потолке?

Что проверяют. Не сводите ли вы нагрузку только к проценту процессора.

Как отвечать. Load Average это очередь на выполнение и на диск, не чистый CPU. Высокий load при низком CPU часто I/O wait или засыхание в D-state. Смотрите vmstat, iostat, кто в uninterruptible. В контейнерах смотрите, не упёрлись ли в cgroup, а не в «хост в целом».

Чем TCP отличается от UDP, когда сервис «просто не отвечает»?

Что проверяют. Идёте ли вы от свойств протокола к диагностике, а не от заученной таблицы.

Как отвечать. TCP даёт соединение, повтор и порядок. UDP шлёт датаграммы без такого договора. Если API «висит», сначала SYN, таймаут, RST, не «перезапусти nginx». Для DNS и части телеметрии UDP нормален, но тогда вы обязаны думать про потерю пакетов, а не про handshake.

Как идти по цепочке DNS, TCP, TLS и HTTP, если сайт не открывается?

Что проверяют. Есть ли у вас путь диагностики, а не сразу tcpdump на всё.

Как отвечать. Имя резолвится? До порта есть маршрут и SYN-ACK? Сертификат и SNI сходятся? HTTP уже отвечает кодом? Потом балансировщик и логи приложения. Назовите шаг, который уже доказан, и только потом копайте глубже.

Junior доходит до ping и curl. Middle читает TLS и код ответа, отличает 502 от таймаута апстрима. Senior оценивает, это один под, нода, зона или весь вход.

Контейнеры и Kubernetes

Чем контейнер отличается от виртуальной машины?

Что проверяют. Понимаете ли namespaces и cgroups, а не фразу «контейнер легче».

Как отвечать. ВМ поднимает своё ядро. Контейнер делит ядро хоста и изолирует вид через namespaces: процессы, сеть, точки монтирования. Лимиты даёт cgroups. Поэтому привилегированный контейнер опаснее «просто ещё одной ВМ». Образ это слои ФС плюс команда запуска, а не работающий процесс.

Что такое Pod и чем Deployment отличается от StatefulSet?

Что проверяют. Не считаете ли вы Pod «маленьким Docker», а StatefulSet «просто Deployment с диском».

Как отвечать. Pod это минимальная единица запуска: один или несколько контейнеров, одна сеть, общие тома. Deployment растит безымянные реплики и любит безсостояние. StatefulSet даёт стабильное имя, порядок и том на реплику. Базу в Deployment с hostPath на интервью обычно ломают вопросом «что будет после переезда пода».

Кластер сейчас скорее дефолт, а не экзотика. Поэтому знать имена объектов недостаточно, на встрече просят починить под.

Зачем liveness и readiness и чем опасно их перепутать?

Что проверяют. Понимаете ли вы, кого kubelet убивает, а кого снимает с балансировки.

Как отвечать. Readiness решает, пойдёт ли трафик. Liveness решает, пора ли перезапустить контейнер. Если liveness бьёт в тяжёлый запрос к базе, под будет убивать себя под нагрузкой. Если readiness всегда true, сломанный под продолжит принимать запросы.

Junior даёт определения. Middle приводит провал: проба в зависимость, которая сама лежит. Senior говорит про startupProbe, период, таймаут и как это связано с PDB при выкладке.

Как разбирать CrashLoopBackOff, не перезапуская весь Deployment?

Что проверяют. Сужаете ли вы причину, а не делаете rollout restart «на всякий случай».

Как отвечать. Сначала describe: lastState, exit code, OOMKilled, причина пробы. Потом логи текущего и предыдущего контейнера. Потом конфиг, секрет, initContainer, права тома. Рестарт всего деплоя маскирует гонку и бьёт по соседям.

Демонстрационный ход. «Сначала один под и его exit. Потом пробы и память. Рестарт контура только когда понятен blast radius.»

Зачем Ingress, если уже есть Service?

Что проверяют. Отличаете ли L4 внутри кластера от входа HTTP снаружи.

Как отвечать. Service даёт стабильный адрес набору подов. ClusterIP снаружи не виден. Ingress или Gateway описывает хосты, пути, TLS на входе. Путать их это как сказать, что у внутреннего DNS уже есть сертификат сайта. На интервью сразу спросите, какой вход сейчас в проде: Ingress, cloud LB или mesh.

Что хотят услышать про Helm, когда спрашивают про релиз в кластере?

Что проверяют. Умеете ли вы откатить релиз, а не только «это шаблоны YAML».

Как отвечать. Chart это пакет манифестов. Релиз это установленный экземпляр со значениями. Важно, где values, кто их меняет, как смотреть diff и как helm rollback связан с GitOps. Если Git источник истины, «откатил Helm руками» может разъехаться с репозиторием.

CI/CD и поставка

Что должно быть в пайплайне кроме сборки и выкладки?

Что проверяют. Есть ли у вас анатомия поставки, а не кнопка «deploy».

Как отвечать. Сборка. Тесты. Проверки безопасности. Неизменяемый артефакт с тегом, не latest. Выкладка. Проверка, что новая версия жива. Без проверки вы узнаете о провале от пользователей. Без неизменяемого артефакта вы не откатитесь к тому, что реально ехало.

Junior рисует build и deploy. Middle добавляет тесты, секреты, окружения. Senior добавляет кто промоутит в прод, подпись и что делать, если verify после выкладки красный.

Чем GitHub Actions, Jenkins и GitLab CI отличаются на интервью?

Что проверяют. Можете ли вы сравнить рабочие контуры, не объявляя один инструмент «единственно верным».

Как отвечать. Jenkins часто живёт как легаси с плагинами и своими агентами. GitHub Actions удобен рядом с GitHub. GitLab CI сидит в том же репозитории, что и код. На встрече важнее другое: где runners, как кэшируете, как храните секреты, как промоутите артефакт между окружениями.

Скажите, чем пользовались сами, и где граница. Не изображайте одинаковую глубину по всем трём.

Как устроить откат, если пайплайн уже зелёный, а прод болит?

Что проверяют. Есть ли план отката до выкладки, а не идея «починим хотфиксом в проде».

Как отвечать. Зелёный пайплайн значит, что проверки прошли, а не что бизнес-метрика жива. Откат это предыдущий артефакт и предыдущее состояние манифестов, плюс проверка, что данные миграции откатываемы. Если миграция ломает назад, откат приложения недостаточен. На HireHi как раз есть разбор, что подготовить к откату релиза до выкладки.

Где хранить секреты и чего нельзя класть в Git?

Что проверяют. Не путаете ли вы .env в репозитории с нормальной схемой.

Как отвечать. В Git не кладут ключи, токены, kubeconfig от прода. Для CI это секрет хранилища системы. Для кластера это Secret из внешнего хранилища или CSI, не манифест с base64 «потому что Kubernetes так хранит». Base64 это кодировка, не защита. Назовите, кто ротирует и как отзываете утёкший ключ.

IaC: Terraform, Ansible, OpenTofu

Чем опасен Terraform state, если его кладут рядом с кодом?

Что проверяют. Понимаете ли вы, что state это карта реального мира, а не ещё один YAML.

Как отвечать. В state попадают адреса ресурсов и иногда секреты. Файл в Git читает кто угодно с доступом к репозиторию. Параллельный apply без блокировки рвёт контур. Держите remote state с блокировкой. Не правьте state руками, пока не понимаете, какой ресурс станет сиротой.

Junior: зачем state. Middle: backend, lock, как выглядит drift. Senior: кто имеет право apply на прод, policy, как GitOps меняет эту модель.

Когда Ansible, а когда Terraform?

Что проверяют. Делите ли вы «создать ресурс» и «настроить уже живую машину».

Как отвечать. Terraform хорошо описывает облачные объекты и их связи. Ansible хорошо приводит узел к желаемой конфигурации: пакеты, файлы, сервисы. Можно вместе: Terraform поднял ВМ, Ansible настроил агент. Плохо, когда Ansible создаёт облако без карты зависимостей, а Terraform правит конфиги внутри гостевой ОС как основной стиль.

Terraform или OpenTofu: что хотят услышать?

Что проверяют. Следите ли вы за развилкой, а не повторяете только знакомый бренд.

Как отвечать. OpenTofu это открытый форк с близким языком. На интервью честно скажите, чем пользовались. Дальше: совместимость стейта, провайдеры, что команда фиксирует в репозитории. Не спорьте «кто морально лучше». Покажите, что смена бинаря это решение с риском, а не смена логотипа.

Облака и GitOps

Что такое GitOps и чем он отличается от kubectl apply с ноутбука?

Что проверяют. Есть ли источник истины и кто его применяет.

Как отвечать. Желаемое состояние лежит в Git. Агент в кластере, часто Argo CD или Flux, сходится к нему. kubectl apply с ноутбука оставляет снежинку: кластер уехал, репозиторий нет. Спросите про prune, хуки, кто мержит в prod-ветку и как смотрят diff до синка.

Junior: Git как истина. Middle: синк, prune, откат через Git. Senior: несколько кластеров, прогрессивная выкладка, разделение кто пишет манифест и кто жмёт sync.

Зачем SBOM и подпись образа, если registry уже есть?

Что проверяют. Понимаете ли вы цепочку поставки, а не только «docker push прошёл».

Как отвечать. Registry хранит байты. Он не отвечает, из какого коммита они собраны и не подменили ли слой. SBOM перечисляет состав. Подпись вроде cosign говорит, что артефакт собрал доверенный пайплайн. На junior devops достаточно идеи. Middle должен сказать, где в пайплайне стоит проверка. Senior связывает это с допуском в кластер.

Что такое OpenTelemetry и зачем он на собеседовании?

Что проверяют. Можете ли вы собрать след запроса, а не назвать ещё один агент.

Как отвечать. OpenTelemetry это договор, как приложения отдают трассы, метрики и логи. Выгода не в логотипе, а в том, что сервис, sidecar и вход говорят на одном языке. На инциденте вы идёте по trace id, а не по трём несовместимым дашбордам. Не обещайте «у нас полный OTel», если в опыте только Prometheus на нодах.

Как говорить про облако, если в резюме один провайдер?

Что проверяют. Переносите ли вы модель, а не зубрите клики консоли.

Как отвечать. Назовите свой контур: сеть, IAM, диск, управляемый Kubernetes, объектное хранилище. Покажите, что понимаете аналог в другом облаке: где там роли, где сеть, где управляемый кластер. Не маскируйте дыру сертификатом, который не открывали полгода.

Что спрашивают про опыт дежурств и инцидентов

Что спрашивают про опыт дежурств и инцидентов, почти никогда не сводится к фразе «я дежурил». Интервьюер хочет услышать контур: какой алерт, какой blast radius, что вы сделали руками, как закрыли повтор. Список Prometheus без этой рамки звучит как витрина навыков.

Подготовьте две истории. Первая: выкладка или отказ, который вы довели до устойчивого прода. Вторая: ночной или дневной инцидент, где вы сузили причину, а не перезапустили всё. В обеих назовите, кого разбудили, что откатили, какая проверка показала, что стало лучше.

Не выдумывайте цифры MTTR. Если точное время не помните, скажите порядок и чем тогда мерили. Отдельно спросят, были ли ложные алерты и что вы с ними сделали. Героизм «я один тушил до утра» на сильном интервью минус, не плюс.

Если дежурства в вакансии плотные, полезно заранее понять модель смен и красные флаги. На HireHi есть отдельный разбор, как оценить on-call до оффера. Здесь достаточно уметь рассказать свой инцидент без театра.

Какие ситуационные кейсы ждут DevOps

Какие ситуационные кейсы ждут DevOps, обычно про прод, который уже болит. В каждой сцене сначала симптом и что проверите, потом лечение. Не начинайте с «перезапустим кластер».

Прод лежит, дашборд зелёный. С чего начнёте?

Что проверяют. Верите ли вы только зелёной панели или ищете, где наблюдение слепое.

Как отвечать. Сверьте симптом снаружи: синтетика, вход, ошибка клиента. Потом спросите, какую сущность дашборд вообще рисует. Часто панель смотрит на процесс агента, а не на бизнес-ручку. Дальше логи входа, saturation нод, недавний релиз. Зелёный дашборд это гипотеза, не диагноз.

Ночью упал один сервис из десяти. Как оцените blast radius?

Что проверяют. Считаете ли вы зону поражения до лечащего действия.

Как отвечать. Кто зависит от сервиса. Один под, деплой, нода, зона, брокер, база. Если это один под, не трогайте соседей. Если это общий Ingress или DNS, радиус шире, и откат одного репозитория может не хватить. Скажите вслух, что уже исключили.

Коллега предлагает откатить всё. Когда это правильный ход?

Что проверяют. Умеете ли вы отличить откат причины от отката «на всякий случай».

Как отвечать. Откат уместен, когда последний релиз совпадает по времени с поломкой и действие обратимо. Если упал диск ноды, откат манифестов не вернёт inode. Если миграция уже писала в новую схему, откат приложения может сделать хуже. Назовите проверку, которая подтвердит, что после отката стало лучше.

Алерт орёт третий час, бизнес молчит. Что сделаете?

Что проверяют. Умеете ли вы снизить шум, не игнорируя настоящий отказ.

Как отвечать. Проверьте, есть ли пользовательский удар. Если удара нет, понизьте severity и запишите, почему правило врёт: порог, измерение, отсутствие for. Если удар есть, а бизнес молчит, это не «ложный», это дыра в эскалации. Не отключайте правило «чтобы поспать», не оставив владельца.

Канарейка ест CPU. Останавливаете выкладку или копаете дальше?

Что проверяют. Есть ли у вас порог остановки, а не бесконечный интерес к графику.

Как отвечать. Сначала доля канарейки и есть ли рост ошибок у этой версии. Если ошибки и latency едут вверх вместе с CPU, стоп промоушена и откат канарейки. Если CPU вырос на прогреве кэша без ошибок, можно наблюдать короткий интервал, но с заранее названным стоп-краном. Копать «ещё пять минут без критерия» на интервью слабый ход.

Какие практические задания дают DevOps

Какие практические задания дают DevOps, обычно сводится к трём типам: ротация логов на Linux, пайплайн сервиса, Terraform рядом с Kubernetes. К ним часто добавляют живой дебаг пода или ноды. Дальше разберём подход к каждому.

Как подойдёте к ротации логов, чтобы диск не кончился?

Что проверяют. Думаете ли вы про процесс, который держит файл открытым, а не только про gzip раз в сутки.

Как отвечать. Сначала где пишет приложение: файл, journal, sidecar. Потом правило: размер или дата, сколько копий, сжатие, куда уезжает архив. Если процесс не открывает лог заново, простое переименование оставит запись в удалённый inode, и диск не освободится. Для systemd это copytruncate или сигнал reopen. Проверьте на стенде: лог растёт, ротация проходит, сервис жив, место вернулось.

Чего не делать. Не сдавайте чужой конфиг ротации без разбора. Назовите, кого будите, если ротация сломается ночью.

Спроектируйте пайплайн сервиса от коммита до проверки в проде

Что проверяют. Закрываете ли вы артефакт, секреты и verify, а не только build.

Как отвечать. Коммит собирает образ или бинарь с неизменяемым тегом. Тесты и линт. Скан зависимостей. Пуш в registry. Выкладка в dev, затем в prod тем же артефактом. После выкладки проверка: под готов, синтетика, ошибка не выросла. Секреты не в репозитории. Откат это предыдущий тег, не «соберём ещё раз с той же ветки и надеемся».

Junior может остановиться на сборке и деплое в dev. Middle должен назвать окружения и стоп при красном verify. Senior добавляет кто промоутит и как не выкатить неподписанный образ.

Terraform должен поднять ресурсы под Kubernetes. С чего начнёте?

Что проверяют. Уточняете ли вы, что создаёт Terraform, а что синкает GitOps, до первого apply.

Как отвечать. Спросите контур: кластер уже есть или его тоже описываем. Где remote state. Какие объекты в Terraform: сеть, нодпул, namespace, или ещё Deployment. Если манифесты приложений уже в Argo, Terraform не должен стать вторым источником тех же подов. План читаете до apply. После apply сверяете, что в кластере появилось ожидаемое, а не только «exit 0».

Не начинайте с сотни ресурсов без state и без границы ответственности.

Под в CrashLoopBackOff. Как будете дебажить вживую?

Что проверяют. Работаете ли вы как у терминала, а не как в лекции про архитектуру Kubernetes.

Как отвечать. Один под. describe. exit code. логи прошлого запуска. events ноды. Не kubectl delete pod в цикле. Если OOM, смотрите лимит и реальный RSS, не поднимайте лимит вслепую в три раза. Если проба, временно отличите её от падения бинаря. Если конфиг, сравните с рабочей репликой, не переписывайте весь Deployment.

Нода тормозит. Как отличить диск, сеть, CPU и kubelet?

Что проверяют. Есть ли у вас развилка, а не один совет «добавьте нод».

Как отвечать. CPU steal и saturation. Диск: await, очередь, место и inodes. Сеть: дропы, DNS, латентность до API. kubelet: ротация логов, количество подов, ошибки PLEG. Смотрите, один под ест ноду или нода больна для всех. Добавить нод в автоскейлере можно, но на интервью сначала назовите, что уже измерили.

Как подготовиться к собеседованию DevOps

Подготовка к собеседованию DevOps это не марафон карточек и не гонка за названиями. Соберите два слоя. Первый: Linux, диск, сеть, один живой дебаг. Второй: пайплайн, IaC, кластер, один инцидент с дежурства. К ним добавьте две свои истории без выдуманных цифр.

Повторите boot, inode, Load Average, probes, state, откат. Если в вакансии GitOps, нарисуйте, кто источник истины. Если в вакансии одно облако, не учите три консоли за ночь. Незнакомые технологии из описания вакансии трогайте только тогда, когда они там действительно есть.

Частые провалы выглядят так. Человек перечисляет Kubernetes и не разбирает CrashLoop. Linux «учил когда-то». Пайплайн без артефакта и verify. Дежурство как подвиг без выводов. GitOps как слово, kubectl apply как практика.

• Не начинайте ответ с названия облака, пока нет симптома и blast radius.
• Не рестартуйте Deployment, пока нет exit code одного пода.
• Не кладите секреты в Git даже в учебном примере.
• Не молчите про откат и про то, кто дежурит после выкладки.

Перед живой встречей ответы стоит проговорить вслух. На HireHi это можно сделать в ИИ-тренажёре: роль DevOps-инженера, грейд, формат, голос, затем разбор слабых тем.

Шаг 1. Выберите специальность, грейд и формат

В форме укажите категорию DevOps, свою подкатегорию, грейд и тип встречи. Для разговора про Linux и кластер берите технический формат. Так вопросы ближе к поду, пайплайну и инциденту, а не только к рассказу о себе.

Категория и грейд должны совпасть с вакансией. Формат выбирайте под ту встречу, к которой готовитесь: технический разбор стека или разговор с рекрутером.

Шаг 2. Запустите тренировку и отвечайте

В живом прогоне отвечайте голосом, как на встрече с инженером платформы. Экран покажет вопрос. Не читайте шпаргалку вслух. Держите рамку: симптом, что проверите, что не тронете, как откатитесь.

Отвечайте до конца сценария, даже если тема просела. Обрыв на середине оставит вас без разбора именно того блока, который стоило подтянуть.

Шаг 3. Посмотрите результат

После завершения сравните, где ответ был верный по сути, но без структуры. Для DevOps типичные дыры: нет blast radius, сразу рестарт, нет отката, Linux обойден определениями Docker.

Детальный разбор открывается после прохождения: сильные стороны, зоны роста и что повторить. Выпишите слабые темы и прогоните их вслух ещё раз.

Шаг 4. Повторите слабые темы

Не перечитывайте все вопросы подряд. Возьмите две просевшие темы, например CrashLoop и Terraform state, и прогоните короткий сценарий ещё раз.

Как отвечать, когда чинят прод

Как отвечать, когда чинят прод, видно по первой минуте кейса. Слабый ход: сразу назвать Argo, три облака и «пересоздадим ноды». Сильный ход: назвать симптом, blast radius, откат и чем подтвердите, что стало лучше.

Спросите, что видит пользователь. Спросите, был ли релиз, миграция, изменение DNS или квоты. Спросите, что хуже: минута недоступности одного сервиса или широкий рестарт. От этих ответов лечение меняется сильнее, чем от любимого тула.

Дальше держите доказательства. Лог, exit code, метрика, trace. Не лечите «по ощущению график красный». Если условий мало, назовите допущение вслух и идите от него. Инструменты называйте как следствие: откат тега, снять под с балансировки, починить диск, а не наоборот.

Это поведение проверяют именно на интервью DevOps. Здесь не просят красиво спроектировать сервис с нуля. Здесь просят не расширить аварию руками.

Какие вопросы задать про on-call и платформу

Какие вопросы задать про on-call и платформу, лучше собрать под контур, а не взять универсальный список про культуру офиса. Ниже вопросы, которые показывают, как устроены дежурства и выкладка.

• Кто дежурит по платформе, какая ротация и кто второй линии ночью?
• Какой SLO у входа и кто владеет error budget?
• Откуда правда кластера: GitOps, пайплайн, ручной apply?
• Как выглядит откат релиза и кто имеет право его нажать?
• Где секреты и как их ротируют после утечки?
• Какой шум алертов на смене и кто чинит сами правила?

Спросите про последний ночной инцидент и что изменили после него. По ответу видна цена дежурства.