FriFlex

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

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

Предисловие. Особенности рынка ИТ-рекрутмента

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

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

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

Иллюстрация: https://vk.com/humanrelations 

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

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

Почему тестовые задания – это вообще проблема?

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

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

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

Миф 1. Тестовое задание упрощает найм нужных кандидатов

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

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

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

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

У нас бывают кейсы, когда мы с клиентом смотрим и по 40 резюме для найма одного человека. И это без стоимости онбординга, обучения, гонорара за найм или оклада HR.

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

Миф 2. Тестовое задание не сказывается на количестве соискателей

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

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

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

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

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

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

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

Миф 3. Тестовое задание нужно любой компании

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

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

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

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

Миф 4. Тестовое задание — это гарантия лояльности нанятого сотрудника

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

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

Миф 5: Тестовое задание — это проверка кандидата «в боевых условиях»

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

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

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

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

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

{ "author_name": "FriFlex", "author_type": "editor", "tags": [], "comments": 6, "likes": 25, "favorites": 18, "is_advertisement": false, "subsite_label": "friflex", "id": 196506, "is_wide": true, "is_ugc": false, "date": "Thu, 14 Jan 2021 10:59:15 +0300", "is_special": false }
0
6 комментариев
Популярные
По порядку
Написать комментарий...
0

Я офигел, когда прочитал, что в логистику можно самых посредственных ребят искать. 
Конечно, что такое Система управления складом или даже терминалом по сравнению аж с целым мобильным приложением. Много ума не надо - расставляй себе паллеты да контейнеры в порту неспешно, пусть весь мир подождёт)

Ответить
0

Мнение эйчара, слабо разбирающегося в предмете. Любой, кто начинал торговать товарами, требующими доставки, сталкивался с необходимостью минимизировать перемещение между точками при поддержке полного ассортимента. Попробуй скажи покупателю, что доставка 4 дня, (потому как вам надо перекинуть товар между магазинами), просто уйдет туда, где есть в наличии.

Ответить
1

Обратите внимание на предложение полностью ;) "для стандартной автоматизации перевозок" - указала именно стандартные задачи. Я могла привести в пример абсолютно любую сферу со стандартными задачами. Упомянула эту, потому что был реальный кейс в практике, где была логистическая компания у которой практически не было автоматизации и задачи были, а-ля отследить трек от точки А к точке Б. Но IT-шников в компании раньше не нанимали и у собственника (харизматичного грузина и темпераментного мужчины) был пунктик "ITшник из Яндекса или Гугла" 😏 Искал полгода. И мнение это было не только мое, а 10-ти мощных синьоров, которые к нему приходили и потом говорили, что задачи там для начинающего миддла.

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

Не нужно сходу умалять профессионализм автора 😌 Просто, наверное, я действительно не до конца развернула мысль.

Ответить
0

Нет такого понятия "стандартная автоматизация" перевозок или чего бы то ни было. Иначе бы пользовались бы "стандартной программой автоматизации". Даже строго регламентированная бухгалтерия для которой есть "стандартная автоматизация" в виде 1C имеет альтернативы в виде всяких Парусов, Галактик и прочих SAPов. А уж сколько программистов нужно для стандартной автоматизации бухгалтерии на стандартом 1С и почем они на рынке - вы в курсе.

А вот формулировка "автоматизация для харизматичного грузина" уже больше понимания дает.

Ответить
0

Статья притянута за уши.

Ответить
–2

Аргументы притянуты за уши

Ответить

Комментарии

null