Привет, Хабр и его читатели! С вами снова Макс, Lead Backend в компании ИдаПроджект и автор YouTube-канала PyLounge.
Так уж вышло, что мне пришлось посмотреть много тестовых заданий за последний год. А мой бэкграунд — в качестве преподавателя классического университета — не смог оставить равнодушным к этой истории :). Так что я решил углубиться в тему тестовых заданий (далее ТЗ) и поделиться с вами результатами.
Вступление
Опираясь на статистику из статьи Тестовое задание при приеме на работу: делать или нет? Что говорят эксперты и статистика, можно заметить, что две трети респондентов сталкивались с тестовым заданием при приеме на работу.
«Большинство соискателей готовы на тестовое задание, однако у многих есть критичные “но”». |
Если у джуниора (начинающего специалиста) выбора особо нет, и ему, скорее всего, придётся выполнять тестовое, то товарищ с грейдом повыше откажется делать ТЗ с вероятностью, пропорциональной высоте его грейда. К тому же, на IT-рынке наблюдается небольшая оттепель (судя по данным HR Media). Компании уже легко нанимают новичков, а значит, и у джунов появляется из чего выбирать. В таких условиях хорошее тестовое тоже становится отличительной чертой хорошей компании на современном рынке кандидатов.
Поэтому к составлению тестового задания (если уже решились его давать) имеет смысл подойти со всей серьезностью. Это важный инструмент найма, который лучше всех фильтров может сократить воронку кандидатов и сэкономить затраты компании на HR-ресурс, время лидов, менеджмента и т.д.
Поэтому в этой статье я разберу:
зачем в действительности нужны — и нужны ли тестовые задания
каких видов они бывают
как составить и оценить хорошее тестовое задание
Также поделюсь мыслями по поводу всего происходящего. Примеры буду приводить из сферы IT (потому что мне это ближе и проще), но все умозаключения так или иначе можно переложить на любую сферу. Пристегивайте ремни. Поехали!
А точно ли нужны тестовые?
Для начала необходимо остановится и подумать — а зачем вообще нужно тестовое задание?
У него есть две основных цели:
Проверить знания кандидата в общем и целом.
Допустим, у нас большая компания, много разных проектов, и мы нанимаем разработчика. Мы пока не знаем, на какой конкретно проект он попадет; кроме того, велик шанс, что потом его переведут внутри компании на второй, третий, пятый, десятый проекты. Поэтому имеет смысл проверить кандидата на общие знания веб-разработки и инструментов, которые он будет использовать в работе — например, Python, Django, PostgreSQL и т.д.
Проверить что-то конкретное
Предположим, нам нужен специалист, который на высочайшем уровне делает CSS-анимации. Senior CSS Animator — не меньше. Поэтому будет логично выстроить все тестовое вокруг создания необычной или сложной CSS-анимации. Узкое требование — порождает узкое тестовое. В таком случае, знает ли человек Angular или Computer Science уже не так важно.
Всегда ли имеет смысл давать тестовое? Если у кандидата вообще нет опыта, вразумительного портфолио или нам надо проверить «совпадение вкусов», то вполне себе стоит.
Если же мы ищем человека для разработки сайта аптеки, и кандидат в портфолио имеет 40 сайтов аптек, вероятно, на тестовое нет смысла тратить время. Достаточно посмотреть, что он уже сделал. Вот если все его проекты под NDA — тут можно расчехлить тестовое :)
Из этого вытекает логичный, но не всегда очевидный момент — не стоит давать тестовое до скрининга. Скрининг займёт 15-30 минут, но позволит оценить соискателя, примерно понять опыт и потенциально сэкономить время и нам, и кандидату. Если мы на этапе скрининга по тем или иным причинам не пропустим человека дальше, то и нашим коллегам не придётся проверять десятки тестовых (а на проверку уходит время — иногда много времени). При этом и кандидат также не потеряет время, делая тестовое в компанию, куда уже после разговора с HR его не возьмут.
Уважайте своё и чужое время.
Тестовое — не догма, а инструмент нанимающего, причём не единственный инструмент. Именно гибкость владения всем спектром инструментов — залог успешного найма.
Итак, перечислим, какие преимущества и недостатки на данный момент заметны.
Плюсы тестового задания:
Дает возможность верифицировать навыки кандидата (но это не точно).
Позволяет оценить мотивацию кандидатов работать именно в этой компании.
Минусы тестового задания:
Задание нужно проверять, а это время компетентных людей.
Растягивает найм. Чем больше этапов, тем ниже скорость закрытия вакансии и конверсия в найм, что довольно критично, например, для IT-рынка, где количеством доминируют кандидаты.
Можно потерять хорошего кандидата. Есть соискатели, которые не рассматривают или рассматривают в последнюю очередь компании с ТЗ.
Даём тестовое, если нам важно проверить уровень конкретного (возможно специфичного) хард-скилла(лов), либо (как в случае с дизайном или монтажом) хотим проверить совпадение видения определённых моментов (визуал, стиля, чувства кадра, подходов и т.д.).
Чаще тестовое имеет смысл в креативных отраслях:
Дизайнер.
Маркетолог/SMM.
Редактор/копирайтер.
PR.
Если специфики нет, то достаточно первичного отбора HR плюс скрининга с последующим интервью. Если человек действительно разбирается в той или иной области, при личном разговоре это всегда понятно. Да, собеседование не панацея, кандидату могут подсказывать, он может как-то загуглить ответы, но нельзя быть уверенным, что он самостоятельно сделал тестовое.
Не менее важные, а иногда и более важные — софт-скиллы тестовым не проверить. Первый слой можно снять на скрининге, но это не совсем то. Понять, как кандидат общается, воспринимает критику, действует в стрессовой ситуации, можно только в реальной работе, а для этого придумали испытательный срок.
Хрен его знает, на кой ляд тебе это тестовое сдалось, но я в чужие дела не лезу, хочешь дать, значит есть зачем… Постарался разузнать для тебя кое-что по этой теме, а именно — критерии хорошего тестового задания. |
Критерии хорошего тестового
На основании нескольких проанализированных работ (см. Источники) и своего опыта я выделил несколько критериев хорошего тестового задания:
1. ТЗ должно занимать не более четырех часов.
Для мидлов и сеньеров — 2-3 часа (заставлять их работать бесплатно — плохая затея, они просто не будут это делать, благо, статус и спрос на рынке позволяют). Да и, будем честны, странно давать в качестве тестового задания разработку доброй половины проекта, которая займёт неделю. Представим себя на месте кандидата — он должен потратить неделю жизни (ну или четыре дня), чтобы, возможно, затем получить отказ. А теперь представьте сколько времени уйдёт у нашего специалиста, чтобы качественно проверить такой микро-проект. А если тестовое пройдет десять человек, ему придется просидеть несколько дней, а он мог бы сделать что-то полезное — код написать, например :)
Если мы все-таки решили дать «большое» тестовое задание, то срок его выполнения следует рассчитать по схеме: Время на тестовое задание = время, которое затрачивает на аналогичную работу действующий сотрудник Х 2-3
2. ТЗ должно быть понятно составлено.
Нет, это не значит, что там должно быть всё разжевано все до мелочей и отсутствовать пространство для проявления самостоятельности. Но если мы дадим посмотреть ТЗ своим действующим сотрудникам, и у них возникнут проблемы с пониманием происходящего — это сигнал, что ТЗ стоит переработать (как минимум, формулировки). Задание должно быть достаточно подробно составлено, но все же не выглядеть как пошаговая инструкция. Поставьте четко сформулированную цель с понятными критериями ее достижения. В идеале — понятные входные и выходные данные.
Результат выполнения фривольной задачи из разряда «сделай к макету» без четкого ТЗ по технологиям и без четких границ к технике выполнения — не является, на мой взгляд, достаточно репрезентативным и полезным для оценки уровня разраба. © Sergei Sirotenko, TeamLead Frontend Idaproject |
3. Делюсь примером хорошей формулировки (нашел в репозитории с тестовыми) — Win-win.
Качественное и продуктивное взаимодействие между людьми будет достигнуто, когда обе стороны находятся в ситуации win-win (оба выигрывают, получают пользу). Если ТЗ составлено так, что кандидат узнает что-то новое, ему будет интересно или он сможет положить работу в портфолио — это будет дополнительной мотивацией хорошо выполнить задание.
Под «интересным» я подразумеваю что-то необычное, то что НЕ дают в качестве тестового в каждой второй компании — починить неработающий кусок кода, сделать ревью, рефакторинг, покрыть функционал тестами и т.д.
4. ТЗ имеет четкие критерии качества выполнения и сроки.
В ТЗ всегда должно быть понятно, что надо сделать, за какой срок, и какие есть критерии успешного выполнения. Детали реализации при этом отдаём на откуп исполнителю.
Пример:
Endpoint должен отвечать не более чем за 3с.
Должны отсутствовать дубликаты запросов.
Верстка должна соответствовать pixel-perfect.
Задание должно максимально раскрыть, с чем придётся столкнуться в реальной работе. Алгоритмические секции имеют место, но как дополнительный пункт в ходе интервью. ТЗ это, в первую очередь, проверка практических навыков решения реальных задач.
5. ТЗ соответствует уровню сложности кандидата.
Казалось бы очевидный момент, но не стоит задание для джуна нагружать до уровня middle+, чтобы так сказать «проверить глубину». Если задание будет слишком сложным, то с большой долей вероятности, оно не поможет с наймом, а только затормозит его. Задания должны быть приближенными к реальным задачам во время испытательного срока; можно чуть менее детализировано, упрощенно. Если все-таки очень хочется «проверить на прочность» — лучше дать дополнительные задания «со звёздочкой» (справился — молодец, не справился — ну хотя бы обязательную часть сделал, будем думать).
6. Нужно предоставлять полную информацию и инфраструктуру для выполнения тестового задания.
Когда у нас на было тестовое задание для бэкендеров, мы развернули отдельный GitLab и проект с полным ТЗ и шаблоном. От него форкались и пушили туда код. Когда проходил пуш, то через ci\cd организовали интеграционное тестирование проекта. И там бэк сразу видел, что требовалось еще дописать. Это также работает на погружение кандидата в реальный процесс разработки и автоматически снимает часть неопределенности относительно формы сдачи задания.
Не совсем критерий, но важная часть процесса прохождения тестового задания — дать подробный фидбек. Кто-то считает, что это мастхэв, кто-то не хочет тратить время. Тут каждый решает для себя. Я считаю — если хотим давать тестовое, значит хотя бы минимальную обратную связь надо дать. Все равно ревьюер делает заключение по каким-то конкретным моментам. Достаточно просто списком их подсветить. Например:
Допустил наличие N+1
Не придерживается код-стайла
Есть логическая ошибка в реализации алгоритма XYZ и т.д.
Из-за того, что тестовое даём только тем, кто прошел скрининг — мы сокращаем и время работы над фидбэками :)
Не обязательно делать жесткое ревью, достаточно в общих чертах указать на ошибки, расставить точки роста. Это продемонстрирует отношение компании, что сыграет на репутации (вы же не думаете, что соискатели не общаются друг с другом?).
Откуда взять тестовое
Чтобы определиться с вариантами составления тестового, необходимо вернуться к пониманию того, что мы хотим проверить у специалиста — узкий навык или багаж знаний в общем и целом.
Если нас интересует узкий навык — даем небольшое задание на него: нарисовать минутную анимацию, смонтировать три минуты видеоролика, сделать CSS-анимацию, поправить вёрстку страницы на Wordpress и т.д.
В случае с проверкой общих знаний все становится немного сложнее, однако вот вам золотое правило хорошего тестового в моде при любой погоде:
Идеальное тестовое задание — это облегченная версия рабочей задачи или околорабочих процессов (написание тестов, фикс багов, ревью и т.д.)
При составлении кейса нет смысла придумывать из ряда вон выходящую задачу по проектированию двигателя на китовом жиру — берите те задачи, с которыми команда уже сталкивалась, упрощайте их, избавляйтесь от лишних деталей, и суп готов.
Однако недостаточно просто взять задачу, обтесать ее и дать кандидату. Мы все-таки хотим хоть немного проверить соискателя на прочность, поэтому:
Стараемся не разжевывать задачу слишком подробно.
Имеет смысл специально сделать пару пробелов, которые мотивируют кандидата прийти с уточняющими вопросами (а не потерпеть и сделать «как сам понял») или самостоятельно принять ряд решений в спорном вопросе (но обязательно обосновать его).
Даем допзадания «со звездочкой». Так кандидат может «прыгнуть чуть выше головы» и продемонстрировать свою заинтересованность и навыки.
Даем простор для решения, чтобы после выполнения можно было обсудить с кандидатом почему он сделал так, а не иначе.
Приведу пример заданий «со звездочкой», которое и выше головы дает прыгнуть и является отличным плацдармом для обсуждения:
Опишите, как изменится архитектура, если мы ожидаем большую нагрузку (реализация не требуется).
Опишите, как можно защититься от накруток (реализация не требуется).
Попробуйте оценить, какую нагрузку в RPS сможет выдержать ваш сервис.
Как по мне, есть три разновидности тестовых заданий, которые не стыдно дать соискателю для проверки общего уровня знаний и того, насколько он подходит команде:
Немного сломанное решение «боевой» задачи из прошлого опыта компании. Даём готовый код, решающий определённую задачу. В этом коде специально допускаем ошибки. Надо понять что не так, починить и докинуть сверху небольшой дополнительный функционал (по сути, имитация реальной задачи)
Мы ввели тестовые после долгого перерыва — и то лишь для стажеров. Сделали акцент на решении околореальных задач, взяв за основу полностью написанную реализацию. Понаделали в ней ошибок, запутали немного мокапное апи, отразили все это в ТЗ в качестве задачи и дополнительно попросили создать один небольшой компонент (с) Sergei Voronezev, Head of Frontend Direction / Senior Engineering Manager idaproject |
Так мы фактически погружаем соискателя в реальный процесс работы. Когда он придет на проект, ему придется разбираться в кодовый базе, фиксить проблемы и дописывать поверх всего этого новый функционал.
Я опрашивал знакомых разработчиков, и большинству этот вариант показался наиболее привлекательным, а ребята, которые сталкивались с похожими заданиями, даже получили удовольствие от происходящего.
2. Починить тесты (или asserts). Разновидность предыдущего варианта, только здесь мы не просто фиксим баги, а пытаемся починить тесты, которые падают (можно дописать ещё парочку). Тут можно дать как кусочек бизнес-задачи, так и просто набор тестовых кейсов на знание поведения языка. Пример такого тестового задания.
3. Ревью кода — отличный вариант тестового, который вполне подойдет и новичку. Проверяем умение читать код, находить ошибки, смотрим за рассуждениями, проверяем умение анализировать и обосновывать решение. А для грейдов повыше уметь в код ревью определённо мастхэв. Такое задание будет коротким, но может раскрыть кандидата, а также выявить его слабые стороны.
4. Рефакторинг. По аналогии с ревью, только упор на практику. Подходит как джунам, так и серьезным опытным дядям. Рефакторим, разумеется, не весь проект на полмиллиона строк :)
5. Хакатон. Если мы — крупная компания, то хакатон отличный вариант и для того, чтобы решить какую-то из бизнес-задач, и для найма достойных кандидатов.
Если тестовое задание предполагает серьезную работу на большое количество времени (например, неделю), то в идеале его необходимо оплачивать. Это следует обговорить заранее. Тем не менее, если соискатель поймет, что быстрее попытаться получить другой оффер, он все равно не будет делать тестовое — даже за деньги. Готовность оплатить выполнение задания снимает негатив и показывает уважение компании к труду и времени кандидата, но концептуальной проблемы не решает.
Как оценить ТЗ
Первый и главный критерий успешного тестового — поставленная задача решена полностью и отвечает всем критериям (именно для этого критерии и надо прописать).
После тестового всегда имеет смысл обсудить решение с кандидатом: почему сделал так, а можно ли сделать по другому, что изменил бы, если бы было больше времени и т.д. Живое обсуждение всегда показывает ход мыслей соискателя. Добротный кандидат, который немного сплоховал при решении, может раскрыть себя, а человек, который списал (или ему помогли), скорее всего, закопается :) Безусловно, человеку может кто-то подсказывать в наушник, из другой комнаты, в чате и т.д. Но это все-таки более редкий кейс — к тому же, это почти всегда заметно. Это я вам как бывший преподаватель говорю :)
Также я всегда ставлю жирный плюс исполнителю, который сделал в тестовом больше, чем его просили. Например, сделал ER-диаграмму схемы БД, покрыл код тестами, написал документацию, CI/CD, накинул дополнительную анимацию и т.д. Важно, чтобы это не было частью требований или задания «со звездочкой», и кандидат самостоятельно принял решение дать чуть больше, чем требовалось. Это покажет мотивацию и заинтересованность человека в вакансии.
Из этой же логики имеет смысл к основной задаче добавить ту самую подзадачу «со звездочкой». Она требует дополнительного исследования или каких-то иных телодвижений. По опыту могу сказать, что это очень хорошо помогает отсеивать слабых и низко мотивированных кандидатов.
Примеры тестовых для разработчиков
Если очень захотелось подсмотреть, какие тестовые делают другие компании, то рекомендую два источника, которые изучал сам.
Первый — база тестовых заданий от Хекслет.
А второй — список репозиториев на гитхаб с хеш-тегом test-assigment.
Может, найдете для себя что-то интересное. Также это полезно не только тем, кто составляет тестовые, но и тем, кто их проходит.
Заключение
Итак, основные мысли нашей статьи:
тестовое нужно не всегда
тестовое не должно идти первым этапом, до общения с кандидатом
тестовое должно быть понятным, подробным, логичным, структурным
тестовое затягивает процесс найма = риск
время на выполнение тестового — не больше 4 часов, а лучше — 2 часа
платить за тестовое — несложно, но не факт, что его все равно будут делать
всегда имейте альтернативу тестовому: собеседование, лайвкодинг, консалтинг и так далее
тестовое должно быть приближено к рабочим задачам
прописывайте критерии и сроки выполнения задания
давайте дополнительные задачи «со звездочкой»
обсуждайте решение на интервью
обратная связь по ТЗ очень важна
Единственный смысл тестового задания — это сузить воронку, когда у вас не хватает ресурсов со стороны hr. Тестовые задания легко хакаются при помощи гуглинга, друга-программиста Васи и ChatGPT (c) Arseniy Sysolyatin, CTO idaproject |
Используйте тестовое задание как один из инструментов найма, однако не зацикливайтесь только на нём, а старайтесь грамотно жонглировать всем спектром.
Надеюсь, материал был полезен. Согласиться или не согласиться с ним можно в комментариях :) Тема дискуссионная и мне действительно будет интересно почитать, что думают по этому поводу другие.
До скорых встреч на просторах Хабра!
Источники
https://huntflow.ru/blog/test-task/
https://habr.com/ru/companies/agima/articles/765556/
https://yelets.hh.ru/article/27930?ysclid=lyzfkirrsy872076571
https://friend.work/blog/test?ysclid=lyzfko3jdo688079281
https://www.cossa.ru/trends/299599/?ysclid=lyzfkql5ty774577456
https://getcompass.ru/blog/posts/testovoe-zadanie?ysclid=lyzfkvo5ux63278336
