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

Привет, %username%! Нам не редко приходится искать работу и проходить собеседования. Главное что многие забывают – собеседование это процедура в обе стороны.

🔄 Обновлено 2026-05-15: тело поста не трогал — основной список вопросов до сих пор работает. В конце добавил раздел «Вопросы для 2026»: про работу с ИИ-инструментами, FinOps и реальную операционку Kubernetes.

Собеседование проходить нужно, важно и полезно. Как минимум потому, что тренируется навык прохождения интервью (ваш Кэп). Но основная тема о которой я хочу поговорить – вопросы. Вопросы, которые стоит задавать на интервью, чтобы понять подходит ли конкретно тебе эта компания так же как и ты ей.

Типичное собеседование#

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

Типичная схема проведения технического интервью на “около Ops”:

• Тебе рассказывают о текущем стеке технологий или проекте над которым придется работать;
• Ты рассказываешь о своем последнем опыте, достижениях и провалах;
• Тебе задают технические и не очень вопросы;
• Ты задаешь свои вопросы интервьюерам;

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

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

Расскажите о своем последнем месте работы?#

Как интервьюер я обычно стараюсь задавать вопрос не только про общее описание: с чем работал, какие задачи выполнял, какими тулами пользовался?

Я всегда стараюсь задавать вопросы про достижения и провалы. Следовательно если кандидат рассказывает про достижения – он наверняка осознает свою полезность для команды и бизнеса в целом. Хорошим примером достижения может быть следующее: “Сделал так, чтобы проект, который падал 2-3 раза в неделю перестал падать. Причины падения были такие-то. Исправил вот так вот”

Также стоит рассказать о провалах, которые были в работе. Это как минимум покажет, что ты осознаешь последствия своих ошибок и способен их исправить. К примеру я обычно рассказываю о том, как уронил Oracle DB развернутую в единственном экземпляре и от которой зависело абсолютно всё. После чего я таки смог ее восстановить. С техдиром компании мы поискали решение, которое позволило избежать подобных инцидентов.

Еще одним не маловажным моментом является то, что стоит рассказать о том чего не особо знаешь или с чем очень плохо получается в рамках предлагаемой вакансии. Стоит рассказывать именно то, в чем плаваешь так сказать. Например в 99% случаев на всякие DevOps/Linux Admin в требованиях указано: “Отличное знание сетей и модели OSI”. Я например очень так себе разбираюсь в модели OSI и постоянно путаю уровни. И в целом по сетям я довольно таки плаваю. И тем не менее, я не стесняюсь об этом говорить как минимум потому, что у интервьюера уже сразу будет формироваться вектор вопросов: вдруг он планировал задавать вопросы по сетям, а я уже сразу на них ответил (немного не так конечно, но ответил).

Рассказать про то, чего не знаешь дает огромное преимущество про которое многие забывают: дальнейшие вопросы будут именно по темам, которые ты знаешь! А тут уж у тебя есть место для манёвров – ты же знаешь эти темы хорошо или на достойном уровне.

Технические вопросы#

Тебе интервьюер(ы) задает вопросы по технологиям и тулам основываясь исключительно на твоем резюме. Ну не совсем исключительно, окай. В преимущественном большинстве случаев вопросы интервьюера зависят напрямую от двух вещей:

1. Что написано в описании вакансии;
2. Что написано в резюме кандидата;

Есть такие компании, интервьюеры которых прям основательно готовятся к собеседованию (привет “Express 42” ). Ребята не просто проштудировали мое резюме - это слишком просто и занимает 3-5 минут перед собесом. Они ознакомились с содержимым этого блога, изучили мой профиль на GitHub , на котором они нашли репозитории с моими ansible-ролями. И знаете что? Это чертовски круто, когда тебе задают предметно вопросы: “Вот тут ты сделал именно так. Поясни почему именно так и как можно сделать лучше?”

