Первичный скрининг разработчика не должен превращать рекрутера в человека, который проверяет синтаксис языка по списку из интернета. Его задача — подтвердить соответствие профилю, понять контекст опыта, личный вклад, уровень самостоятельности, мотивацию и условия перехода. Глубокую техническую оценку проводит эксперт, но рекрутер способен отсечь значительную часть случайных совпадений до этого этапа.
Сильный скрининг строится не вокруг вопроса «сколько лет вы работали с технологией», а вокруг реальных проектов и решений. Кандидат должен объяснить, что делал, зачем, при каких ограничениях, с кем взаимодействовал и какой результат получил.
Сначала определите цель скрининга
До разговора разделите критерии на три группы: то, что проверяет рекрутер, то, что оценивает техническая команда, и то, что требует совместного решения. Рекрутер не обязан доказывать качество архитектуры, но должен понять, работал ли кандидат с системами нужного типа и способен ли конкретно описать вклад.
- Соответствие основному профилю и типу задач.
- Масштаб проектов и уровень ответственности.
- Личный вклад и самостоятельность.
- Причины переходов и текущая мотивация.
- Зарплатные ожидания, формат, локация и доступность.
- Риски, которые технической команде нужно проверить глубже.
Подготовьте scorecard до интервью
Scorecard — короткий список критериев с понятными уровнями подтверждения. Без него интервьюер оценивает кандидата по общему впечатлению, а итог «вроде сильный, но не уверен» невозможно использовать.
Для каждого пункта укажите, какой факт считается достаточным. Например, не «знает микросервисы», а «проектировал или существенно менял сервисы, понимает границы, взаимодействие, данные, наблюдаемость и компромиссы».
Начните с рамки разговора
Кратко представьтесь, расскажите длительность, структуру и цель интервью. Назовите роль, команду и основные условия. Кандидат должен понимать, куда он проходит отбор, прежде чем отвечать на подробные вопросы.
Пример: «Сначала расскажу контекст роли, затем разберём последние проекты, ваш вклад, мотивацию и условия. Технические детали глубже обсудите с командой на следующем этапе. В конце оставим время на ваши вопросы».
Вопросы про текущий или последний проект
- Какую задачу решает продукт или система?
- Кто пользователи и насколько критична система?
- Как устроена команда и ваша роль в ней?
- Какая часть работы занимает больше всего времени?
- За какие решения вы отвечаете лично?
- Что изменилось в проекте благодаря вашей работе?
Ответ должен дать контекст. Перечень технологий без объяснения задачи не показывает уровня. Если кандидат говорит «мы мигрировали», уточните, какую часть он сделал сам и какие решения принимал.
Когда нужно быстро найти и проверить инженеров под конкретный продукт, профессиональный подбор разработчиков включает первичный скрининг по задачам, масштабу и реальному вкладу, а не только по совпадению стека.
Как проверить личный вклад
- Что именно было вашей зоной ответственности?
- Какое решение вы предложили или защитили?
- Что сделали другие участники команды?
- Какие ограничения вы учитывали?
- Как вы поняли, что результат работает?
- Что бы вы изменили сейчас?
Использование «мы» нормально, потому что разработка командная. Но кандидат должен уметь отделить коллективный результат от собственной ответственности. Постоянное отсутствие конкретики — повод передать риск техническому интервьюеру.
Вопросы про сложность и масштаб
Масштаб — не только количество пользователей. Уточняйте объём данных, нагрузку, критичность, количество интеграций, требования к доступности, скорость изменений и цену ошибки. Один внутренний сервис может быть технически сложнее публичного приложения с большим числом пользователей.
- Какие ограничения делали задачу сложной?
- Какой объём данных или запросов обрабатывала система?
- Какие требования были к доступности и времени ответа?
- Сколько команд зависело от вашего компонента?
- Какие инциденты или узкие места возникали?
Как обсуждать технические решения без экзамена
Рекрутер может попросить кандидата объяснить одно решение простым языком: какая была проблема, какие варианты рассматривались, почему выбран этот, какие недостатки приняли. Цель — увидеть структуру и глубину, а не оценить правильность каждой детали.
Если кандидат использует сложные термины, задавайте уточнение: «Что это изменило для системы или команды?» Сильный специалист обычно способен объяснить суть на уровне собеседника.
Вопросы про production и качество
- Как изменения доходят до production?
- Как команда тестирует и наблюдает систему?
- Участвуете ли вы в разборе инцидентов?
- Какие метрики и логи используете?
- Расскажите о дефекте или сбое, который вы помогали устранять.
- Что команда изменила после проблемы?
Для части ролей production-опыт критичен, для других — желателен. Не превращайте его в универсальный фильтр, если вакансия не требует такой ответственности.
Проверьте взаимодействие с командой
Разработчик работает с другими инженерами, продуктом, аналитиками, QA, дизайном и бизнесом. Уточняйте не абстрактную коммуникабельность, а реальные ситуации: согласование решения, конфликт приоритетов, code review, наставничество и работа с неопределёнными требованиями.
- Как вы согласовывали решение с другими командами?
- Что делали, когда требования менялись?
- Как реагировали на несогласие в code review?
- Приходилось ли объяснять технический риск бизнесу?
- Как вы помогали менее опытным коллегам?
Вопросы про переходы между компаниями
По каждому месту достаточно понять причину входа, причину выхода и логику следующего шага. Не превращайте интервью в расследование. Повторяющиеся короткие периоды требуют уточнения, но сами по себе не доказывают ненадёжность.
Смотрите, насколько текущая мотивация совпадает с вакансией. Если кандидат уходит из-за отсутствия влияния, а новая роль полностью исполнительская, риск очевиден даже при идеальном стеке.
Как проверить мотивацию без вопроса «почему наша компания»
- Что вы хотите изменить в следующей роли?
- Какие задачи хотите сохранить, а какие убрать?
- Какой уровень ответственности ищете?
- Что для вас важно в руководителе и команде?
- Какие предложения вы точно не рассматриваете?
- По каким критериям будете выбирать между вариантами?
Кандидат на первом разговоре может знать о компании немного. Оценивать его по качеству рекламной речи бессмысленно. Гораздо полезнее проверить совпадение критериев выбора с реальными особенностями роли.
Условия, которые нужно обсудить сразу
- Текущая локация и допустимый формат работы.
- Право на работу и готовность к релокации, если это важно.
- Зарплатные ожидания и структура компенсации.
- Срок выхода и текущие процессы.
- Готовность к дежурствам, командировкам или офису.
- Факторы, которые могут остановить процесс позже.
Прозрачность экономит время обеих сторон. Не нужно откладывать критичные ограничения до финального этапа в надежде, что кандидат потом согласится.
Красные флаги, которые требуют проверки
- Кандидат не может отделить свой вклад от результата команды.
- Описание проектов противоречит резюме или меняется при уточнениях.
- Все решения объясняются только указанием руководителя.
- Нет понимания результата или пользователей своей работы.
- Каждый уход объясняется исключительно некомпетентностью других.
- Ожидания по роли не совпадают с её реальным содержанием.
- Кандидат скрывает критичное ограничение после прямого вопроса.
Красный флаг не всегда означает отказ. Это тема для дополнительной проверки. Рекрутер должен передать конкретный риск технической команде, а не общий ярлык «что-то не понравилось».
Что не нужно спрашивать рекрутеру
Не проводите викторину по определениям, если ответы не связаны с задачами роли. Вопросы «что такое полиморфизм» или «назовите принципы SOLID» могут проверять память, но почти не показывают, как человек работает с реальной системой.
Также не стоит оценивать глубину по количеству названных инструментов. Один опытный инженер может осознанно использовать небольшой стек, а другой перечислить десятки технологий без самостоятельной практики.
Как оформить итог скрининга
- Краткое соответствие основным задачам.
- Последний релевантный проект и масштаб.
- Подтверждённый личный вклад.
- Сильные стороны по scorecard.
- Риски и вопросы для технического этапа.
- Мотивация и критерии выбора.
- Условия, ожидания и доступность.
- Чёткая рекомендация: двигать, отклонить или уточнить.
Для сложных или массовых задач можно подключить кадровое IT-агентство, чтобы внутренняя команда получала уже откалиброванные профили с понятным отчётом по опыту, мотивации и рискам.
Как передать кандидата техническому интервьюеру
Не пересказывайте всё резюме. Передайте три блока: почему профиль релевантен, что подтверждено на скрининге и что требуется проверить глубже. Это помогает техническому эксперту не повторять первый разговор и сфокусироваться на решениях.
Профессиональный подбор разработчиков особенно полезен, когда вакансия требует точного сочетания стека, масштаба, домена и уровня самостоятельности, а внутренние эксперты не могут тратить время на нерелевантные интервью.
Частые вопросы
Сколько должен длиться первичный скрининг?
Обычно 30–45 минут достаточно для контекста, проектов, мотивации и условий. Для руководящих ролей может потребоваться больше времени.
Должен ли рекрутер задавать технические вопросы?
Да, если они проверяют контекст опыта и согласованы с командой. Но рекрутер не должен подменять глубокую техническую оценку или принимать решение по заученным определениям.
Как понять уровень кандидата без знания кода?
Через масштаб задач, самостоятельность, качество объяснения решений, личный вклад, работу с ограничениями и влияние на результат. Финальное подтверждение остаётся за техническим этапом.
Нужно ли проверять все технологии из вакансии?
Нет. Сфокусируйтесь на обязательном ядре и допустимых аналогах. Остальное техническая команда проверит по необходимости.
Что делать, если кандидат отвечает слишком общо?
Уточняйте конкретный проект, решение, действие и результат. Если конкретика не появляется после нескольких вопросов, зафиксируйте это как риск.
Вывод
Первичный скрининг разработчика должен подтверждать не набор ключевых слов, а релевантный контекст: задачи, масштаб, личный вклад, решения, production, взаимодействие, мотивацию и условия. Хороший итог помогает технической команде принять решение быстрее и не повторять разговор.
Чтобы получать проверенных инженеров с понятным первичным отчётом, передайте вакансию на подбор разработчиков. Это сокращает количество случайных интервью и сохраняет время технических специалистов.