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

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

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

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

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

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

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

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

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

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

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

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

Я всегда стараюсь задавать вопросы про достижения и провалы. Следовательно если кандидат рассказывает про достижения – он наверняка осознает свою полезность для команды и бизнеса в целом. Хорошим примером достижения может быть следующее: “Сделал так, чтобы проект, который падал 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 у них «работает потому что работает», или у команды есть осмысленная операционная модель. Список того, что про кластер стоит знать помимо kubectl, — в листе про контейнеры и оркестрацию.

TL;DR апдейта#

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

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

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

На это всё! Profit!