Как проходит техническое собеседование в ИТ: этапы, кто их ведёт и что оценивают

Типовой цикл найма — 3–5 этапов и 2–6 недель от отклика до оффера. Начинается он со скрининга у рекрутера, заканчивается разговором с нанимающим менеджером. Между ними интервью с инженером, часто live coding, для middle+ и senior — секция по проектированию. На каждом шаге меняется интервьюер, а с ним и предмет оценки: рекрутер сверяет формальные рамки, техлид — глубину стека, менеджер — совместимость с задачами. Сроки, к слову, растянулись: об увеличении длительности найма сообщают 38% ИТ-организаций (данные HR-платформы «Поток»).

Ключевые факты

Чем техническое собеседование отличается от разговора с HR

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

Три разговора в цикле найма легко перепутать, хотя ищут в них разное:

1. HR-скрининг. Мотивация, деньги, формат, сроки выхода. Технологии сверяют по списку, вопросов на понимание нет.

2. Техническое интервью. Стек, архитектурные решения, отладка, качество кода. Ведёт практикующий инженер.

3. Финальное интервью. Задачи, зона ответственности, условия. Решают не «знает ли», а «сработаемся ли».

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

Из каких этапов состоит наём в ИТ и сколько это занимает

Полный цикл обычно укладывается в 2–6 недель. Состав этапов зависит от компании, грейда и роли: у стартапа это один созвон с CTO, у крупного заказчика — пять шагов с согласованиями. Аналитику почти никогда не дают live coding, DevOps редко проходит секцию по алгоритмам. Таблица ниже — типовая конфигурация, длительности в ней практика рынка, а не стандарт.

Публичной статистики по конверсии между этапами в РФ нет: ни одна платформа не раскрывает, какая доля кандидатов отсеивается на скрининге, а какая на секции по коду. Проценты из блогов ничем не подтверждены.

Скрининг у рекрутера

15–30 минут, звонок или короткая видеовстреча. Технических вопросов почти нет, но список технологий сверяют построчно: если в вакансии Kafka, а у вас RabbitMQ, спросят прямо. Стоп-фактор — расхождение по вилке и грейду. Это не провал. Когда ожидания не сходятся, обе стороны экономят пять часов интервью.

Техническое интервью с инженером

60–90 минут, ведёт техлид или сильный разработчик из команды. Структура почти всегда одна: разбор опыта → вопросы по стеку → обсуждение решений из прошлых проектов. Здесь звучит основная часть технических вопросов и принимается большинство отказов.

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

Live coding и тестовое задание

Форматов три: задача в реальном времени с шарингом экрана, домашнее тестовое, разбор чужого кода на code review. Оценивают не только итог — уточнили ли вы условия до того, как начали писать, проговариваете ли гипотезу вслух, как реагируете на наводящий вопрос. Решение, полученное молча, часто оценивают ниже, чем незаконченное, но объяснённое. Стоп-фактор — тишина: интервьюер видит курсор и не видит мышления.

System design — для middle+ и senior

45–60 минут. Дают размытую задачу вроде «спроектируйте хранение и отдачу изображений на 10 млн пользователей» и смотрят, что дальше. Правильного ответа нет, и это принципиально: проверяют работу с неопределённостью — какие вопросы вы задаёте про нагрузку, какие компромиссы выбираете между хранением, отказоустойчивостью и ценой. Стоп-фактор — начать рисовать схему, не спросив о требованиях.

Финал с нанимающим менеджером и командой

30–60 минут: задачи ближайших месяцев, зона ответственности, устройство команды, условия. Решение принимают про сработаемость, и ваши вопросы весят здесь столько же, сколько ответы.

Кто сидит по ту сторону экрана и что нужно каждому из них

За одним процессом стоят четыре роли с разными критериями. Контекст у всех сейчас жёсткий: по данным «Потока», уровень закрытия вакансий не превышает 55–60%, об увеличении сроков найма говорят 40% отечественных компаний, при этом 64% работодателей отмечают нехватку ИТ-специалистов. Вакансий стало меньше — с начала 2025 года их количество сократилось на 22%, в 2026 году открытых позиций примерно на 35% меньше, чем в 2025, в Санкт-Петербурге спрос упал примерно на 40% год к году.

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

Что оценивают на самом деле: три слоя за одним разговором

