бессмысленно или сложно, то необходимо воспринять это как маячок. Тут как в старой шутке: если и третий муж бьет… Да, шутка дурацкая, сексистская, но смысл понятен: может, проблема не в кандидатах.
В таком случае разузнайте у недовольных, что именно их не устраивает в задании, чтобы потом аргументированно обсудить проблему с тимлидом. Это наглядно продемонстрирует кандидату, что вам не все равно, покажет вашу заинтересованность и гибкость в принятии решений. Главное — не забыть объяснить, что задаете вопросы не из праздного любопытства, а чтобы обсудить с нанимающей стороной.
Если же в среднем отзывы о тестовом задании нормальные, а недовольны лишь несколько человек, то можно предположить, что дело именно в них, а не в чем-то другом.
Часто кандидат, не желающий выполнять тестовое задание, предлагает нам вместо этого посмотреть примеры его кодов с GitHub и по ним оценить его способность выполнять поставленные задачи.
С одной стороны, это действительно хорошая идея: если у человека в репозитории есть какая-то задачка, которую он реализовал, тимлид может оценить стиль его работы. С другой стороны, мы не можем доподлинно знать, как именно выполнялась эта работа, в какие сроки, самостоятельно или в команде. При этом коммерческие проекты, которые могут быть подтверждением профессионализма человека, порой запрещено разглашать. А именно они представляют для нас наибольший интерес.
Так что, несмотря на наличие у большинства разработчиков кусков кода, которые они могут показать на GitHub, это далеко не всегда является заменой тестовому заданию. Поэтому нам придется его давать. И возникает вопрос: как сделать так, чтобы человек не отказывался его выполнять?
Как я уже говорил в начале книги, нет смысла продавать всем одно и то же, по стандартной схеме. Мы должны исходить из каждого конкретного случая. Поэтому в процессе беседы важно узнать, что для человека важно в работе, почему он ищет новое место, что его устраивает или не устраивает, какие у него мотивы, — и подбирать аргументы, исходя из этой информации.
Если кандидат не хочет выполнять задание, хорошо бы выяснить, что конкретно его смущает. Возможно, у него был какой-то негативный опыт по этой части: например, дали большое сложное тестовое задание, он его выполнил, потратил время, а фидбэка не получил? Мы ищем те причины, которые могут объяснить отказ кандидата от выполнения тестового задания (обычно их от одной до трех) и отдаляют нас от оффера.
У некоторых кандидатов есть определенный страх, что компании могут так решать какие-то свои задачи: просят кандидатов выполнить тестовое задание, а потом используют полученные куски кода. В реальности я ни разу не сталкивался с такой ситуацией, но, если у людей есть подобный страх, можно предположить, что он возник не на пустом месте. Однако в каждой конкретной ситуации важно понять: сомнения кандидата вызваны его личным опытом или опытом коллег, или это просто абстрактный страх? Исходя из этого вы уже сможете выстроить свою «продающую речь» — подобрать те аргументы, которые актуальны именно для этого человека. Не забывая, что немаловажно, про ответственность за сказанное.
Иначе мы можем «продавать» налево и направо, рассказывая, что тестовое задание — это легко, просто формальность, да вы справитесь на раз, и все у нас будет прекрасно! А потом вдруг возникнет ситуация, когда задание не проверили, или проверили очень и очень нескоро, предоставили неадекватную обратную связь или просто молча не взяли.
Вот вполне универсальный аргумент для негативно настроенного кандидата: тестовое задание — это проверка не только для него, но и для компании. Посмотрев на тестовое задание, он сможет оценить сложность задач, которые ему предстоит выполнять, а также адекватность тимлида: как он дает задания и предоставляет обратную связь. Мало кто захочет работать с руководителем, который пишет задачи «на коленке» или набирает команду на основе теоретических задач, не имеющих отношения к реальности. Такой подход задает тренды всего рабочего общения, и об этом кандидату лучше узнать заранее, еще до трудоустройства.
Конечно же, приводя этот аргумент, вы должны быть уверены в своем тестовом задании, иначе своими громкими заявлениями мы сами роем себе яму.
Итак, если обобщить все то, о чем мы говорили, то тестовые задания — это серьезный камень преткновения. У заказчика, как правило, не хватает времени, чтобы полноценно подготовить задачу. У кандидатов наработан большой опыт выполнения заданий «ни о чем», поэтому даже если у вас хорошее тестовое, кандидат может сомневаться, стоит ли его делать. В итоге решение о том, приступать ли к заданию, зачастую принимается по результатам первичного контакта: кандидат смотрит, как строится взаимодействие, и только потом берется или не берется за тестовое задание.
Из-за всех этих сложностей текст могут давать на разных этапах общения с кандидатом. Иногда его присылают перед собеседованием, чтобы человек сразу оценил, стоит ли ему пытаться трудоустроиться именно в эту компанию. Или, наоборот, задание дается в самом конце, после технического собеседования, когда кандидат уже познакомился с командой, понял, с кем и как ему предстоит работать, обсудил важные для него вопросы — и теперь готов показать себя в деле. Варианты развития событий могут быть любыми, и когда именно приступать к тестированию — полностью зависит от ваших реалий.
Что особенно важно для рекрутера во всей этой ситуации? Повторюсь: во-первых, надо заранее обговорить с заказчиком, что именно дается в виде теста. А во-вторых — держать руку на пульсе, то есть давать своевременную обратную связь обеим сторонам, поскольку мы сами не можем ни повлиять на содержание задания, ни проверить качество его выполнения.
Вообще тема обратной связи достаточно болезненна для кандидата, и более детально об общих правилах обратной связи мы поговорим чуть позднее. В контексте же тестового задания нам важно понимать, что кандидату необходимо получить более-менее аргументированный отклик на свою работу. Поэтому, общаясь с тимлидом, нам важно получить побольше «мяса» — фактов о качестве выполнения задания, о том, что конкретно понравилось или не понравилось. Среднестатистический ответ должен строиться по принципу: «Вот эту задачу ты выполнил хорошо, а вот здесь можно было бы использовать другие инструменты, например…» Просите тимлидов написать хотя бы два-три корректных предложения, которые дадут человеку чуть больше конкретики, нежели «вы нам не подходите». Потому что в ответ на такое заявление у человека возникает вполне резонный вопрос:
— А почему?
— Потому что плохо выполнено тестовое.
— А что именно не так?
Возможно, под «плохо выполнено» имеется в виду, что оно выполнялось долго. Или в нем использовались не те инструменты, которые актуальны для тимлида. А может, оно было выполнено нормально,
