Я перестал собеседовать разработчиков. Вот что я делаю вместо этого

В 2020 году я нанял разработчика, который на собеседовании безупречно объяснил архитектуру microservices, правильно ответил на все вопросы по PHP и произвёл впечатление на двух людей в команде. Через четыре месяца я его уволил. Не потому что он был плохим человеком — он просто не умел работать в нашем реальном контексте.

После этого я перестал проводить собеседования в привычном смысле.

Собеседование проверяет память, не умение работать

На собеседовании человек отвечает на вопросы в искусственной обстановке. Он знает, что его оценивают. Он подготовился. Он показывает лучшую версию себя за 1-2 часа.

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

Я потратил несколько месяцев онбординга на людей, которые умели хорошо рассказывать, но не умели работать в нашей среде. Это дорого. Не только в деньгах. В нервах, в сорванных дедлайнах, в объяснениях клиентам. Я закрываю риски, а не тикеты — и найм не исключение.

Средняя стоимость неправильного найма mid-разработчика — от трёх до шести месяцев его зарплаты, если считать онбординг, переделку кода и потери на проектах. По данным Habr Career, только на замену одного разработчика уровня middle уходит от 200 до 350 тысяч рублей прямых расходов. Косвенные — ещё столько же.

Три дня пробного проекта стоят меньше.

Что такое трёхдневный пробный проект

Модель простая. Я предлагаю кандидату три рабочих дня в нашем реальном окружении. Задача — небольшая, но настоящая: например, добавить кэширование к компоненту на Bitrix без изменения существующего интерфейса, или настроить очередь задач через RabbitMQ в существующем PHP-проекте. Не учебный пример, а реальный кусок из нашего репозитория.

За эти три дня человек получает нормальную оплату — пропорционально его ставке. Я не прошу работать бесплатно.

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

Технически всё просто: я создаю отдельную ветку в репозитории, даю доступ к dev-окружению, провожу короткий вводный созвон на 30 минут. Дальше человек работает как обычный член команды.

Три сигнала, которые не видны на собеседовании

За три дня я смотрю не на результат. Точнее, не только на него.

Первый — вопросы. Хороший разработчик задаёт уточняющие вопросы в первые несколько часов. Не потому что не понимает задачу, а потому что понимает: в задаче всегда есть неопределённость. Человек, который молча берётся и через сутки приносит «готово», часто сделал что-то своё, а не то, что нужно.

Второй — поведение при проблеме. В реальном коде всегда есть что-то, что мешает. Как человек реагирует, когда упирается в неочевидную ситуацию? Пишет в Slack сразу или два дня роет молча? Спрашивает разрешения на каждый шаг или принимает разумные решения сам?

Третий — отношение к legacy. У нас есть код, написанный пять-семь лет назад. Если человек сходу начинает говорить «это надо переписать», это не обязательно плохой знак, но стоит заметить. В первые три дня он ещё не понимает, что и почему было написано именно так. Поспешная критика — признак небольшого опыта работы с чужим кодом.

Как хорошие кандидаты реагируют иначе

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

Это не человек, который хорошо продаёт себя на интервью. Это человек, который умеет работать.

Плохой кандидат на пробнике — тот, кто постоянно ищет подтверждения. «Правильно я делаю?», «Можно я сделаю вот так?», «Вы смотрели, что я отправил?» — через каждые два часа. Это не плохой человек, просто не тот уровень автономии, который нужен для нашей работы.

Цифры: стоимость ошибки в найме

Три дня оплачиваемого пробника при ставке разработчика 3000-4000 рублей в час — это 72 000-96 000 рублей. Много? Нет. Потому что альтернатива — три-четыре месяца онбординга человека, который в итоге не подходит.

Я провёл больше двадцати пробных проектов за последние три года. Примерно шесть закончились отказом — либо с моей стороны, либо кандидат сам понял, что наш контекст не для него. В каждом из этих случаев мы потратили три дня вместо нескольких месяцев. Это просто математика.

Конверсия из пробника в оффер — около 70%. Конверсия из оффера в «человек работает больше года» — около 85%. Это цифры, которые меня устраивают.

Когда пробник не работает — честно

Есть ситуации, где эта модель не подходит.

Если нужен человек очень срочно — на три дня пробника времени нет. Это реальное ограничение.

Если кандидат работает на другой работе full-time и не может взять три дня — пробник не состоится. Иногда делаем компромисс: задача на выходные, чуть более длинный горизонт. Но это уже менее чистый результат.

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

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

В итоге

Собеседование — это продажа. Кандидат продаёт себя, вы покупаете. Три дня работы — это не продажа. Это работа.

Я не говорю, что собеседований не должно быть вообще. Вводный разговор на 30 минут — важен. Но если вы хотите понять, сработаетесь ли вы, единственный надёжный способ — поработать вместе. Хотя бы три дня.