«Дешевле заплатить за плохое тестовое задание, чем работать с неподходящим человеком»

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

Редакция публикует инструкцию от Ясина.

«Давайте смотреть на вещи реально: собеседование - ужасный способ поиска разработчиков и других технических специалистов. Вы не получаете реального представления о навыках и личности кандидата, и часто делаете выбор в пользу неудачных вариантов», - пишет автор заметки.

В качестве примера Ясин приводит материал на Medium, автор которого разобрал основные способы найма разработчиков и рассказал, какие из них не работают и почему. Из всех советов Ясин выделяет два.

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

Почему платить за выполнение тестового задания - выгодно

Для работодателя:

• Кандидат получает деньги и чувствует, что попал в реальную рабочую ситуацию, - а значит, прикладывает максимум усилий к поиску решения.
• Такая практика наглядно показывает кандидату, как компания относится к своим сотрудникам.
• Это позволяет работодателю испытать кандидата в «боевой» обстановке - притом с минимальным риском. Общее обсуждение помогает понять, как кандидат общается с коллегами, как отстаивает свои решения, принимает критику и задают вопросы.

Для соискателя:

• Кандидат получает возможность посмотреть, как работает команда и как руководство относится к своим сотрудникам.
• Соискатель также получает возможность продемонстрировать свои дополнительные навыки, которые не перечислены в резюме, или на которые не обратил внимания рекрутер.
• Работодатель может узнать, что на самом деле считает важным соискатель. «Возможно, он не тестирует каждую строчку кода - и у него будет шанс рассказать, почему он так делает, и может быть, он даже окажется прав. Вы никогда не сможете получить такой информации, просто спросив на собеседовании, придерживается ли кандидат методологии TDD».

Амир Ясин приводит шесть основных правил, которых он придерживается при найме с помощью оплачиваемого тестового задания.

1. Для выполнения задания кандидату нужны выходные

По словам Ясина, ни один разработчик не сможет продемонстрировать свои лучшие навыки, если на решение задачи у него есть всего два часа. «Я приглашаю соискателей в свой офис в пятницу и объясняю им проблему, которую предстоит решить. В понедельник мы изучаем и обсуждаем получившиеся результаты», - объясняет автор заметки.

При этом Ясин объясняет, какие технологии нужно использовать для решения, и предоставляет к ним доступ. В то же время разработчикам не запрещается использовать другие инструменты по своему усмотрению. «Например, я даю задание реализовать решение на JavaScript, а какую библиотеку использует разработчик - Kefir, Bacon или RX - мне не важно».

2. Не стоит давать кандидату реальную проблему, для решения которой требуется освоение множества инструментов

«Нельзя просто посадить соискателя за компьютер и сказать ему: решите вот эту проблему. Она возникла у нас в процессе работы и для выполнения задачи вам понадобится владеть всеми инструментами, которым мы обучили работников. Дайте ему отдельную задачу, которая не требует глубоко знания контекста», - говорит Ясин.

3. Решение задачи должно быть ясно определено, но у кандидата должна быть возможность внести в него улучшения

«К примеру, если я нанимаю веб-разработчика, я даю ему четкую инструкцию: создать одностраничное приложение, которое позволит пользователю хранить домашнюю коллекцию фильмов, иметь доступ к ним в офлайн-режиме и искать нужные фильмы. Поиск - по названию, жанру и актерскому составу», - объясняет автор материала.

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

«Я не говорю разработчику: "Знаете, мне очень нравится смотреть фильмы, сделайте для меня хороший киносайт" или "Представьте, что вам нужно спроектировать IMDb с нуля". Задача должна быть достаточно простой, чтобы соискатель успел решить ее, и в то же время интересной - чтобы он мог продемонстрировать свои навыки и создать нечто особенное».

4. Разработчик обязательно должен представить свое решение команде

Самая большая проблема среди разработчиков, пишет Ясин, заключается в том, что они слишком стараются защитить свое решение. И работодателю стоит узнать, как кандидат реагирует на критику. «Если они немедленно занимают оборонительную позицию - это никуда не годится. Есть разница между защитой и обороной. Защита основана на фактах, оборона - на эмоциях», - объясняет он.

При этом, замечает Ясин, очень важно, чтобы все в команде основательно подготовились к мероприятию и изучили поставленную задачу.

5. Проблему нужно описать письменно

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

6. Оплатить выполненную задачу следует сразу же после завершения обсуждения в понедельник

«Не важно, собираетесь ли вы нанимать соискателя - лучшее, что вы можете сделать как для начала, так и для окончания отношений - выписать чек сразу после командной встречи», - говорит Ясин.

Нанимать или не нанимать

Предприниматель приводит несколько признаков, которые сигнализируют о том, что соискатель достойно справился с задачей:

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

Признаки того, что нанимать кандидата не стоит:

• Соискатель отказывается выполнять задачу, мотивируя это тем, что другие компании готовы нанять его и без тестового задания.
• Решение не соответствует поставленной задаче.
• Кандидат не может аргументировать свои решения.
• Он занимает оборонительную позицию на встрече.