Технический скрининг без лайвкодинга

Введение

Картина знакома: кандидат сидит перед камерой, вы пишете условие на доску, он должен за 30 минут написать решение. На самом деле вы видите не его таланты, а как быстро он может паниковать. После собеседования 70% кандидатов говорят: «На работе я пишу намного лучше, чем на собеседовании». Они правы.

Почему лайв-кодирование плохо? И что делать вместо этого?

Почему лайв-кодирование неправильно

Стресс блокирует мышление. Человек в напряжении работает медленнее. Глубокие думки приходят дома на диване, а не под камерой.

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

Проверяешь не то. Лайв-кодинг проверяет память, уверенность, умение писать синтаксис под давлением. Это не то, что ценится при рутинной работе.

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

Метод 1: Асинхронная домашняя задача

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

Как сделать эффективно:

• Задача = типичная рабочая ситуация. Если вы пишете API, попросите реализовать простой эндпоинт с валидацией. Если фронтенд — компонент с состоянием.
• Время: 40–60 минут. Ровно столько, сколько уходит на реальную задачу.
• Дайте критерии оценки. Работает? Читаемо? Тестируемо? Кандидат будет писать лучше, если знает, что ценится.
• Обсудите решение живьём. После сдачи возьмите 20-30 минут, обсудите его выбор. Почему именно этот паттерн? Что можно улучшить?

Результат: вы видите реальный уровень кандидата, он не в стрессе.

Метод 2: Видеорассказ о коде

Попросите кандидата записать видео (3–5 минут), где он рассказывает про проект из своего портфолио или из работы.

Что смотреть:

• Может ли человек объяснить своё решение?
• Видит ли он слабые места в своем коде?
• Как он рассуждает о масштабируемости и удобству?

Это мало занимает времени у кандидата (много компаний просят асинхронные видео-интервью), а вы узнаете о человеке больше, чем на 1-часовом звонке.

Метод 3: Обсуждение архитектуры

Вместо кодирования обсудите, как бы кандидат спроектировал систему:

• «Как бы вы спроектировали кеш для микросервиса?»
• «Какие проблемы возникнут, если масштабировать эту базу данных?»
• «Как бы вы структурировали этот код, чтобы его было легко тестировать?»

Глубокое архитектурное мышление > быстрое написание синтаксиса.

Метод 4: Pair programming-лайт

Вместо стрессового лайв-кодинга проведите сессию, где вы два пишете вместе.

• Вы начинаете задачу, кандидат продолжает
• Дальше меняетесь
• Параллельно общаетесь, обсуждаете подходы

Это куда ближе к реальной работе, стресса меньше, вы видите, как человек сотрудничает.

Метод 5: Проверка через открытый исходный код

Если кандидат приносит реальный проект (свой или open-source вклад), изучите его:

• Навигируетесь ли вы по коду?
• Есть ли тесты?
• Коммиты с осмысленными сообщениями?
• Был ли диалог с maintainer-ами (про pull-request)?

Реальный код многое скажет о привычках кандидата.

Комбинированный подход

Лучше всего работает комбинация:

1. Асинхронная задача (30–40 минут)
2. Обсуждение решения (20 минут)
3. Беседа про архитектуру (20 минут)
4. Встреча с лидом (если пошел хорошо)

Это займет 1–1.5 часа вашего времени и 1–2 часа времени кандидата. Но вы будете уверены в его уровне.

Итого

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

Чем раньше вы это осознаете, тем раньше начнете нанимать людей, которые действительно решают задачи.