Viktor.Orlov
New member
Полтора года назад я потратил на поиск одного бэкенд-разработчика почти шесть месяцев. Не потому, что кандидатов не было — их было человек сорок. Проблема была в другом: мы отлично проходили этап интервью, обменивались вежливыми письмами, подписывали оффер, а через месяц человек уходил, потому что «ожидал другого». И каждый такой цикл стоил нам от трёх недель до двух месяцев календарного времени. Тогда я решил, что дело не в рынке, а в том, как мы проверяем людей на входе.
Классическое тестовое на восемь часов — это, честно говоря, главный источник моих седых волос. Мы давали кандидату абстрактную задачу, он неделю её не трогал, потом за ночь лепил решение из чужих идей, а мы получали код, который ничего не говорил о том, как этот человек работает в команде. Мы оценивали не инженера, а умение доводить формальную домашку до состояния «компилируется и даже проходит тесты». Сеньор с прекрасным чувством архитектуры мог провалить наш отбор просто потому, что у него была тяжёлая неделя на текущей работе.
Формат, который мы в итоге собрали, я называю тестовым нового формата. Он состоит из двух частей. Первая — короткая живая сессия на девяносто минут: кандидат и один наш разработчик вместе разбирают небольшую реальную задачу, вырезанную из нашего же бэклога. Никаких алгоритмических головоломок, только тот код, который мы пишем каждый день. Вторая часть — маленькая асинхронная правка на два-три часа, но с обязательным условием: кандидат записывает короткий комментарий о том, почему выбрал именно такое решение и что бы сделал иначе при других ограничениях. Мне важнее ход мысли, чем идеальный результат.
Проводим мы это так. Сначала пятнадцать минут на знакомство и разбор контекста, чтобы человек не чувствовал себя на экзамене. Потом сам код: кандидат пишет, наш разработчик рядом задаёт вопросы и иногда специально подкидывает противоречивое требование, чтобы посмотреть, как человек спорит и как меняет решение. В конце двадцать минут на разбор: что было сложно, что бы переделал, где не хватило информации. За это время видно больше, чем за три часа формального интервью.
Что показала практика. Конверсия из первого созвона в оффер у нас выросла примерно с шестнадцати до тридцати четырёх процентов, потому что мы перестали сжигать людей на длинном домашнем задании. Время от первого контакта до выхода на работу сократилось с восьми недель до трёх. И самое приятное — доля людей, которые уходят в первый месяц, упала почти до нуля. Не потому, что мы стали лучше угадывать, а потому, что кандидат за эти девяносто минут видит реальную работу, реальный код и реального человека из команды. Он тоже принимает решение — и это честнее для обеих сторон.
Если будете внедрять у себя, вот что я советую. Берите задачу из настоящего бэклога, а не из учебника по алгоритмам. Пусть на сессии обязательно присутствует человек, с которым кандидат потом будет работать, а не только HR и тимлид. Не оценивайте по чек-листу «умеет или не умеет», оценивайте по тому, как человек реагирует на новую вводную. Давайте обратную связь в течение двух дней — даже отказ, но с объяснением. И держите весь процесс в пределах недели: если вы тянете дольше, сильный кандидат уже получил другое предложение.
Главный вывод, который я сделал за эти полтора года: тестовое задание — это не фильтр, а первое совместное дело. Если после него обе стороны хотят продолжить работать вместе, значит, оно сделало свою работу. Теперь мой вопрос к вам, форумчане: а какой формат отбора прижился именно у вас и что в нём оказалось самым неожиданным — со стороны кандидатов или со стороны команды? Расскажите, буду рад поспорить и позаимствовать хорошие идеи.
Классическое тестовое на восемь часов — это, честно говоря, главный источник моих седых волос. Мы давали кандидату абстрактную задачу, он неделю её не трогал, потом за ночь лепил решение из чужих идей, а мы получали код, который ничего не говорил о том, как этот человек работает в команде. Мы оценивали не инженера, а умение доводить формальную домашку до состояния «компилируется и даже проходит тесты». Сеньор с прекрасным чувством архитектуры мог провалить наш отбор просто потому, что у него была тяжёлая неделя на текущей работе.
Формат, который мы в итоге собрали, я называю тестовым нового формата. Он состоит из двух частей. Первая — короткая живая сессия на девяносто минут: кандидат и один наш разработчик вместе разбирают небольшую реальную задачу, вырезанную из нашего же бэклога. Никаких алгоритмических головоломок, только тот код, который мы пишем каждый день. Вторая часть — маленькая асинхронная правка на два-три часа, но с обязательным условием: кандидат записывает короткий комментарий о том, почему выбрал именно такое решение и что бы сделал иначе при других ограничениях. Мне важнее ход мысли, чем идеальный результат.
Проводим мы это так. Сначала пятнадцать минут на знакомство и разбор контекста, чтобы человек не чувствовал себя на экзамене. Потом сам код: кандидат пишет, наш разработчик рядом задаёт вопросы и иногда специально подкидывает противоречивое требование, чтобы посмотреть, как человек спорит и как меняет решение. В конце двадцать минут на разбор: что было сложно, что бы переделал, где не хватило информации. За это время видно больше, чем за три часа формального интервью.
Что показала практика. Конверсия из первого созвона в оффер у нас выросла примерно с шестнадцати до тридцати четырёх процентов, потому что мы перестали сжигать людей на длинном домашнем задании. Время от первого контакта до выхода на работу сократилось с восьми недель до трёх. И самое приятное — доля людей, которые уходят в первый месяц, упала почти до нуля. Не потому, что мы стали лучше угадывать, а потому, что кандидат за эти девяносто минут видит реальную работу, реальный код и реального человека из команды. Он тоже принимает решение — и это честнее для обеих сторон.
Если будете внедрять у себя, вот что я советую. Берите задачу из настоящего бэклога, а не из учебника по алгоритмам. Пусть на сессии обязательно присутствует человек, с которым кандидат потом будет работать, а не только HR и тимлид. Не оценивайте по чек-листу «умеет или не умеет», оценивайте по тому, как человек реагирует на новую вводную. Давайте обратную связь в течение двух дней — даже отказ, но с объяснением. И держите весь процесс в пределах недели: если вы тянете дольше, сильный кандидат уже получил другое предложение.
Главный вывод, который я сделал за эти полтора года: тестовое задание — это не фильтр, а первое совместное дело. Если после него обе стороны хотят продолжить работать вместе, значит, оно сделало свою работу. Теперь мой вопрос к вам, форумчане: а какой формат отбора прижился именно у вас и что в нём оказалось самым неожиданным — со стороны кандидатов или со стороны команды? Расскажите, буду рад поспорить и позаимствовать хорошие идеи.