У тебя с интервьюером общий язык на котором вы оба говорите и оба понимаете. Я могу порекомендовать со своей стороны лишь одно: веди свой GitHub/GitLab профиль! Указывай ссылки на свой профиль в резюме! Это будет играть тебе на руку в дальнейшем как минимум тем, что можно будет показывать примеры своих наработок. Те кто сейчас подняли ведра с помидорами чтоб меня закидать – остыньте! Я не говорю о том, что нужно брать и как есть выкладывать на GitHub все свои наработки. Я к примеру сделал некоторое количество ansible-ролей, в максимально унифицированном виде – их можно применить к чему угодно.

Задавай свои вопросы#

Вот тут стоит хорошенько подумать и я попробую в первую очередь для себя сформировать чек-лист с теми вопросами, которые стоит задавать на техническом собеседовании. Этот этап интервью кандидат очень часто стесняется – “Как я буду задавать вопросы? Они ж вон какие большие и крутые!”

А задавать вопросы стоит! Потому что интервью – это в первую очередь диалог! Компания оценивает насколько хорошо ты впишешься в команду, а ты должен понять подойдет ли тебе эта команда, проект, компания.

Собственно вот такой список вопросов как мне кажется надо задавать интервьюерам на данном этапе собеседования:

• Как выглядит типичный рабочий день?
• Что необходимо для того, чтобы стать действительно успешным на этой должности?
• Какие виды навыков отсутствуют в команде, которые вы хотите получить, наняв нового сотрудника?
• Какие самые большие проблемы, с которыми предстоит столкнуться человеку на этой позиции?
• Предполагаете ли Вы, что основной круг обязанностей для этой должности изменится в ближайшие полгода-год?
• Имеются ли дежурства или овертаймы? Насколько часто? Как и кем составляется график дежурств? Как они компенсируются?
• Сколько человек в команде? Как организована коммуникация внутри команды и между смежными командами?
• Имеются ли токсичные люди в команде куда я иду?
• Какие учебные программы доступны для ваших сотрудников?
• Какие существуют возможности карьерного роста и профессионального развития?
• Кому я должен буду отчитываться? Какова координация в команде? Имеется ли тайм-трекинг? Кто отвечает за постановку задач?
• На сколько сложно уйти в отпуск в любой момент времени (вне зависимости от задач/пожаров на проекте) просто написав заявление за 2 недели?
• Есть ли bus-фактор на позициях коллег, с которыми мне предстоит работать?
• Как обстоят дела с выделением времени на инкремент документации? Как в целом обстоят дела с документацией?
• Есть ли шеринг опыта в команде? Внутренние митапы или иные регулярные встречи с участием Ops, Dev и QA?
• Есть ли инженер безопасности? Если ли понимание DevSecOps в команде?
• В случае изменения архитектуры инфраструктуры кто принимает решения?
• Будет ли выделена рабочая техника? В т.ч. из соображений безопасности.
• Обучение английскому? Участие в конференциях как спикер или доступ к докладам сотрудников/коллег на каких-либо конференциях?
• Смогу ли я представлять компанию на отраслевых конференциях?
• С кем из менеджерского состава предстоит взаимодействовать? Как сильно они погружены в IT в целом, в продукт, в технологию?
• Гибкость начала и конца рабочего дня? На сколько просто при необходимости сдвинуть рабочий день, чтоб начать позже и закончить позже, но выполнив задачи?
• Есть ли ретроспективы? Ведутся ли постмортемы?
• Какие наиболее важные вещи, по вашему мнению, я должен буду сделать за первые 30, 60 и 90 дней работы?
• По каким показателям моя деятельность будет оцениваться?
• Планируете ли вы нанимать ещё людей в это подразделение в ближайшие шесть месяцев?
• С какими подразделениями компании придется взаимодействовать чаще всего?
• Можете ли вы рассказать мне о последнем совместном командном мероприятии?
• Насколько, по вашему мнению, моя квалификация соответствует данной роли?
• Как устроено обучение сотрудников?
• Есть ли правила коммуникации?
• Сталкивались ли с выгоранием сотрудников и что делали в этой ситуации?

