Как стать программистомКарьера

Тестовое задание не нужно?

Ранее я уже писал о собеседованиях, задачах, которые любят давать на них, и вообще о процессе найма. Ещё одной частью этого самого процесса у многих компаний является тестовое задание. Многие работодатели любят таким использовать его как инструмент получения более подробной картины знаний у кандидата. Но получают ли они её?

Довольно часто в отношении тестовых заданий льётся негатив со стороны специалистов. Тому есть множество причин: огромный объём работы, бессмысленность задачи, даже попытки решить внутренние проблемы руками соискателей. Но однозначно говорить о том, что тестовое задание бесполезно, я бы не стал. Многое в нём зависит от контекста.

Спасибо XanderToons за картинку в тему 🙂

Чего хотят (в идеале) достичь компании тестовым заданием?

  1. Подтвердить уровень знаний кандидата
  2. Посмотреть на работу с кодом/архитектурой
  3. Показать типовые задачи в работе

Чего обычно достигают компании своим тестовым заданием?

  1. Режут воронку найма
  2. Убирают часть толковых спецов
  3. Дают типовые задачи, которые ничего не показывают

Сам же контекст определяют следюущие вещи

  1. Кого Вы собеседуете? Это джуниор или лид?
  2. Какую ценность несёт задача?
  3. Какую временную нагрузку имеет тестовое задание?

Давайте разбираться с каждым и решать, что же делать.

Контекст позиции

Рынок IT полон вакансий, но испытывает дефицит квалифицированных кадров. То есть, настоящие (а не нарисованные в резюме) middle и выше специалисты будут иметь более, чем один оффер за несколько дней поиска. Но предварительно он потратит N часов на собеседования. А с учётом того, что компании любят устроить несколько этапов, то времени и сил на выполнение тестовых заданий у таких специалистов просто не остаётся.

Вспоминая свой опыт трудоустройства в позициях middle и senior, могу сказать, что в день доводилось проходить по 3-4 собеседования. После такой эмоциональной встряски хочется просто отключиться и отдохнуть, а не возвращаться к сложным задачам при всей моей любви к их решению. И представьте, если каждая компания даст по тестовому заданию — это уже человекодни работы!

Можно ли сказать, что соискатель на middle+ слаб, раз не выполнил тестовое задание? Нет. Скорее всего у него нет времени. А большинство компаний — это компании без громкого имени, чтобы одна только возможность поработать у них мотивировала на многочасовые испытания.

Также стоит обратить внимание на то, когда даётся тестовое задание — до или после общения. Очевидно, что после общения человек может получить некий интерес в отношении компании, что будет дополнительно мотивировать его на выполнение задания, но необязательно. Вы расширите воронку найма, но не решите проблемы.

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

Если джуниор выполнил тестовое, то он с большой долей вероятности имеет бОльший потенциал в сравнении с остальными. Но не забывайте, что он мог и «списать». Поэтому тестовое задание не будет отменять собеседования и обсуждения результатов задания.

Решение:
Тестовые задания имеют наибольшую ценность с джуниорами, чтобы отфильтровать наиболее подходящих. Тестовые задания для миддлов и выше падают в ценности и скорее вредят. Несколько раз подумайте о том, зачем Вы даёте тестовое.

Если же даёте тестовое задание, возвращайтесь для обсуждения его результатов. Хотя бы для того, чтобы убедиться, что человек сам писал код.

Контекст ценности

Как часто Вы встречали в тестовых заданиях действительно увлекательные задачи, которые хочется решить? В большинстве своём они стандартны — надо что-то развернуть, создать данные или распарсить их, или решить типовую алгоритмическую задачу. Это связано с тем, что в компании процесс найма выстроен плохо. Наниматель (тимлид или CTO) не понимает, какие реально знания ему нужны, но с другой стороны сталкивается с тем, что с рынка приходит много некомпетентных специалистов. И начинается борьба некомпетентного решения с некомпетентными соискателями. Что самое плохое, страдают от этого вполне стоящие люди.

