Нояб. 30

Почему не стоит давать тестовые задания. И почему не стоит их делать

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

Для начала определимся с контекстом. Тестовое задание (домашнее задание, ДЗ) — это задание, выполняемое кандидатом вне собеседования, схожее с его должностными обязанностями. Далее мы будем рассматривать применимость ДЗ как этап фильтрации кандидатов на позиции разработчиков. Скорее всего, похожие проблемы будут возникать и при найме других технических специалистов.

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

Чтобы понять, насколько применимо ДЗ для поиска специалистов, попробуем ответить на 2 вопроса:

Какие выводы можно сделать из невыполненного задания?
Какие выводы можно сделать из выполненного задания?

Какие выводы можно сделать из невыполненного задания

Можем ли мы сказать, что кандидат не является хорошим специалистом, если он не выполнил ДЗ? К сожалению, нет. Оказывается, что у людей бывают и другие интересы помимо программирования. И поскольку программированием человек занимается 8 часов (ну или 4-6) на работе, то в свободное время ему логично уделять другим своим интересам. Те же, кому не хватает 8 рабочих часов для любимого занятия, довольно часто имеют свои пет-проекты, и совсем не факт, что ваше ДЗ будет интереснее, чем уже начатые проекты. Бывает и еще одна категория людей — те, у кого не установлено все необходимое для работы на домашнем компьютере. Таким образом, в придачу к тем, кто не может выполнить задание, мы также отсеиваем тех, кто не хочет выполнять или не может выделить достаточно времени на выполнение задания.

Какие выводы можно сделать из выполненного задания

ДЗ часто используют при найме джунов, так как с начинающими специалистами не поговоришь об их прошлом опыте. И если джун сделал ДЗ, то, скорее всего, он имеет больший потенциал чем тот, кто не выполнил. Но тут не стоит забывать про такое интересное словосочетание как «намутить лабу». Если синьор, с большой долей вероятности, не будет заморачиваться с поиском решения в интернете и просить товарищей сделать тестовое, то вот с джуниорами все может оказаться (и на практике оказывалось) не так радужно. И тут ДЗ может сыграть с вами злую шутку, поскольку на момент собеседования у интервьюера может сложиться излишне позитивное впечатление о кандидате, так и кандидату проще «сдавать зачет», когда он знает подмножество тем.

Излишне позитивное впечатление от ДЗ может создать похожие проблемы и при найме «не джуниоров». Как-то во время собеседования у меня не спрашивали ни одного вопроса по Spring, потому что «из моего решения было очевидно, что у меня большой опыт с этим фреймворком». На тот момент мой опыт со Spring состоял из 2 просмотренных видосиков и проекта длиной в 3 дня.

Размер и типы заданий

В размере тестового задания как раз и кроется основной фактор, который делает его неэффективным инструментом. Если задание занимает менее часа, то его вполне можно дать во время собеседования. При таком подходе есть возможность проверить те самые «problem solving skills», которые многие путают с алгоритмическими задачками. Как раз благодаря небольшому времени на решение довольно популярны алгоритмические задачи. Из плюсов таких задач можно отметить простоту проверки, ибо если код читабельный (это требование актуально для всех адекватных компаний), то на проверку такой задачи уйдет минут 10-30. А еще есть Codility и другие сервисы, которые позволяют автоматизировать процесс. К сожалению, у этого подхода есть небольшой недостаток: сама алгоритмическая задачка проверяет только знание кандидатом конкретного алгоритма (максимум группы алгоритмов). Многие подсознательно устанавливают порядок между базовыми знаниями CS и всем остальным (работа с БД, корректное применение паттернов, умение писать тесты и т.д.). В реальном мире эти навыки параллельны.

В задание менее 4 часов довольно сложно впихнуть задачу, требующую большего, чем просто выполнение механических действий. Именно поэтому типовые задачи в диапазоне 2-4 часа — это напилить CRUD, разобраться с API или инструментом. С точки зрения проверки такого задания, оно схоже с ревью небольшого незнакомого вам проекта. Если задача — просто быстро понять, нет ли грубых залетов, такое ревью можно и на 15 минут сделать. Но в таком случае зачем было давать тестовое, подобное решение может быть закрыто прочтением резюме и тем же 15-минутным общением с кандидатом по телефону (если уж хочется сэкономить время на проведение собеседования). Более же вдумчивое ревью займет минут 30-60, что соизмеримо по времени с общением на интервью, но проверяющий не имеет возможности уточнить, почему были приняты те или иные решения, в отличие от интервью.