За техническим разговором идёт оценка по трём слоям, и технический уровень из них не главный.

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

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

Совместимость. Коммуникация, реакция на критику, поведение под давлением. Проверяется всем ходом разговора.

Отдельно про «не знаю». Ответ «не работал с этим, но разбирался бы так: посмотрел документацию по транзакциям, потом воспроизвёл на тестовом стенде» — рабочий, а не провальный. Попытку закрыть незнание выдумкой считывают почти всегда: следующий уточняющий вопрос обрушивает конструкцию. Незнание стоит одного минуса в строке. Выдумка — доверия ко всему интервью.

Вопросы на техническом собеседовании: что стоит за типовыми формулировками

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

Три формулировки понимают неправильно чаще всего.

«Расскажите о проекте». Это не просьба пересказать README: интервьюер восстанавливает вашу настоящую роль. Помогает жёсткая схема — задача → решение → отброшенные альтернативы → результат в измеримых величинах. «Мы переписали сервис на Go» не даёт ничего. «Я вынес расчёт скидок в отдельный сервис, потому что он держал транзакцию 40 секунд и блокировал оформление заказа; после выноса оформление стало занимать 3 секунды» даёт сразу всё: контекст, роль, причину, результат.

Вопрос по алгоритмам. Секцию ругают заслуженно: в проде редко пишут обход графа руками. Но проверяют ей не знание обхода, а умение оценить стоимость решения и предложить размен памяти на время. Проговорённое вслух «здесь O(n²), можно свести к O(n) через словарь, но вырастет расход памяти — для наших объёмов приемлемо» весит больше, чем молча написанный идеальный код.

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

Почти всегда есть «вопрос-щуп» на границу знания: интервьюер уходит вглубь, пока вы не скажете «дальше не знаю». Это калибровка грейда, а не попытка вас утопить. Встречный уточняющий вопрос идёт в плюс: спросивший «речь про распределённую систему или про один инстанс?» показал, что видит разницу.

[Вставка: что интервьюеры iFellow хотят услышать за этими формулировками. Данных от команды подбора нет, разбор выше — типовая отраслевая практика.]

Собеседование в аутсорс и аутстафф: почему кругов два

При найме в аутстафф-модель кандидат проходит два круга интервью: сначала у вендора, затем у заказчика, на проект которого его предлагают.

Аутстаффинговая компания анализирует компетенции кандидата по hard и soft skills и передаёт заказчику шортлист из 2–3 претендентов. На заключительной стадии кандидат проходит у заказчика собеседование по технической части и проверку на соответствие корпоративной культуре. Вендор смотрит общий уровень и договороспособность, заказчик — соответствие проекту и стеку.

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

Что это меняет практически. Процесс растягивается: между кругами проходит неделя и больше, опыт приходится рассказывать дважды — второй раз под конкретный проект. Зато вендор заинтересован в том, чтобы вы прошли: он объясняет контекст заказчика, готовит ко второму кругу и даёт фидбэк. Техническое собеседование в IT-аутстаффе устроено сложнее, но информации у кандидата больше.

[Вставка: как устроены два круга у iFellow — что смотрит команда, интервал между кругами, формат фидбэка перед интервью у заказчика.]

ИИ на собеседовании: что происходит в 2026 году

Использование ИИ кандидатом прямо во время интервью остаётся серой зоной: единой нормы рынок не выработал. По публикации РБК от 14 января 2026 года кадровики сообщают о случаях, когда позиции разработчиков получали люди без базовых навыков программирования — ИИ помогал им на этапе тестирования. Есть и отдельный класс инструментов, interview copilots, подсказывающие ответы по ходу разговора.

Компании реагируют по-разному. Одни запрещают и вводят прокторинг — наблюдение за экраном и камерой. Другие допускают подсказчиков при условии, что кандидат объясняет каждую строку. Третьи не регламентируют вовсе.

Формат интервью на это уже отреагировал:

• вопросы всё чаще касаются кода самого кандидата и его личного опыта — того, чего нет в интернете;

• вернулись задачи с обсуждением вслух: интервьюеру нужен процесс, а не результат;

• после каждого ответа идёт углубляющее «почему так, а не иначе» — сгенерированный ответ ломается на втором уточнении;

• разбор чужого кода вытесняет написание своего.

Вывод неприятный, но честный: подсказка помогает пройти этап и мешает пройти испытательный срок.

