Перевод статьи «Are tech tests still relevant in today’s hiring landscape?».
Я недавно написал статью о поиске работы в сфере технологий, в которой поделился своим опытом и дал несколько советов. Эта статья послужила началом нескольким дискуссиям с бывшими коллегами и друзьями, в настоящее время находящимися в поисках работы. И эти дискуссии неизменно приводили нас к обсуждению пугающей темы тестовых технических заданий.
Это заставило меня задуматься над тем, насколько релевантны технические задания на сегодняшнем рынке и являются ли они по-прежнему полезным инструментом.
Проблема технических заданий
Кто-то когда-то решил, что в процедуру найма разработчиков нужно включить технические задания, поскольку они являются хорошим показателем способности кандидата написать заданный код на соответствующем языке. Это должно давать интервьюерам понятие о технических знаниях кандидата.
Но проблема в том, что большая часть технических заданий недостаточно продуманны и могут страдать от ряда проблем:
- Наниматель, принимая решение, пользуется результатами техзаданий как единственным мерилом знаний кандидата (причем, отнюдь не объективным).
- Тестовые задания не слишком хорошо охватывают технические навыки кандидатов и не дают понимания, насколько глубоко кандидат знает язык программирования.
- В лучшем случае задания бывают слишком поверхностными.
- Они могут быть слишком большими.
- Они не позволяют определить или измерить другие жизненно важные вещи, например, уровень эмпатии, навыки коммуникации или даже умение мыслить логически и решать задачи.
- Техзадания не отражают того, с чем разработчику придется сталкиваться в реальной работе.
Как хорошие тестовые задания превращаются в плохие
Существуют, конечно, и другие проблемы, как и в любом другом процессе. Но в приведенном выше списке есть пара пунктов, которые я хотел бы раскрыть подробнее, поскольку считаю, что они совершенно не помогают (и даже мешают) достижению основной цели техзаданий.
Слишком поверхностные задания
Я видел тестовые задания, которые давались на собеседованиях на позицию full-stack разработчика. Кандидат должен был добавить несколько свойств в класс C# и связать их с полями формы в UI.
На это задание отводилось около 40 минут. Больше, чем достаточно. Но больше, чем достаточно времени для чего? Чтобы впихнуть кнопки в форму в .Net, передать значение методом POST и привязать его к каким-то свойствам класса?!
Когда предлагаемое задание настолько простое, начинаешь думать, что в нем вообще нет никакого смысла. Оно вряд ли покажет наличие навыков, выходящих за пределы руководства по C# для начинающих. А на выполнение этого задания отводится 40 минут, которые вы могли бы потратить на то, чтобы обсудить с кандидатом его подход к решению больших рабочих задач или его способности работать в команде.
Если вы хотите дать кандидату техническое задание, оно должно соответствовать вашей вакансии и быть достаточно содержательным, чтобы дать вам нужные сведения о навыках кандидата.
Масштабные неоплачиваемые проекты
Другая крайность – слишком монолитные задания, практически являющиеся отдельными проектами. Но ведь более сложное задание, напоминающее проект, решает проблемы, озвученные в предыдущем пункте, верно?
Да, решает, но есть одно «но».
Вы гораздо лучше сможете оценить, на что способен ваш кандидат, но есть одна проблема, и она заключается не в размере задачи. Дело в том, что довольно часто от кандидата ожидают, что он потратит на выполнение задания много часов своего времени, причем сделает это бесплатно.
Да, это кандидаты приходят к вам (а не вы к ним), это они ищут работу в вашей компании, но процесс найма это в любом случае улица с двусторонним движением. Кроме того, кандидаты могут подавать заявки на множество разных позиций – только представьте, что по каждой из них человек получит задание на 5-6 часов работы! А ведь вы по сути просите их бесплатно написать для вас мини-приложение.
В такое неудобное положение часто попадают дизайнеры. Перспективные клиенты обесценивают их навыки и время (впрочем, непреднамеренно), требуя выполнения большого количества работы по спецификациям. При этом они ссылаются на то, что благодаря этой работе кандидат сможет «выиграть тендер» или «получить работу».
Индустрия дизайна борется с подобными явлениями, пример этого – сайт No!Spec.
Нет ничего плохого в том чтобы посмотреть, как кто-то работает, но не просите людей тратить слишком много времени зря, лишь в обмен на перспективу попасть на финальное собеседование.
Технические задания фокусируются только на чисто технических навыках
Хотя прямой целью технического задания является решение данной кандидату задачи, под ней должна скрываться другая: увидеть, как человек подходит к решению задачи, как он разбирается с проблемами.
Узнать это можно, главным образом, обсуждая проекты, над которыми человек работал, ситуации, в которых он оказывался. Техническое задание может подтвердить сведения, полученные в ходе беседы, а также продемонстрировать некоторый уровень компетентности в рассматриваемом вопросе.
Но решение о найме кандидата должно, на мой взгляд, зависеть от ответов на следующие два вопроса:
- Насколько хорошо этот человек подойдет нашей компании, сработаемся ли мы с ним?
- Может ли он учиться, развиваться и расти?
Конечно, это касается не всех сфер деятельности. Не думаю, что стоит нанимать кардиохирурга, исходя только из его смелости и уверенности в себе. Но вместе с тем не стоит и отвергать опытного разработчика с аналитическим складом ума лишь потому, что он не знаком с ReactJS.
Строгие условия технических заданий не соответствуют практике реальной работы
Также мне случалось встречать (и выполнять) тестовые задания с очень жестко прописанными условиями. Эти условия могут включать что угодно. Например, там может значиться «без доступа к интернету», могут быть ограничения по времени, не соотносящиеся с количеством работы, а могут быть и связывающие жесткие стандарты написания кода.
Да, какие-то ограничения нужны, например, относительно времени. Но если мы даем нереалистичные ограничения, которые не встречаются (по крайней мере, не должны встречаться) в настоящей работе, мы не можем увидеть, как кандидат поведет себя в реальной, жизненной ситуации.
Я хочу сказать, кто из нас не искал помощи на Stack Overflow или не обращался к документации, потому что не мог удержать весь API JestJS в голове?
В чем польза тестовых технических заданий
Технические задания могут помочь объективно оценить подход кандидата к решению задач. Также на примере задания можно увидеть, как человек справляется с задачами – в том, что выходит за рамки чистого кодинга: как он комментирует код, насколько эффективно он пишет функции, какого стиля написания кода придерживается и т. п. Здесь тестовые технические задания могут оказать огромную помощь.
На примере тестового задания можно увидеть сильные и слабые стороны владения языком или фреймворком, или даже подход к шаблонам проектирования (SOLID, DRY). Но результаты выполнения технических заданий сами по себе не должны определять успех кандидата.
Хорошие технические задания:
- Достаточно глубоки, чтобы дать интервьюеру достаточно данных.
- Оплачиваются (в случае объемных заданий), чтобы возместить кандидату потраченное время и расходы.
- Являются частью профайла кандидата, но не решающим фактором.
- Имеют реалистичные, справедливые ограничения.
- Не рассматриваются как единственный показатель уровня навыков.
Технические задания все еще существуют, но…
Тестовые задания по-прежнему применяются и могут приносить пользу в плане составления общего впечатления о кандидате, но для этого в них должен быть выдержан баланс. Они должны быть достаточно сложными и большими, чтобы их вообще стоило выполнять, и при этом достаточно маленькими, чтобы не забирать слишком много времени в процессе найма. Они должны быть спроектированы таким образом, чтобы хорошо служить в качестве части общей картины.
И не забывайте, что сегодня есть много других способов проверить технические навыки кандидата: портфолио на GitHub, участие в NPM-разработке, рабочие веб-сайты. Все это можно обсудить на собеседовании, чтобы разобраться в том, как кандидат подходит к процессу разработки и принятия решений.
