Техническое собеседование: как его провести и правильно оценить кандидата?

Рекрутеры пишут тексты вакансий и отбирают резюме с помощью нейросетей, кандидаты готовят ответы и даже решают задачи с подсказками ИИ, а многие ИТ-компании в 2025 году снова стали проводить интервью офлайн. В этой новой реальности старые подходы к собеседованиям теряют эффективность: проверка теории «по учебнику» или стандартный список вопросов не дают объективной картины. Сегодня важно уметь видеть за готовыми ответами реальные навыки, ход мысли и то, насколько человек подходит под конкретный проект.

Привет, VC! Меня зовут Никита Королев, я ведущий разработчик мобильных приложений в IBS. Я регулярно провожу собеседования и сегодня хочу поделиться своим видением того, как делать это эффективно для компании и без нервотрепки для обеих сторон.

Когда я устроился в IBS, в нашем отделе мобильной разработки уже был план собеседований, составленный другим тимлидом. Я добавил в него пару деталей, но в целом структура оставалась неизменной до середины 2024 года.

Техническая часть собеседования на Flutter-разработчика длилась час и включала в себя такие этапы:

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

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

С кодом ситуация интереснее. Раньше на собеседованиях давали задание написать код на бумаге, и многие разработчики, включая меня, побаивались этого этапа. Сегодня я бы рекомендовал комбинировать два этапа: сначала решение на бумаге, потом в IDE с любыми помощниками. И показательна тут будет не только разница в качестве решения, но и в затраченном времени. Не стоит ставить крест на человеке, не решившем задачу на бумажке, в конце концов, в работе он будет пользоваться помощниками. Здесь гораздо важнее верный ход мысли.

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

Я выделил шесть шагов:

Теперь пройдемся по каждому пункту подробнее.

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

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

Уже не раз сталкивался с ситуацией, когда описание вакансии полностью пишет рекрутер без участия технических специалистов. На мой взгляд, HR-отделу можно доверить только «продающую часть» и бонусы, а вот за требования должен отвечать технарь. Для каждого отдела можно создать базовое описание вакансии с помощью ИИ, а далее адаптировать требования вручную под проект и заверять у руководителя или заказчика.

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

Пожалуй, самый сложный и неоднозначный этап. Я бы разделил его на три части:

1. Список базовых знаний и хард-скилов

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

Если в компании есть готовая Карта карьеры, где прописаны обязательные навыки, знания предметной области, софт-скилы и права по каждому грейду, то можно взять матрицу из нее.

При этом напрямую задавать вопросы по матрице компетенций не стоит — открытые вопросы работают гораздо эффективнее.

2. Открытые вопросы

На собеседованиях все реже работают «вопросы с одним ответом»: человек может выдать зазубренный или, что еще хуже, подсмотренный у ИИ ответ. Гораздо важнее, чтобы кандидат рассуждал и приводил примеры.

Приведу несколько примеров открытых вопросов:

Еще один хороший способ понять, насколько глубоко человек понимает предметную область — стать «почемучкой». Например, задаем вопрос: «Зачем в разработке нужен полиморфизм?» Собеседник отвечает: «Чтобы использовать один и тот же интерфейс для разных реализаций». И тут напрашивается: «А зачем нам использовать один и тот же интерфейс для разных реализаций?» Важно не выбесить человека, но докопаться до истины: действительно ли он понимает тему или просто заучил формулировку. Другими словами, этот метод можно описать как «объясни бабушке свою работу». Если человек способен объяснить сложную ИТ-теорию своими словами, это одновременно признак глубоких знаний и показатель хороших коммуникативных навыков.

3. Практические задачи

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

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

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

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

Заметки по ходу интервью важно делать еще тогда, когда собеседования идут потоком, по несколько в день. В такие моменты высок шанс запутаться в кандидатах, поэтому нужно заранее выработать систему фиксации данных о каждом кандидате. Лично я пользуюсь простыми заметками в текстовом редакторе Obsidian.

При этом полезно сразу отмечать «красные флаги»:

🚩 грубость или панибратство;

🚩 обесценивание процессов (код-ревью, документация);

🚩 обесценивание работы коллег по команде или желание работать в одиночку;

🚩 пробелы в базовых знаниях;

🚩 отсутствие вопросов к интервьюеру.

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

После собеседования важно как можно быстрее, пока воспоминания свежи, составить на основе своих заметок полноценный фидбэк.

Фидбэк стоит отправлять всем кандидатам, даже тем, кто явно не подошел. Если вы видите, что кандидат серьезно проседает в определенной теме, не лишним будет дать рекомендации курса, статьи или направление развития. Вам несложно, а человеку полезно. А заметки лучше хранить: через год тот же кандидат может прийти снова, и вы увидите прогресс.

Приведу несколько цитат из своих старых фидбэков и то, как бы я их сегодня исправил:

Когда соискателей много, решать приходится по чек-листу и… интуиции. При первой встрече сложно сразу сформировать устойчивое мнение о человеке. Он не имел возможности показать себя в разных рабочих ситуациях, поэтому опираться приходится на один — максимум два разговора. Задайте себе вопрос: «Хотел бы я работать рядом с этим человеком каждый день?» Это важнее, чем количество «галочек».

А главное — идеального кандидата не существует, но всегда есть максимально подходящий для проекта. Осталось только его найти.