Стоит ли давать тестовые задания кандидатам?
Проверка соискателей тестовыми заданиями уже несколько лет входит в воронки найма. Но в последнее время она собирает много негативных отзывов от специалистов. Так ли плох инструмент на самом деле или его просто неправильно используют? Делимся, что ответили руководители компаний.
Тестовое задание – это камень преткновения для соискателей, встретив который многие отказываются от пути к должности в компании. Рекрутеры стараются отговорить от него работодателей и сразу переходить от отклика к собеседованию. IT-руководители создают видимость замены проверки на лайв-кодинг и код-ревью. Но всегда найдутся кандидаты, которым не угодить и альтернативными вариантами.
Может быть дело не в самом способе узнать навыки соискателя, а в попытке это сделать? И при определенных условиях и критериях тестовое задание – отличный инструмент, помогающий принять окончательное решение о трудоустройстве?
На сайте mediaten.ru мы опубликовали статью, в которой рассказали о своем применении тестовых заданий при приеме на работу. Спойлер – предлагаем его не всем и не всегда. При найме кандидата – оплачиваем затраченное время.
Но нам интересно, что думают другие по этой теме. Мы задали вопрос трем руководителям IT-компаний и делимся их ответами. Ждем ваши мнения в комментариях!
У нашей IT-компании огромный опыт в заказной разработке. В связи с этим возникают запросы в расширении штата или замещении. Традиционно после скрининга рынка и резюме мы проводим собеседование на софт-скиллы, а также техническое интервью – на хард.
Чтобы не тратить время тимлидов и ведущих специалистов, стараемся на технические вакансии подготовить небольшое тестовое задание.
Данный этап, с одной стороны, показывает заинтересованность соискателя в вакансии, а с другой – не только правильность/неправильность ответа, но и образ мысли: насколько элегантно дано решение и чисто написан код. Решить одну и ту же задачу зачастую можно несколькими способами.
Если ответ и само решение нас устраивают, то переходим к очной встрече.
Из интересных кейсов отмечу три последних
Первый – QA после популярных онлайн-курсов неплохо выполнил тестовое задание, а на очном интервью поплыл. Начал гуглить ответы на вопросы и в итоге сознался, что тестовое решал не сам.
Второй – бэкенд-разработчик хорошо и грамотно написал тестовое, но на очном интервью не показал такого же результата. Мы использовали лайв-кодинг – проверку, на которой соискатель и ведущий специалист в одном рабочем пространстве решают заранее подготовленную задачу. Код из тестового и реальный кодинг отличались разительно. Образ мысли и вариант решения нестандартного «домашнего задания» были выше того уровня, что кандидат продемонстрировал очно.
Третий – соискатель не справился с тестовым. Задача – сделать ревью куска кода BE на PHP. Мы попросили уточнить некоторые детали, а в ответ последовал отказ и вот такое продолжение.
Несмотря на это мы считаем, что тестовые задания нужны. Они позволяют сделать первичный скрининг и отсеять соискателей, которые пройдя «стильно-модно-молодежные» курсы IT, считают себя опытными разработчиками и претендуют на рыночные зарплаты.
У меня за плечами 100+ проведенных собеседований как в своей компании, так и в других. Периодически к нам обращаются за помощью прособесить технарей. Считаю, что тестовые задания эффективно работают только для творческих позиций: дизайнеров, копирайтеров, иллюстраторов.
Когда речь идет о технических специальностях и тем более об управленческих позициях, мы предпочитаем не давать тестовых заданий.
На вопрос «Почему?» приведу в пример три истории.
История №1. Троянский конь
Искали мы Node.JS разработчика. К нам постучался молодой человек и сам попросил тестовое задание вместо лайв-кодинга. Сказал, что ему так проще. Теорию ответил посредственно, однако хорошими софт-скиллами уговорил HR «проверить себя в бою». Скинули ему достаточно заковыристую задачку и спустя какое-то время получили просто идеальное решение.
Лид удовлетворен, HR со светящимися глазами пригласила товарища на встречу в офис. Чувствуя подвох, прошлись еще раз по задаче и в догонку спрашивали «Почему сделал именно так?». Тут-то кандидат и посыпался. Node.JS превратился в Node.TS. По своему же коду, кроме заученных формулировок, сказать ничего не мог. Шаг влево-вправо – аут. Оказалось, что задачу решил за него его брат.
История №2. Гугл в помощь...
Мы не берем готовые задачи из Интернета. Видоизменяем реальные кейсы и даем их кандидатам, чтобы условия были максимально близки к рабочим. Такая уникальность позволяет мониторить «подсказки» в Сети. Однажды мы дали подобную задачу в виде тестового. При проверке увидели ее на форуме с просьбой помочь в решении и ответом, идентичным тому, что дал кандидат.
История №3. Где деньги, Лебовски?
Оплачиваемое тестовое задание – это норма. Только оплачиваться, по нашему мнению, должно выполненное тестовое задание. Был у нас случай, когда человек взял тестовое задание и куда-то пропал. Не выходил на связь 2-3 недели. Потом объявился и... потребовал деньги за потраченное время. Напомню, сам результат = выполненное тестовое, а он его даже не прислал. Забавный кейс.
Вместо тестовых заданий для техспециальностей и управленческих позиций мы используем цепочку живых собеседований. Как показал наш опыт, они гораздо эффективнее.
Скрининг с HR и «проверка на адекватность».
Техническое собеседование. Для технарей – это лайв-кодинг + задачи и проверка теории. Причем обязательно с камерой. Без камеры бывали случаи, когда проходил собес один кандидат, а приходил – другой. С другим голосом, с другой манерой говорить и т. д.
- Знакомство с командой, которое помогает определить, насколько кандидат подходит нам по культуре и ценностям.
Найм людей – это достаточно трудо- и времязатратный процесс. Однако найм неправильных людей – это еще и финансово затратный процесс. Поэтому считаю, что для снижения риска впустить «залетных птичек» лучше потратить больше времени на интервью, чем рассылать тестовые направо и налево.
До открытия студии я работал в Яндексе менеджером продукта и в целом вырос из фулстек-разработчика. Сам писал и веб, и мобилки, и десктоп приложения. В общем, чистый технарь в прошлом.
За 12 лет в IT я понял одно: неважно, сколько знает сотрудник в моменте, важно то, как он умеет находить информацию и мыслить логически.
Мы всегда даем тестовые задания, но они не в стиле «напиши тут много кода», а состоят из логических задач на знание алгоритмов. Причем их решают прямо на онлайн-собеседовании до технического интервью.
В привычном понимании отправить кандидату тестовое тоже можем, если нам требуются знания здесь и сейчас. Как правило, это тоже +- логические задачи на подумать, но не на 5 минут. Мы стараемся уложить выполнение задания в 30-60 минут.
Конечно, для сотрудников, от которых просто требуется точное следование инструкции, задание может занять 5-10 минут. Но наши специалисты участвуют в сложных технических проектах, где нужно проявлять не только знания, но и смекалку. И выявить таких нам помогает рекрутинговая воронка с использованием различных проверок:
созвон, знакомство, логические задачи (наше базовое тестовое);
тестовое, если требуется проверить кандидата углубленно;
техническое собеседование;
- решение.
Как и многие, мы даем тестовое задание ввиду невозможности квалифицировать интеллект человека только по его внешнему виду.
В использовании проверочных инструментов сложно говорить о единой и безоговорочно правильной точке зрения. Каждая компания выстраивает процесс найма сотрудника, ориентируясь на свои потребности, возможности и опыт. Более подробно о внедрении или исключении тестовых заданий в воронки написано в статье «Тестовые задания при приеме на работу».
Мы, в MediaTen, практикуем разные подходы в рекрутинге. За 12+ лет в разработке успели сменить несколько методов отбора кандидатов и выстроить индивидуальные этапы для каждой специальности. Тестовые задания для нас – это дополнительная возможность проверить навыки будущих участников команды. Однако пользуемся мы ею только тогда, когда опыт соискателя требует подтверждения практикой.
А что думаете вы? Стоит или нет давать тестовые задания кандидатам?