Собеседования в IT: записи на разные грейды и вопросы

Сначала сами собеседования

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

DevOps собеседование в VK: реальные кейсы и вопросы Собеседование DevOps на 450к: вопросы, ошибки и оффер Техническое собеседование DevOps: как войти в айти Собеседование на Технического Директора / MLOps MLOps собеседование: вопросы про RAG и LLM Специально завалил все тех вопросы на собесе

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

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

Разные грейды, компании и интервьюеры

Senior в названии вакансии ещё не означает, что на собесе будут спрашивать что-то невероятное. Иногда вопросы оказываются гораздо проще, чем ты себе представлял. Посмотри запись и попробуй ответить сам: возможно, часть этого ты давно знаешь, пока откладываешь следующий шаг.

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

А бывает, напротив сидит прожжённый DevOps с большим опытом. Тогда за первым ответом идут уточнения: почему сделал так, где решение сломается, что проверишь при аварии. Здесь уже сложнее. Дело не в названии должности интервьюера, а в том, насколько глубоко он знает тему и как собеседует.

Поэтому не суди обо всех собесах по одному сложному или провальному интервью. На одну и ту же роль в другой компании могут спрашивать совсем иначе. Неудача в одном месте не означает, что ты нигде не пройдёшь на этот уровень.

Я бы смотрел несколько записей и останавливал видео перед ответом. Что можешь объяснить сам? Где не знаешь термин, а где не понимаешь саму задачу? Какие уточнения уже ставят в тупик? По одной записи грейд себе не присвоишь, но она помогает увидеть, что уже получается. Дальше — откликаться и пробовать самому, а не ждать идеальной готовности.

Почему я не делаю культ из этапов найма

Резюме, HR, техсобес, руководитель, оффер — знакомая последовательность. Но это не обязательный ритуал. На канале есть оффер на 500К после одного этапа. Есть более длинные разговоры. Я бы в начале спрашивал, сколько встреч предполагается и что происходит после каждой.

Для меня имеет значение и цена процесса в собственном времени. Несколько этапов ради понятной интересной работы — одна история. Бесконечные созвоны, после которых всё ещё неясны деньги и обязанности, — другая. Компания оценивает кандидата, но кандидат не обязан отключать свою оценку компании.

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

Что я обсуждаю с HR

Если впереди первый созвон, начни с разбора HR-собеседования в IT: рассказ о себе, причины перехода, деньги и вопросы к работодателю. Ниже — коротко о моём подходе.

Я не искал компанию мечты. Меня интересовали деньги, формат и то, сколько работы за этим стоит. Поэтому мне не близка рекомендация сочинять глубокую любовь к каждому продукту, на вакансию которого откликнулся.

Рассказать о себе полезно по делу: какой опыт относится к роли, что хочешь делать дальше, какие условия рассматриваешь. Если причина перехода — зарплата или удалёнка, её не обязательно переодевать в «потребность в новых вызовах».

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

Как это выглядит без идеального сценария — запись моего скрининг-интервью на DevOps. Посмотри, как из общего разговора вырастают вопросы про конкретный опыт.

Что я проверяю перед техническим этапом

Вопросы на техсобесе не всегда совпадают с тем, что предстоит делать на работе. Иногда спрашивают определения, иногда предлагают разбирать ситуацию, иногда глубоко копают одну строчку резюме. Поэтому я разделяю умение работать и умение объяснять свою работу на собеседовании. Второе тоже приходится тренировать.

Я бы начал с версии резюме, которую отправил. Если там Kubernetes, Terraform и автоматизация — надо быть готовым говорить именно об этом. Не весь стек в мире, а то, на что сам пригласил вопросы.

• Могу объяснить задачу без перечня модных названий?
• Понимаю, почему выбрал решение и где оно не подходит?
• Если уточнят про ошибку или восстановление, есть что сказать?
• Могу отдельно назвать, что делал сам, а что было уже готово?

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

Какие темы повторяются

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

Можно сравнить это с техническим интервью на английском. Термины знакомые, а необходимость объяснять всё на другом языке меняет ощущение от разговора. Мой опыт работы с этим стеком — в статье про DevOps.

Банки вопросов по ролям

Большую часть этих вопросов задавали мне на собеседованиях. Есть и дополнительные общие вопросы для подготовки. Я разложил их по темам и добавил разборы ответов: это не обещание получить тот же список на следующем интервью и не дословная расшифровка каждого видео.

• DevOps — Linux, сети, контейнеры, CI/CD, инфраструктура и рабочие ситуации.
• SRE — надёжность, SLI/SLO, error budget, дежурства и разбор инцидентов.
• MLOps — модели и данные, инференс, дрейф, LLM и RAG.
• DevSecOps — секреты, права, пайплайны, зависимости и уязвимости.
• AIOps — телеметрия, аномалии, алерты и автоматизация эксплуатации.
• Linux-администратор — процессы, файловые системы, сеть и диагностика.

Я бы выбирал не самый длинный банк, а ближайший к вакансии. Отвечать полезнее своими словами. Если можешь повторить готовый абзац, но не выдерживаешь уточнение «почему?», тему ещё стоит разобрать.

Если ответа нет

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

«С этим не работал, но начал бы проверять вот отсюда» — нормальное начало, если дальше есть мысль. Не гарантия оффера и не способ обойти любой вопрос. Если же начинаешь уверенно нести случайные слова, следующее уточнение только усложняет положение.

В эксперименте с намеренно заваленными вопросами можно посмотреть на сам разговор. Я не публикую его как инструкцию ничего не знать. Мне важно показать: неудачный ответ случился, а жизнь на этом не закончилась.

Не делать ставку на один собес

Что делать перед интервью, если страшно, как продолжить разговор после неудачного ответа и что разобрать после отказа — собрал отдельно. Здесь не нужно ни обещать себе оффер, ни заранее назначать провал.

Когда одна компания объявлена последним шансом на нормальную жизнь, на собеседование приходишь уже с лишним грузом. У меня были 23 компании и много интервью. Именно этот масштаб помогает не превращать отдельный отказ в заключение обо мне как о специалисте.

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

Но и чужое время, свои нервы, повторный отклик в ту же компанию — реальные вещи. Поэтому «вообще без риска» я бы это не называл. Можно сначала проговорить ответы самостоятельно или на пробном интервью. Главное — не назначать себе бесконечную подготовку вместо попыток.

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

Моё собеседование с ИИ

У меня есть запись собеседования с ИИ вместо HR. Это конкретный опыт нового формата, а не доказательство, что теперь все компании нанимают одинаковыми ботами.

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

Если готовишься к самому первому интервью, последовательный разбор есть на Dev0pser. Если уже работаешь и собеседуешься ради новых условий — на IT-Para. А здесь главное можно увидеть самому: записи, вопросы и мои попытки, а не образ безошибочного эксперта.

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