Собеседование DevOps junior: что проверяют на интервью и как отвечать

Что смотрит интервьюер на junior-уровне

От джуна не ждут, что он в одиночку поднимет кластер. Проверяют фундамент: понимаете ли вы связь между приложением, сервером и сетью и видите ли разницу между «поправить сейчас» и «поправить так, чтобы не сломать остальное».

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

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

Карта тем: что спрашивают почти всегда

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

Linux и процессы. Вопросы по Linux здесь про нагрузку, память, права, systemd и логи. Спрашивают не «что делает chmod», а «почему сервис не поднялся после перезагрузки». То есть спрашивают про поведение системы, а не про список команд.

Сети и DNS. Порты, HTTP-коды, диагностика: ping, traceroute, curl. Рабочий сценарий — «сайт недоступен, где искать причину».

Docker. Образ и контейнер, слои, volumes, сети, разница между одиночным запуском и compose. По этой теме на платформе больше всего вопросов: 43.

CI/CD. Зачем нужен пайплайн, что происходит между коммитом и продом, где живут секреты, как откатывается релиз.

Kubernetes. База: pod, deployment, service, логи и события. От джуна ждут понимания этих объектов, а не проектирования отказоустойчивого кластера.

Облака и автоматизация. Базовые понятия инфраструктуры: виртуальная машина, сеть, диск, балансировщик. Плюс скрипты на bash или Python для рутинных задач.

Пять вопросов, на которых чаще всего сыпятся

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

1. Процесс съел процессор. Что будете делать?

Проверяют не команду, а порядок действий на живом сервере. Слабый ответ: «убью процесс и перезапущу сервис».

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

2. Сайт недоступен. С чего начнёте?

Здесь смотрят на умение сужать область поиска. Слабый ответ: «проверю, работает ли сервер».

Сильный ответ идёт по слоям: резолвится ли имя, отвечает ли порт, слушает ли служба, отвечает ли приложение. На каждом шаге вы объясняете, что именно проверяете и какой вывод из этого следует. Такой ответ показывает, что вы чинили такое руками, а не читали о диагностике.

3. Чем образ Docker отличается от контейнера?

Вопрос из категории «могут спросить каждого». Слабый ответ — определение из документации, после которого разговор останавливается.

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

4. Что происходит в пайплайне после merge в main?

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

Сильный ответ разбирает этапы и их смысл: сборка артефакта один раз, тесты, публикация, доставка на окружение. Отдельно — секреты (в переменных CI, не в репозитории) и откат: к какой версии и как вернуться, если релиз сломался. Такой ответ показывает, что пайплайн для вас — процесс с предсказуемым результатом, а не кнопка.

5. Pod перезапускается по кругу. Ваши действия?

Слабый ответ: «перезапущу деплой и посмотрю». В Kubernetes это ничего не лечит.

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

Как подготовиться, если интервью уже скоро

Списки вопросов читать можно, но проверять себя лучше практикой. Тесты по Docker, Kubernetes и Linux показывают пробелы точнее самооценки: знакомую формулировку мозг узнаёт и записывает в «знаю», а тест проверяет применение.

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

На ExplainIf по DevOps-темам есть и тесты по уровням, и режим интервью: ИИ задаёт вопросы с таймером, а после сессии показывает разбор по критериям: точность, полнота, структура ответа, коммуникация. Тренажёр не заменит живого интервьюера, но честно покажет, где у вас пробелы.

Порядок повторения — слоями: Linux и сети, затем Docker, потом CI/CD, и уже потом Kubernetes. Так база усваивается спокойнее, чем при попытке охватить всё сразу.

Частые вопросы