Думаю на этом можно закончить. По мере необходимости буду стараться обновлять данный список вопросов.

Вопросы для 2026#

Пост написан в середине 2021-го. Рынок и стек с тех пор поменялись — добавляю три блока вопросов, без которых сейчас разговор про работу про-уровня уже не клеится.

Работа с ИИ-инструментами#

Если в команде кто-то говорит «мы LLM не используем» — это либо неправда, либо повод задуматься о технологическом отставании. Что имеет смысл спросить:

• Используют ли разработчики Copilot/Claude Code/Cursor/Codeium на ежедневной основе? Платит ли компания за лицензии?
• Есть ли политика по работе с ИИ: что можно отправлять в облачные LLM, что нельзя, какие данные считаются sensitive?
• Используются ли agentic-инструменты (например, инструменты с MCP-серверами) для рутинных операционных задач — миграций, ревью PR, инцидент-ассистенты?
• Есть ли self-hosted LLM (vLLM, Ollama, llama.cpp) для задач, которые в облако отдавать нельзя?
• Как в команде смотрят на «vibe coding» и где проходит граница между «LLM написал, мы приняли» и «инженер написал, LLM помог»?

Ответы покажут, насколько компания осознанно работает с инструментами, а не «слышали, что есть Copilot — не пользуемся».

FinOps#

Если облако (или гибридная инфра) — обязательно спроси:

• Кто отвечает за оптимизацию инфра-расходов? Это отдельная роль (FinOps-инженер) или размазано по команде?
• Есть ли cost-теги на ресурсах? Видит ли каждая команда свой расход в дашборде?
• Используются ли spot-инстансы, savings plans, reserved capacity? Кто принимает решение?
• Есть ли регулярные FinOps-ревью (например, раз в квартал) и rightsizing-кампании?
• Какая доля бюджета уходит на k8s-кластеры vs managed-сервисы vs storage?

Если ответы плавающие — скорее всего инфра растёт быстрее выручки, и это сигнал.

Kubernetes-операционка (а не теория)#

В 2021-м спрашивали «что такое Pod и Service». Сейчас если на тебя смотрят так, как будто это и есть единственный k8s-вопрос — это плохо. Полезнее спросить про реальную операционку:

• Как вы дебажите упавший Pod в проде? Что в первую очередь смотрите?
• Какая стратегия выкатки: rolling, blue/green, canary? Через что управляется (Argo Rollouts, Flagger, vanilla deploys)?
• Как организован доступ к кластеру: kubeconfig у каждого инженера, или через bastion/Teleport/SSO?
• Есть ли GitOps (Argo CD, Flux)? Кто пишет манифесты — разработчики или платформенная команда даёт темплейты?
• Что с network policy и multi-tenancy? Все сервисы в одном namespace, или есть изоляция?
• Кто отвечает за обновления control plane и worker-нод? Какая частота патч-окон?

Ответы дадут понять, kubernetes у них «работает потому что работает», или у команды есть осмысленная операционная модель.

TL;DR апдейта#

Три темы, без которых в 2026-м серьёзный разговор уже не получится: ИИ в ежедневной работе, FinOps как осознанная функция, k8s как операционная модель, а не набор YAML’ов. Если на эти вопросы у компании нет внятных ответов — это не криминал, но повод подумать, готова ли она расти.

Главное, что необходимо помнить во время интервью (ну и в период испытательного срока) это то, что не только компания оценивает тебя как специалиста, но и ты оцениваешь компанию – нравится ли тебе то, чем занимается компания, устраивает ли тебя команда в которую ты идешь, интересен ли стек технологий и т.д.

ЗЫЖ Пример тех вопросов, которые реально глупые или слишком заезженные можно найти в Собеседовании без купюр .

На это всё! Profit!

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .

О способах отблагодарить автора можно почитать на странице “Донаты ”.