В сотый раз писать одно и то же неинтересно никому. А ещё большее негодование вызывает постановка задачи. В работе хороший программист привыкает задавать вопросы, уточнять реализацию. Но в виде тестового часто получает сферического коня в вакууме. Либо получает возможность задавать вопросы, но это растягивается на длительное время, что тоже плохо.

Решение:
Если уж Вы собрались давать тестовое задание, подумайте, как оно расскажет о Вас, как о компании? Поможет ли оно сформировать кандидату понимание о том, над какими задачами ему предстоит работать?

К примеру, мы со студентами в конце курса PHP работаем над финальными проектами, где они в команде могут написать проект на тему, предоставленную компанией-партнёром. И здесь партнёр явно показывает специфику своих задач. С одним лишь только НО — эти проекты пишутся командой из 3-4 человек в течение месяца.

Контекст ресурсов

Теперь про время. Обычно создатели задачи думают: «Это должно занимать около 2-3 часов». Когда Вы в последний раз писали код с нуля?
Надо развернуть стенд, настроить IDE для интеграции с ним, продумать хотя бы какую-то архитектуру. И мы снова скатываемся в то, что у нас выходит типовая задача — это запрогать CRUD, может быть присобачить API (и то, если у Вас фреймворк). Какова ценность такого задания? Человек либо будет впопыхах делать что-то и наваяет не весть что, либо будет пользоваться стандартными инструментами фреймворка, а значит ценность такого кода тоже будет невелика (разве что умение пользоваться кодогенератором покажет).

А потом это задание надо ещё и проверить, что займёт полчаса-час уже Вашего времени или времени Ваших сотрудников.

Ценность, как видите, резко падает. Но чем заменить такую проверку? Давайте углубимся в корень проблемы. Мы хотим все таки посмотреть, как человек пишет код и/или работает с кодовой базой. Само собой напрашивается решение в виде доступа к GitHub-репозиторию соискателя. Но мы живём в мире NDA, так что часто кроме pet-проектов, которым соискатель не уделяет много времени, мы там вряд ли найдём что-то серьёзное, если найдём что-то вообще.

Решение:
Я уже не в первой команде применяю отличный способ проверки знаний, который называю «Эталонный говнокод». Это кусок кода размером в 1-1.5 листа А4 (либо его экранном эквиваленте), который проверяет всё, что мне и моей команде надо проверить

  • Знание синтаксиса языка
  • Умение применять принципы DRY, KISS, SOLID, YAGNI и т.п.
  • Знание стандартов и code conventions
  • Умение анализировать код и запросы до их запуска в Production
  • *впишите здесь код, который будет отражать умение по Вашему требованию*

Такую задачу мы даём прямо на собеседовании, и она занимает до 30-40 минут, но даёт отчётливое понимание скилов. Самое главное, что мы идём от обратного, задавая вопрос: «Что не нравится в этом коде?». Удивительно, но на одном и том же коде я могу проверять соответствие

  • джуниоров, обращая внимание на грубые ошибки
  • миддлиов, обсуждая, к примеру, применимость Inversion of control
  • сеньёров, говоря про Highload и архитектурные вещи

Не могу не отметить, что со временем этот тестовый код под присмотром команды оброс различными дополнениями и спецификами. Но суть не утратил.
По итогам, мы отказались от тестовых заданий в 95% случаев, давая их только тогда, когда относительно кандидата начинаются прения.
Но и здесь не стоит забывать, что самое лучшее тестовое задание — это испытательный срок. Именно здесь человек показывает свои реальные навыки, а в случае несоответствия ожиданиям процесс расставания лёгок и просто. Но это уже отдельная тема для разговора 🙂

TL;DR

Любое тестовое задание — это не только проверка кандидата на знания и мотивацию работы у Вас, но и испытание самой компании в том, чтобы не выстрелить себе в ногу в попытке отфильтровать поток соискателей.

Я придерживаюсь мнения о том, что кроме Junior позиций, поиск не требует тестовых заданий, ограничиваясь обсуждением кода на собеседовании и изучением GitHub. А как относитесь к тестовым заданиям Вы?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *