Тестовые задания в ИТ – пережиток прошлого или важный этап отбора? Часть 1

Как понять, что разработчик действительно крут и подходит для ваших задач? Дать тестовое. Самый ли эффективный это вариант, учитывая, что IT – это рынок кандидата? Потому что кандидатов нужного уровня гораздо меньше, чем открытых вакансий. Например, в направлениях frontend, mobile, data science предложение превышает спрос в 2,5 раза. И тестовые задания в виде объемных кейсов на дом иногда усложняют процесс поиска. Мы попросили поговорить на эту тему Татьяну Аква, опытного эксперта по ИТ-рекрутингу, руководителя направления в рекрутинговом агентстве Star Staff.

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

- Большинство компаний хотят «найти лучших». «Лучших» естественно меньше, чем компаний, и начинается жесткая офферная война с повышением зарплат в разы, что тоже негативно влияет на сферу – рынок перегревается, зарплаты неадекватно растут. Либо компании упрямо стоят на своем, требуя «Надо чтобы глаза горели! Мы подождем того, у кого будут гореть!».

А в итоге гореть начинают проектные дедлайны у самой компании. При этом не все понимают, что действительно «лучшие» нужны не всегда и не всем. Одно дело искать лучших для разработки сложных, оригинальных решений, меняющих сферу или мировые практики. И совсем другое дело – полгода отбирать разработчика в логистический проект для стандартной автоматизации перевозок.

- Трудности с поиском кандидатов с нужным уровнем скиллов и опытом, необходимость учитывать технический стек у соискателя и проекта, важность не только HR-бренда компании и формирование технического бренда, адекватность процесса отбора и собеседований, организация онбординга и так далее.

Многие из этих проблем прочно заняли место в списке тем для неустаревающих мемов. Атаки на кандидатов предложениями (по 15-20 в день), неоправданно большое количество этапов собеседований, долгая (или вообще отсутствующая) обратная связь. И, разумеется, одна из самых острых проблем — тестовые задания. Длинные и короткие, перед собеседованием, после и во время, теоретические и практические.

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

Наша рекрутинговая компания уже 13 лет работает на рынке ИТ-подбора, и мы понимаем, что тестовые задания в найме появились не просто так. Это попытка решения проблемы и часто обоснованный этап, возникший от невозможности решить задачи найма иначе. Основываясь на своем опыте работы с самыми разными компаниями, озвучу свое мнение – тестовые задания в большинстве случаев не нужны. А отказаться от этой практики компаниям сложно, потому что она подкреплена рядом заблуждений, укоренившихся на рынке.

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

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

Если брать среднее время на взаимодействие с одним разработчиком, то оценка трудозатрат в этих двух кейсах будет выглядеть примерно так:

Посчитаем, сколько времени потребуется для закрытия этих вакансий.

Повторюсь, это показатели по типовой воронке.

Кроме оценки по времени есть еще конверсионная воронка по вероятности выхода человека в компанию. Вы задумывались, как формируется первичное решение кандидата пойти на собеседование? На одного ведущего разработчика, разместившего хорошее резюме, в день его размещения приходится около 15-20 звонков/писем и предложений в других каналах связи. И ему из этого количества приходится выбирать, с кем общаться, потому что никто в здравом уме не будет общаться со всеми подряд без разбора.

Как он принимает решение, с кем общаться? Будь вы на месте кандидата, вы наверняка провели бы отсев по формальным признакам.

• Зачем ехать в офис, который находится в 20 минутах от метро, когда есть 10 предложений в лофтах и в паре минут от удобной станции?
• Зачем тратить время на несколько этапов и финальное личное собеседование, если большинство компаний предлагают один этап в любое время по зуму и не нужно отпрашиваться с работы?
• Зачем тратить время на тестовое задание, если сейчас тестовое дают 2 компании из 10 на рынке, а остальные 8 умеют нанимать без него. И ладно если бы эти две были условными Google или Facebook, но ведь нет.

В итоге остаются 2-3 предложения, с которыми кандидат готов общаться.

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

Пандемия тоже внесла свои коррективы и предложения полностью удаленной работы выросли в разы без снижения ЗП. Иностранные компании составляют полноценную конкуренцию российским, нанимая удаленно на свои проекты, предлагая при этом гораздо более привлекательные ставки, потому что могут себе это позволить. Логично, что при прочих равных, толковому специалисту интереснее поработать с зарубежной компанией, а значит он предпочтет сделать тестовое для них.

Как раз об этом следующий миф:

Да, мы все хотим равняться на лучших, думая, не зря же у Google, Яндекса, Mail, Facebook все устроено так, как устроено. Давайте делать как они!

И это серьезная ошибка.

Давайте подумаем, зачем им это? Во-первых, чтобы выявить действительно лучших из лучших, потому что у них есть задачи под стать самым сильным кандидатам, которые хотят (и могут!) решать самые сложные задачи. Во-вторых, их процессы отбора — это в том числе метод экономии времени. Представьте, если бы условный Google собеседовал всех, кто хочет у них работать, без формального этапа с тестовым заданием. Что случилось бы? Думается, Google бы превратился в собеседовательный конвейер, а не в разработчика всемирно известных продуктов.

Поэтому скажу так, если вы из тех счастливчиков, к кому реально стоит очередь из кандидатов, у вас уникальные задачи и лучший социальный и компенсационный пакет, есть свой модный кампус и мировое имя — давайте тестовое. В остальных случаях –– читайте дальше :)

Миф о том, что тестовое задание снижает вероятность непрохождения сотрудником испытательного срока. Мол, если кандидат инвестировал свое личное время в выполнение тестового задания и успешно прошел его, то он обязательно согласится с оффером и будет держаться за свое место.

Развею этот миф. За 13 лет наблюдений процент «соскочивших» кандидатов никак не коррелирует с наличием или отсутствием тестового задания. Люди уходят из компаний по множеству причин, в том числе и вскоре после прихода в компанию, и тестовое задание на собеседовании или количество этапов на это никак не влияют.

Как говорит мой знакомый технический директор крупной IT-компании, между результатом тестового задания и реальной работой лежит огромная пропасть. Начиная с того, что тестовое выполняется в комфортном режиме с кем и где угодно, а реальная задача в бою может застигнуть тебя врасплох.

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

Плюс, нельзя забывать, что тестовое здание, в отличие от реальной работы над проектом, не включает ряда важных этапов: поиск ошибок, дебаг, архитектурные моменты, рефакторинг, работа в команде, спринты, метрики а-ля Time To Market и прочее.

А что делать, когда возникает реальная проблема, все валится и не работает, а ваши разработчики не могут понять, почему? Теория здесь не поможет, нужен боевой опыт. Поэтому бесполезно искать теоретически подкованных разработчиков, любящих решать типичные проблемы, нужно искать людей, подходящих вам по стеку, умению решать проблемы, технической любознательностью, креативностью, с опытом и умением просто делать все, что нужно, и хорошей совместимостью с командой.

Итак, проблема обозначена. Причины тоже более-менее ясны. И как же с этим жить, спросите вы? Просто взять и отменить тестовые — не вариант, и в этом я с вами полностью согласна. Чем заменить тестовое задание и что делать, если без него совсем никак не обойтись, в следующей части материала. Stay tuned ;)