[Вставка: позиция iFellow по использованию ИИ на интервью и способ проверки. Без неё раздел публиковать не рекомендуется.]

Как пройти техническое собеседование: подготовка, которая работает

Гарантий не даёт никто. Но подготовка меняет то, что вы контролируете: качество рассказа о своём опыте и скорость реакции на непривычный формат.

1. Разберите 2–3 своих проекта по схеме «задача → решение → альтернативы → результат в цифрах». Это закрывает половину технического интервью сразу. Проговорите вслух и засеките: связный рассказ укладывается в 3–4 минуты.

2. Восстановите базу по стеку — по слабым местам, а не подряд. Выпишите технологии из вакансии и отметьте те, где вы «использовал, но не объясню». Туда и пойдёт вопрос-щуп.

3. Прогоните live coding вслух. Решать задачу молча вы умеете. Комментировать ход мысли под чужим взглядом — отдельный навык, и тренируется он только повторением. Подойдёт mock-интервью с коллегой.

4. Подготовьте 4–5 вопросов к компании. Состав команды, техдолг, процесс релизов, критерии успеха на испытательном сроке. Вопрос про код-ревью даёт информацию и работает как сигнал вовлечённости.

5. Отрепетируйте признание незнания. Заготовленная фраза «с этим не работал, разбирался бы так-то» снимает панику, когда вопрос уходит за границу опыта.

6. Проверьте технику накануне. Камера, микрофон, шаринг, среда для кода, запасной канал связи. Двадцать минут из шестидесяти на настройку звука — минус ваше время.

7. Сверьте вилку до первого созвона. Расхождение по деньгам — типовой стоп-фактор скрининга, и узнать о нём на пятом этапе обиднее, чем на первом.

Чего делать не надо — заучивать наизусть готовые вопросы на техническом собеседовании вместе с ответами. Заученное слышно: оно звучит гладко ровно до первого уточнения.

Пять ошибок, из-за которых отказывают сильным кандидатам

1. Молчание во время задачи. Оценивать нечего, кроме итогового кода: раздел «мышление» в форме остаётся пустым даже при верном решении.

2. Выдуманный ответ вместо «не знаю». Уточняющий вопрос вскрывает выдумку, и под сомнение попадает всё сказанное раньше.

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

4. Спор вместо уточнения. «Вы неправы» против «возможно, мы про разные сценарии — вы имеете в виду распределённый случай?». Первый вариант даёт минус по коммуникации, который часто весит больше технических плюсов.

5. Нет вопросов к компании. Читается как безразличие. На финале, где сравнивают мотивацию двух похожих кандидатов, это ощутимо.

Частые вопросы о техническом собеседовании

1. Сколько этапов и сколько времени занимает наём?

   Типовая структура — 3–5 этапов, полный цикл от отклика до оффера занимает 2–6 недель и зависит от компании, грейда и роли. Сроки в 2025–2026 годах выросли: об увеличении длительности найма сообщают 40% российских компаний и 38% ИТ-организаций (исследование HR-платформы «Поток»).

2. Что делать, если вопросы на техническом собеседовании уходят за границу опыта?

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

3. Можно ли пользоваться поиском и ИИ во время интервью?

   Единой нормы на рынке нет. Часть компаний вводит прокторинг и запрещает подсказчиков, часть допускает их с условием объяснять каждое решение. По публикации РБК от января 2026 года есть случаи найма разработчиков без базовых навыков, прошедших тестирование с помощью ИИ, — из-за этого требования ужесточаются. Спросите о правилах у рекрутера до интервью.

4. Чем отличается собеседование в аутстафф от продуктовой компании?

   Кругов интервью два вместо одного: сначала у вендора, затем у заказчика, которому вендор передаёт шортлист из 2–3 кандидатов. Процесс дольше, опыт приходится рассказывать дважды. Взамен вендор готовит ко второму кругу и даёт обратную связь.

5. Дадут ли обратную связь после отказа?

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

6. Как понять, на какой грейд претендовать?

   Ориентир — отраслевая логика грейдирования: hard skills оценивают от «не знаю, не слышал» до «могу научить другого», soft skills — от «не выражено» до «применяет в нестандартных ситуациях». Middle решает типовые задачи самостоятельно, senior отвечает за архитектурные решения и за чужой код.