Задания от 4 часов до 2-3 дней. Из позитивных моментов, вы сможете проверить насколько кандидат мотивирован получить работу в вашей компании (по крайней мере насколько он прямо сйечас мотивирован). При этом в плане затрат вашего времени на вдумчивую проверку задания уйдут те же 30-60 минут, но уже с большей вероятностью 60, чем 30. На таких заданиях уже можно ожидать какого-то определенного уровня качества. При этом нужно понимать, что любое решение задачи — это всегда trade-off между качеством и скорость выполнения. И вполне может оказаться, что решение было сделано хуже, чем могло бы быть, как раз потому что кандидат не сложен к overengineering. Чтобы узнать, почему было принято определенное решение, нам нужно таки провести собеседование. Таким образом, мы потратили дополнительно час своих работников. Также необходимо понимать, что любое задание, которое занимает больше одного вечера (теоретически вечер — это 4 часа, в реальности — 2), очень существенно уменьшает количество желающих его выполнять.

Идеальное тестовое задание — это испытательный срок (ИС). Практика показывает, что большинство негативных моментов связанных с компетентностью человека и его умением работать в команде, всплывают в первую неделю-две испытательного срока (конечно же, бывают случаи, когда такие моменты проявляются уже после ИС, независимо от его длины :) ). Поэтому некоторые компании практикуют ДЗ на 3-5 дней. За этот период мы можем увидеть, как человек решает достаточно комплексные задачи, насколько качественный код он выдает, как общается с командой (уточняя требования, например). Тут есть 2 проблемы. Первая — затраты времени со стороны компании будут составлять где-то 1 час на день задания. Вторая проблема состоит в том, что множество людей, которые согласятся его выполнять, будет сведено к тем, у кого (на момент решения задания) достаточно свободного времени, чтобы впихнуть в него 24-40 рабочих часов, и достаточно денег, чтобы потратить 24-40 часов не на работу и не на отдых. Хотя это, наверное, не проблема, а просто новый вызов для ПМов и ХРов: как мотивировать такого человека работать предсказуемо в течение длительного периода времени :)

Ранее были описаны случаи, когда ДЗ идет как этап, предшествующий интервью. Бывают случаи, когда ДЗ дают после интервью. Зачем же? Формулировки бывают разные, но они сводятся к тому, что после интервью наниматель не получил достаточно информации, чтобы принять решение. К сожалению, ДЗ и в этой ситуации не помощник. Тут нужно приводить в порядок процесс самого интервью. Понять, что человек не подходит, можно за 15-45 минут, понять, что человек подходит, можно за 30-60. В этом случае ДЗ — это просто попытка интервьюера снять с себя ответственность.

Еще одним видом ДЗ являются задания непосредственно перед интервью, прямо в офисе компании. Несмотря на то, что такие задания очень схожи с практическими заданиями, решаемыми прямо на интервью, они имеют ряд недостатков. Наиболее заметным является то, что мы теряем возможность оценить те самые problem solving skills, так как мы не видим ход мыслей кандидата, а видим лишь результат. Также одним из подводных камней этого подхода является, то что кандидата нужно не забыть уведомить заранее, что ему придется часок-другой провести в переговорке наедине со стопкой бумаги или ноутбуком. Подобный сюрприз может негативно сказаться на желании кандидата работать в компании и на тех отзывах, которые он будет давать о компании.

Когда тестовое задание эффективно

Как ни странно, тестовое задание является очень эффективным способом уменьшить поток кандидатов на интервью. Единственное, что надо понимать — уменьшение будет происходить не столько за счет отсеивания менее квалифицированных кандидатов (как этого бы хотелось), а в основном за счет отсеивания менее мотивированных в данный момент. Но даже с учетом этого, вопрос с долгосрочной мотивацией останется открытым.

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

Но я люблю делать тестовые задания

Бывают случаи, когда кандидаты предпочитают делать ДЗ. Наиболее распространены 2 типа мотивации: кандидату интересно делать ДЗ, кандидат предпочитает сделать ДЗ вместо «задачи на бумажке». В первом случае все намного проще: нравится — делайте. Но, возможно, стоит задуматься о более предсказуемых способах получения задач для своего хобби или самообучения. Второй же случай сигнализирует о серьезном пробеле в ваших профессиональных навыках. Ибо, как указывалось ранее, «задачки на листиках» проверяют во многом способность человека получить необходимую для решения информацию и объяснить свой подход другому человеку (интервьюеру или члену команды).

Image by Visual Generation