Технические задания в процессе найма программистов: нужны ли они?

0
919
views

Перевод статьи «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-разработке, рабочие веб-сайты. Все это можно обсудить на собеседовании, чтобы разобраться в том, как кандидат подходит к процессу разработки и принятия решений.

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here