Десять типовых вопросов про Docker все чаще становятся не формальностью, а быстрым фильтром на техническом интервью. Для русскоязычного рынка это сигнал простой: Docker на собеседовании перестал быть проверкой на знание команд и превратился в разговор о том, понимает ли кандидат, как вообще устроена контейнеризация.
Об этом сообщает Habr / Карьера в материале про 10 главных вопросов, которые задают кандидатам на позиции бэкенд-разработчиков, DevOps-инженеров и QA. Сам набор тем показателен сам по себе. Интервьюеров уже мало интересует человек, который помнит синтаксис docker run, но плавает в базовых вещах: чем контейнер отличается от виртуальной машины, куда исчезают данные после перезапуска, зачем нужны тома, почему контейнер останавливается вместе с главным процессом и как Compose упрощает жизнь в многоконтейнерных проектах.
Фактически речь идет о смене уровня ожиданий. Docker давно прошел стадию модного пункта в резюме. Для части рынка это уже такой же базовый слой, как Git, Linux или работа с CI/CD. Поэтому логика найма стала жестче: если кандидат пишет, что умеет в Docker, его спрашивают не про список флагов, а про архитектуру. Например, про различие между виртуальными машинами и контейнерами. Здесь работодатель хочет услышать не рекламную формулу про «легковесность», а нормальное инженерное объяснение: контейнеры используют механизмы ядра ОС, изоляцию процессов и ограничения ресурсов, а не тянут за собой отдельную гостевую систему для каждого экземпляра. Это важно не для красного словца, а потому что из этого вытекают и скорость старта, и плотность размещения, и ограничения по среде запуска.
Не менее показателен блок про образ и контейнер. На бумаге разница выглядит школьной: образ статичен, контейнер запускается из образа. На практике именно здесь часто видно, кто работал с Docker всерьез, а кто просто однажды поднял локальную базу под проект. Если человек не может объяснить, что контейнер получает временный слой записи поверх неизменяемого образа, дальше неизбежно начинаются типичные аварии уровня «после пересоздания контейнера все пропало». Для нанимающей стороны это красный флаг: такой специалист может без злого умысла уронить данные, перепутать ответственность образа и runtime-среды или собрать систему, которая красиво стартует на демо, а потом рассыпается при первом обновлении.
Отдельный пласт вопросов касается Dockerfile и того, как именно запускается приложение внутри контейнера. Снаружи это выглядит как мелкая придирка про CMD и ENTRYPOINT, но на деле вопрос проверяет взрослость инженерного мышления. Если кандидат понимает разницу между фиксированной точкой входа и параметрами по умолчанию, он, скорее всего, умеет проектировать образы так, чтобы они были предсказуемыми и удобными в эксплуатации. Если нет, дальше появляются контейнеры, которые ведут себя как черный ящик: их сложно переиспользовать, неудобно дебажить и легко сломать неосторожным аргументом в команде запуска. Для команды это уже не теоретическая проблема, а вполне прикладная стоимость поддержки.
Еще один важный маркер в статье — вопросы про хранение данных и разницу между volumes и bind mounts. Именно здесь Docker на собеседовании быстро отделяет тех, кто понимает жизненный цикл приложения, от тех, кто привык жить в happy path локальной разработки. Тома нужны, когда данные должны пережить контейнер и не зависеть от его удаления. Привязка директории хоста удобна для разработки, когда код должен мгновенно обновляться внутри контейнера, но в продакшене такая практика легко превращает переносимый артефакт в систему, привязанную к структуре папок на конкретном сервере. Для бизнеса разница тоже не академическая: ошибка в этой зоне стоит данных, времени на восстановление и вполне реальных денег на простой.
Compose в этом наборе тем тоже оказался не случайно. Базовые команды Docker достаточно быстро заканчиваются там, где начинается реальное приложение с базой, кэшем, очередью и отдельным сервисом API. Умение описать многоконтейнерную систему в одном файле и поднимать ее одной командой для работодателя означает не только технический комфорт кандидата, но и его пригодность к командной разработке. Человек, который понимает Compose, обычно быстрее воспроизводит окружение, меньше спорит с коллегами в стиле «у меня локально работает» и проще встраивается в процессы онбординга и тестирования. Это особенно заметно в небольших продуктовых командах и стартапах, где нет роскоши держать отдельного человека на каждую инфраструктурную мелочь.
Пожалуй, самый неприятный для неподготовленных кандидатов вопрос — почему контейнер завершается, если внутри умирает основной процесс. Здесь заканчивается магия и начинается нормальная модель Unix: контейнер живет ровно столько, сколько живет его PID 1. Если специалист этого не понимает, он может долго лечить несуществующие «сбои Docker» там, где на самом деле просто завершился главный процесс приложения. Для интервьюера это удобная проверка на то, видит ли человек под красивой оберткой Docker обычные процессы, сигналы и правила их жизни. И именно таких проверок на рынке становится больше: не на знание бренда, а на понимание механики.
Из этого следует неприятный, но здоровый вывод для соискателей и команд. Docker на собеседовании больше не дает очков сам по себе, как строчка в резюме или значок в профиле. Теперь он работает как лакмусовая бумажка инженерной зрелости: понимает ли человек изоляцию, хранение состояния, сборку образов и модель запуска процессов, или просто умеет копировать команды из README. На фоне усложнения стека это, вероятно, только начало. Следующим обязательным уровнем для многих ролей станет уже не сам Docker, а связка контейнеров с CI/CD, безопасностью образов и воспроизводимостью окружения без шаманства в терминале.