HR-блог про IT рекрутинг от ИТ Кадрового агентства

Технический скрининг IT-кандидатов: что проверять до интервью с командой

Технологии IT рекрутинг Управление персоналом

Технический скрининг IT-кандидатов часто оказывается между двух крайностей. В первом случае рекрутер задаёт формальные вопросы по списку и пропускает человека, который просто выучил правильные слова. Во втором — пытается провести полноценное техническое интервью, не имея достаточной экспертизы, и отказывает сильному кандидату из-за неудачной формулировки.

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

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

Что должен решить технический скрининг кандидата

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

Если внутренней команде не хватает времени на первичную проверку, можно подключить подбор IT и digital-специалистов с рекрутерским скринингом и калибровкой по роли.

Граница ответственности рекрутера

Рекрутер должен понимать профессиональный контекст, но не обязан решать алгоритмические задачи или оценивать архитектуру на уровне Staff Engineer. Его задача — задавать вопросы, которые раскрывают факты и позволяют увидеть несоответствие.

Например, вместо вопроса «знаете ли вы Kubernetes?» полезнее спросить, где и для чего кандидат его использовал, за какую часть отвечал, какие ограничения были и с кем принимались решения. Ответ не заменит техническую оценку, но покажет глубину участия.

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

Проверка стека: упоминание не равно опыту

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

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

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

Сложность систем и масштаб ответственности

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

Цель не в том, чтобы получить секретные данные текущего работодателя. Достаточно относительных ориентиров и характера решений. Профессиональный кандидат умеет объяснить сложность без раскрытия конфиденциальной информации.

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

Как отделить личный вклад от результата команды

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

Какую проблему вы решали лично?
Какие решения принимали самостоятельно?
С кем согласовывали архитектуру или приоритеты?
Что изменилось благодаря вашему участию?
Что бы произошло, если бы вы не участвовали в проекте?

Эти вопросы полезны для разработчиков, аналитиков, продукта и руководителей, но профессиональные доказательства будут различаться.

Карьерная логика и соответствие уровню

Title не всегда отражает уровень. В стартапе Senior может иметь большой мандат, а в корпорации Lead — отвечать за узкий участок. Нужно сопоставлять не названия, а сложность и масштаб.

Карьерный переход также требует контекста. Человек может осознанно перейти из управления в individual contributor, сменить домен или выбрать меньшую компанию ради влияния. Это не автоматический риск, но мотивация должна быть понятна.

Что можно проверить до технического интервью

Релевантность последних задач. Не только старый опыт из резюме.
Глубину по ключевым технологиям. Контекст, свежесть и личное использование.
Масштаб систем. Нагрузка, критичность, архитектура и команда.
Уровень самостоятельности. Какие решения человек принимал.
Коммуникационный контекст. Работа с продуктом, бизнесом и смежными командами.
Мотивацию и ожидания. Задачи, уровень, доход, формат и сроки.
Формальные условия. География, язык, документы и доступность.

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

Когда использовать тесты и задания

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

LinkedIn в материалах о skills-based hiring рекомендует строить критерии вокруг требуемых навыков и использовать практические оценки, близкие к будущей работе. Для software engineer это может быть coding challenge, но формат должен быть соразмерен этапу и не превращаться в бесплатную разработку.

Источник: LinkedIn о skills-based hiring.

Структурированная передача кандидата команде

После скрининга технический интервьюер должен получить не субъективное «понравился», а краткую фактическую картину: релевантный опыт, масштаб, личный вклад, мотивацию, сомнения и вопросы для следующего этапа.

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

CIPD рекомендует сравнивать кандидатов с заранее определёнными критериями роли и использовать структурированные методы оценки. Такой подход снижает влияние общего впечатления и несопоставимых вопросов.

Подробнее: CIPD о методах отбора.

Ошибки технического скрининга

Проверять память вместо опыта. Вопросы на определения не показывают качество решений.
Отказывать за незнакомый инструмент. Не оценивать переносимые навыки.
Принимать командный результат за личный. Не уточнять вклад кандидата.
Притворяться техническим экспертом. Делать выводы за пределами компетенции рекрутера.
Передавать команде только резюме. Терять информацию скрининга.
Дублировать вопросы на всех этапах. Увеличивать процесс без новой информации.

Чтобы техническая команда встречалась только с кандидатами, прошедшими качественную первичную калибровку, можно передать технический скрининг IT-кандидатов агентству в рамках поиска и сопровождения вакансии.

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

Должен ли IT-рекрутер уметь программировать?

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

Сколько длится первичный скрининг?

Зависит от уровня и роли. Важно получить достаточный контекст, а не уложиться в универсальную цифру.

Можно ли отказать после рекрутерского скрининга?

Да, если выявлено фактическое несоответствие ключевым критериям или формальным условиям. Технические сомнения лучше передать специалисту.

Нужно ли задавать одинаковые вопросы всем?

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

Что делать, если рекрутер и команда оценивают уровень по-разному?

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

Вывод

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

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