И что следует использовать вместо тестовых заданий
Представьте, что вы директор небольшой средней школы, который хочет нанять новых учителей. Поскольку у вас в штате их должно быть не более 20, вы должны убедиться, что каждый учитель, которого вы нанимаете, сможет преподавать в любом классе. Усложним пример. Недавно уволилась одна из лучших учителей с более чем 15-ти летним стажем, и которая была наставником для многих более молодых сотрудников. Кем вы сможете её заменить?
После некоторых раздумий, вы создаёте, как вам кажется, творческий подход к интервьюированию. Когда кандидат придёт на интервью, вы попросите его провести урок, взятый из учебной программы средней школы. Поскольку вы хотите убедиться в том, что кандидат хорошо подготовлен, то вы не скажете ему какой урок он должен будет преподать. Если он справляется с таким заданием, то вы делаете вывод, что он с лёгкостью сможет провести любой урок, так как он хорошо себя проявил со случайно выбранной темой.
Вы размещаете объявление о найме и, через некоторое время, несколько интересных кандидатов подают заявки. Однако, протестировать свой новый подход вы планируете на учителе, которого рекомендовал один из ваших сотрудников, который работал с ней в прошлом, как классного специалиста. Вы не верите в своё счастье, что она вообще согласилась, и думаете, что она будет идеальным подопытным кроликом в вашем эксперименте. Вы связываетесь с ней, чтобы назначить день собеседования и рассказываете её о своём новом подходе, чтобы дать ей возможность подготовиться.
Наконец, наступает день интервью и ваш кандидат появляется в школе. Вы замечаете, что она немного нервничает, что странно, потому что она опытный кандидат и её резюме безупречно. Вы решаете не думать об этом и проводите её в один из ваших классов, чтобы начать собеседование. “Мне бы хотелось, чтобы вы преподали мне урок по теории чисел”. В этот момент её лицо помрачнело. Дело в том, что она не преподавала в 8-м классе вот уже более чем 10 лет. Но вы об этом не были осведомлены. Как профессионал, она пошла к доске и начала урок. Она рассказывает о множителях чисел и о том, как определить делится ли число на 2, 5 и 10. Но видно, как ей трудно. Вы просите её рассказать о GСF и LCM, но она просит уточнить, что означают эти аббревиатуры. Вы расцениваете это как дурной знак и объясняете, что имели в виду “наибольший общий делитель” и “наименьшее общее кратное”. В этот момент вы замечаете, что её уверенность в себе поколебалась и чувствуете раздражение в её голосе.
К концу часа, с горем пополам, она прошлась по всем основным моментам теории чисел. Однако это не вселило в вас уверенность, что она сможет провести этот урок перед группой непослушных 8-ми классников. Она успешно прошла ещё пару тестов, но вы никак не можете отделаться от чувства, что она, возможно, не самый лучший классный учитель. После ещё нескольких интервью, вы решаете не останавливать свой выбор на ней и нанимаете учителя с гораздо меньшим опытом, который прошёл “тест уроком”.
. . .
Возможно, этот пример вам покажется слишком надуманным. Довольно странный способ отобрать соискателя на должность учителя, не так ли? Однако он точно отражает метод интервьюирования инженеров ПО. Тем не менее, я здесь не для того, чтобы спорить, что тестовые задания по кодированию совершенно не работают (хотя многие так считают). Я убеждён, что таким заданиям не место в интервью на должность уровня Senior.
Почему? Очень просто! Сеньор разработчики очень разные и типовые задания по кодированию ставит их в невыгодное положение по ряду причин:
Они отнимают кучу времени на подготовку - поскольку тестовый кодинг опирается на всю область разработки программного обеспечения, к нему невероятно трудно подготовиться исчерпывающе. Для сеньор-девелопера эта проблема ещё и усиливается. Во-первых, по определению, время школьного обучения уже далеко позади, где они возможно и сталкивались с более эзотерическими аспектами разработки ПО (динамическое программирование, красно-чёрные деревья или, даже, рекурсия). Чтобы освежить знания по такому огромному диапазону алгоритмов и структур данных, может потребоваться значительное время. Вдобавок, сеньор инженеры более сжаты по времени (у них более жёсткие проектные рамки и значительная личная ответственность) и это настоящая проблема. Я знаю несколько случаев, когда сеньор-инженеры интересовались прохождением интервью у заказчика и, если он предлагал кодинговое тестирование, то отказывались его проходить.
Они заставляют сеньор-инженеров работать в непривычной среде - сеньор-инженеры давно уже не пользуются средствами разработки предлагаемыми на интервью. Обычно они пользуются тонко настроенными средами разработки, которые совершенствовались многие годы и заточены на то, чтобы избавить от лишней писанины низкоуровневого кода. Если учесть, что интервью накладывает временные ограничения на выполнение теста, то извлечение из привычной среды разработки ставит сеньор-инженера в невыгодное положение. Более того, последние несколько лет они могли работать с собственными библиотеками (управление памятью, контроль ошибок, трэйсинг) своего заказчика. Кодинговое интервью выдёргивает их из зоны комфорта в мир стандартов и примитивных редакторов.
На самом деле они не проверяют навыки, которые сеньор-инженеры будут применять - вероятно самое дебильное то, что такие интервью проверяют только малую часть того, ради чего вы нанимаете сеньора. Он обычно зарабатывают в 3-5 раз больше, чем джун. Ожидать при этом, что сеньор будет писать в 3-5 раз больше кода, как минимум неразумно. Им просто не хватит на это времени. Основное, для чего нужен сеньор, это чтобы вести команды джунов, обучать их, выявлять систематические проблемы, отлаживать сложные процессы в разработке и, когда дело доходит до кодинга, разобраться в сложной системе и запутанной работе, чтобы кодить вместе с ними. Ни один из этих аспектов не тестируется кодинговыми интервью и это главное, почему сеньор-инженеры ненавидят тестовые задания.
Они становятся недобрым предзнаменованием - как вы уже знаете, сеньор-инженера нанимают не для того, чтобы кодить, и они это тоже знают. Но когда вы делаете акцент на кодинговых тестах в процессе найма, вы заставляете сеньора сомневаться в той роли, для которой вы его нанимаете. “Они просто хотят, чтобы я стал код-макакой”, “Не растрачу ли я свой талант здесь?”, “Это шаг вперёд или шаг назад?”. Наверное вы не очень хотите, чтобы какой нибудь талантливый инженер засомневался в вакансии или в вашей компании во время интервью. Попросите их покодировать на интервью - засомневаются.
Поразмыслив над всем сказанным не удивляешься, почему это сеньор-инженеры ненавидят кодинговые интервью. Если вы хотите действительно привлечь талантливых сеньоров на этом напряжённом рынке труда, то перестаньте просить их что-то покодить.
Однако, вы возможно подумали, а как я узнаю сможет ли он вообще кодить? Ну, если вы уж так хотите убедиться, что нанимаемый сеньор сможет кодить, могу предложить дать небольшое задание на дом (чтобы оно занимало не более одного-двух часов). Большинство сеньоров вполне могут найти немного времени, чтобы выполнить такое задание, тем более, что это устраняет подготовительную работу, необходимую для тестового кодинга и может быть разбито на короткие отрезки времени, которые легче спланировать в напряжённом графике. Такое задание на дом также позволяет работать в привычной среде разработки и потратить любое доступное время, чтобы изучить или освежить знания по какой нибудь стандартной библиотеке.
Дополнительное преимущество это то, что соискатель может посвятить столько времени, сколько он захочет, чтобы выполнить ваше задание и это даст вам представление о его персональных особенностях работы. Внимательны ли они к комментариям? Насколько тщательно продумывают тесты? Насколько хорошо структурируют свой код? В какой степени заботятся о качестве работы, которую отправляют? Иными словами, вы будете знать не только то, что они умеют кодить, а ещё и насколько хорошо они умеют кодить в более или менее реалистичной обстановке.
…
Сеньор-инженеры - это “живая кровь” любой софтовой компании. Они самые желанные, самые дорогие и трудные в отборе. И особенно в исторически сложившемся, тесном рынке труда, ваш процесс найма должен быть более гибким к их специфическим нуждам, так как вы нуждаетесь в них больше, чем они в вас.
Да, сеньор-инженеры ненавидят кодинговые интервью и вы в процессе поиска лучшего способа отбора, тоже должны их ненавидеть.