Представьте, что вы директор небольшой средней школы, который хочет нанять нового учителя. Так как работает у вас их не очень много, то нужно убедиться в способности каждого преподавателя вести любую дисциплину. Дополнительная сложность в том, что недавно вы лишились одного из лучших учителей, имевшего 15 лет стажа, и являвшегося наставником для молодых специалистов. Как его заменить?
После некоторых раздумий у вас созревает идея креативного собеседования. Вы будете просить кандидатов провести урок из учебной программы школы. А так как вам нужно убедиться в том, что кругозор его достаточно обширен, о теме урока вы заранее не сообщаете. Если кандидат пройдет такое испытание в стесненных условиях и без подготовки, то можно сделать вывод, что он без проблем сможет обучать детей различным дисциплинам.
Далее вы размещаете объявление о найме, на которое откликается несколько серьезных кандидатов. Однако изначально вы решаете опробовать свой подход на проверенном человеке, которого один из ваших сотрудников рекомендует как некогда “Звезду школы”, в которой они вместе работали. Радуясь уже тому, что он просто согласился, вы видите в этом отличный шанс протестировать свою систему отбора. Созвонившись, вы обговариваете дату собеседования и сообщаете ему о придуманной вами технике, чтобы он имел возможность хоть как-то подготовиться.
Наступает назначенный день, и кандидат приходит в школу. Вы чувствуете, что он несколько взволнован, что довольно странно, ведь за плечами этого человека обширный опыт и безупречное резюме. Вы решаете не заострять на этом внимания и просто ведете его в кабинет для собеседования. “Хочу, чтобы вы провели урок по теме теории чисел” — говорите вы. В этот момент выражение его лица тускнеет, так как курс 8 класса он не преподавал уже лет 10. Тем не менее, сохраняя профессионализм, он идет к доске и начинает урок. В процессе урока речь идет об умножении, а также о том, как определить, делится ли некое число на 2, 5 и 10. Но дается ему все это нелегко. Когда вы спрашиваете о НОД и НОК, то он просит пояснить эти сокращения, что для вас является плохим показателем. Вы отвечаете, что имеете в виду наибольший общий множитель и наименьшее общее кратное, но в этот момент становится очевидно, что его уверенность подорвана, и в голосе возникает доля раздражения.
К завершению учебного часа он раскрыл вам основные моменты теории чисел, но никак не убедил, что сможет достойно провести урок для группы непоседливых восьмиклассников. Он отлично показывает себя в ряде других поведенческих тем собеседования, но вас не покидает ощущение, что это не ваш “лучший учитель”. После тщательного обдумывания вы принимаете решение отказать этому кандидату и нанять намного менее опытного, но более успешно прошедшего тест с уроком.
Это, конечно, может показаться слишком надуманным примером и странным способом оценки кандидата в учителя, но именно такой метод используется при отборе инженеров ПО. Я хоть и не писал статью с целью доказать несостоятельность подобных собеседований (это сделали другие), но сильно убежден в том, что они не уместны для проверки опытных разработчиков.
Почему? Говоря просто, ведущие инженеры — они другие, и типичное собеседование по написанию кода ставит их в неудобное положение по ряду причин:
- Оно требует уйму времени на подготовку. Поскольку собеседования по написанию кода происходят из огромной индустрии разработки ПО, к ним очень тяжело подготовиться всесторонне. Эта проблема усиливается для старших инженеров в двух смыслах. Во-первых, времена обучения остались давно позади, в связи с чем некоторые малораспространенные аспекты программирования оказались в закромах памяти, например динамическое программирование, красно-черные деревья или даже рекурсия. Чтобы освежить память по обширному спектру алгоритмов и структур данных, понадобится время. Прибавьте к этому тот факт, что старшие инженеры, как правило, итак, во времени ограничены. Я знаю несколько случаев, в которых ведущие инженеры интересовались о процессе приема на работу, и когда в ответ им говорили, что будут проверять их навыки написания кода, они просто отказывались.
- Это вынуждает инженера менять стиль работы. Ведущие программисты уже далеки от голых сред разработки, которые используются на собеседованиях, так как привыкли работать в тщательно настроенных и оформленных. Лишение их этого в ситуации, в которой дополнительно накладываются искусственные временные ограничения, однозначно ставит специалистов в невыгодное положение. Более того, может быть так, что в последние несколько лет разработчик провел за проприетарными библиотеками (управление памятью, проверка ошибок, трассировка кода) последнего работодателя. В таком случае собеседование резко вырвет его из зоны комфорта, поместив обратно в мир стандартных библиотек и простых текстовых редакторов.
- На деле проверяется не то, чем разработчик займется после найма. Вероятно, наиболее злостный аспект собеседований по программированию состоит в том, что на них тестируют только малую толику потенциальных обязанностей соискателя. Ведущие инженеры обычно зарабатывают в 3–5 раз больше новичков. Но ожидать при этом, что они будут писать в 3–5 раз больше кода, чем выпускники, очевидно не разумно — так как у них элементарно не хватит на это времени. Вместо этого такие специалисты нанимаются, чтобы вести команды молодых инженеров, быть их наставниками, выявлять системные проблемы, отлаживать наиболее сложные сбои, а также, что касается написания кода, понимать сложные системы и запутанность процесса работы внутри них. Ни один из этих аспектов не проверяется, и это одна из основных причин, почему старшие инженеры ненавидят подобные собеседования.
- Они дают плохой знак. Вы знаете, что нанимаете ведущего разработчика не для написания кода, и он тоже это понимает. Но когда вы вносите в процесс найма этап с написанием кода, то кандидат может начать додумывать ту роль, для которой вы его нанимаете, например “Они что, действительно хотят сделать из меня наборщика кода?” или “Неужели я утрачу здесь все свои навыки и способности?” или “Это вообще шаг вперед или назад?”. Последнее, что вам нужно, это возникновение в ходе такого собеседования сомнений у талантливого инженера в его роли или в вашей компании. А этот этап наводит именно на такие сомнения.
Можно подытожить все перечисленные факторы и уже не удивляться, что ведущие инженеры ненавидят подобные схемы приема на работу. Если вы стремитесь привлечь лучших разработчиков и снизить коэффициент трения в процессе собеседования в условиях столь конкурентного рынка труда, то предлагаю перестать расспрашивать опытных соискателей о том, как писать код.
На встречный вопрос “Как же убедиться в том, что они умеют писать код?” отвечу так. Если вас действительно сильно волнует риск нанять ведущего инженера, не имеющего представления о коде, то можете предоставить ему очень краткое домашнее задание, на выполнение которого потребуется не более часа. Большинство инженеров должны найти для этого достаточно времени, особенно с условием того, что это избавит от необходимости подготавливаться к собеседованию, а также позволит разбить задачу на удобные временные промежутки. Задание на дом также позволит заняться им в привычной IDE (если они сделают такой выбор) и затратить необходимое время на освежение в памяти знаний о стандартных библиотеках.
Дополнительным преимуществом будет тот факт, что кандидат сможет сам решить, сколько времени ему уделить на подготовку. Это позволит понять, чему он действительно уделяет внимание. Задумывается ли он над комментариями? Насколько тщательно он подходит к тестированию? Структурировал ли он код разумным и понятным образом? Позаботился ли о качестве проделанной им работы в целом? Говоря иначе, вы поймете не только, насколько хорошо этот специалист пишет код, но также насколько старательно и грамотно он это делает, причем в более реалистичном формате тестирования.
Ведущие инженеры являются ключевыми сотрудниками любой компании по разработке ПО. Это самый желанный, дорогостоящий и сложный для привлечения ресурс. Тем более, что в жестких условиях современного рынка труда ваш процесс найма должен быть ориентирован на конкретные нужды инженеров, так как они вам нужны намного больше, чем вы им.
Ведущие инженеры ненавидят собеседования с этапом написания кода, и если вы хотите найти лучших, то и сами должны их избегать
Читайте также:
- Худшие способы нанять хороших программистов
- Какие вопросы задавать HR-менеджеру во время собеседования
- Лучшие приёмы HR от Google
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Adam Storm: Why Senior Engineers Hate Coding Interviews
