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