Недавно мне доверили проводить собеседования с кандидатами в нашу команду инженеров. Меня назначили интервьюером 1-го и 2-го раундов, а это означало, что я должен был оценить, способен ли наш кандидат выполнить «достаточно хорошую работу». У меня был другой интервьюер, который спросил меня, как я буду проводить собеседования с этими кандидатами, поэтому, естественно, мне пришлось написать об этом статью на Medium.

Почему я имею право высказывать свою точку зрения?

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

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

Получите правильное мышление

Позвольте мне перейти к делу: вы хотите создать такую ​​среду, в которой кандидат может проявить себя наилучшим образом.

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

Что Вы ищете?

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

Под «вещами, которые вы хотите» я не имею в виду такие вещи, как «Есть ли у них опыт или они знают фреймворк xyz и SAFe», потому что, откровенно говоря, они переоценены. Знания и опыт часто неправильно используются в качестве основного показателя ценности и часто пользуются таким большим уважением (и часто используются для дисквалификации в остальном хорошего кандидата) прежде всего потому, что эти — гм — показатели поддаются количественному измерению и оправдываются их менеджерами. За исключением того, что навыки, которыми мы обладаем как SWE, очень редко поддаются количественной оценке. Я имею в виду, как точно определить влияние на бизнес, которое кандидат оказал, применив свои навыки? Делает ли NodeJS автоматически квалификацию Райана Даля в качестве технического директора Microsoft? Воздействие редко оказывает один человек, несмотря на то, что могут предложить лайф-коучи и обзор производительности.

Но это не значит, что эти вещи не имеют значения: они имеют значение, но это не главное, что вы должны искать в кандидате. Это всего лишь «сигналы».

Сигналы.

Сигналы?

Возьмем приведенный выше пример «опыта» и «знаний»: написание среды выполнения JS, которая используется во всем мире, означает, что разработчик может создавать программное обеспечение, которое нравится другим разработчикам. Однако это не означает, что Райан Даль автоматически должен стать вашим следующим ведущим SWE.

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

  • Вам нужен гений, который может разработать приятный UX для ваших клиентов? Сигналы:
  • Уделяет внимание UX
  • Может сотрудничать, чтобы использовать язык дизайна, знает, что делать
  • Поднятые ARIA-ярлыки — сигнализируют о том, что человек знает, что делать с доступностью

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

Использование количественных показателей вместо «сигналов»

Возьмем пример из реальной жизни: человек, которого мы наняли для нашего производственного бизнеса, имел 10-летний опыт работы в крупных национальных компаниях и отвечал всем требованиям, которые мы искали (например, он знал, как составлять СОП и как работать с реестрами). Тем не менее, он был одним из самых плохих кандидатов, которых мы наняли до сих пор.

Не отсутствие у них опыта, навыков или знаний сделало его плохой кандидатурой; это была его — гм — склонность «подлизываться к своему начальнику» и игнорировать все остальное. Справедливости ради: подлизываться к людям — это нормально, но они должны (1) приносить пользу; и (2) сделать бизнес своим главным приоритетом, а не привязанностью к ним своего босса. Интересно, что нам удалось обнаружить эту их черту во время одного из наших первых раундов. Его наняли через рекрутинговую организацию, и, как сообщалось, у него была низкая собственная инициатива и склонность следовать статус-кво.

Так почему же у нас в голове не щелкнуло, что, наверное, не стоит брать его в нашу команду?

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

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

Разработка «тестов» для раскопок сигналов

Хорошо, значит, у вас есть сигналы. Так как же их копать?

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

Сигналы не всегда появляются и видны интервьюеру; вы должны убедиться, что окружающая среда идеальна для их появления.

Возьмем, к примеру, техническое собеседование: если вы проверяете собеседника, задавая ему банальные вопросы, такие как «Как вы складываете стопку карт вместе?» и оценивая их ответ на основе его правильности, вы в первую очередь получите сигналы о том, что кандидат либо хорошо, либо плохо решает простые вопросы; технически в эту категорию попадает шахматист, который никогда не занимался программированием.

Когда вы разрабатываете тесты, вы должны помнить о том, что эти тесты могут дать кандидату возможность представить вам свои прекрасные сигналы (или их отсутствие). Вы действительно хотите пропустить звездного кандидата, который не смог рассказать вам, как работает виртуальный рендеринг React? Вас действительно волнуют математические способности кандидата?

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

Чтобы привести вам пример, сложные задачи LeetCode (такие как создание сбалансированной кучи для слияния отсортированных списков) ужасно мешают мне получать точные сигналы. Во-первых, на их выполнение уходит вечность, потому что они, как правило, «сложны», а это означает, что у вас остается меньше времени, чтобы на самом деле разобраться в том, подходит ли кандидат для этой роли. Кроме того, из-за того, что проблемы настолько нишевые, кандидаты в конечном итоге делятся на 2 категории: (1) кандидаты, которые слышали об этой проблеме раньше и знают общее решение; или (2) кандидаты, которые застряли, потому что они никогда раньше не сталкивались с такими проблемами.

Я считаю, что проблемы, которые вы решали в прошлом на своей работе, обычно являются довольно хорошими тестами для выявления технических сигналов. Во-первых, поскольку вы уже решили ее, вы знаете, как можно прийти к решению и как давать дополнительные подсказки, если кандидат застрял. Поскольку вы знаете, как прийти к проблеме, вы также знаете, какие из ваших собственных «сигналов» вы подали для ее решения; возможно, проблема требовала от вас небольшого уточнения требований, чтобы решить ее, или, может быть, вы вытащили свою алго-волшебную палочку и применили алгоритмическую магию, чтобы решить проблему за время O(1).

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

Образец технического теста

Мой «технический тест» для определения того, подходит кандидат или нет, заключается в том, чтобы просто давать ему задачи, которые мне приходилось решать на моей повседневной работе. Это позволяет мне откалибровать их общий подход и прогрессировать с моим опытом.

Тем не менее, очень важная вещь, которую я всегда делаю, это то, что я четко даю понять своим кандидатам, что я не даю летучей рыбы правильность их решения (за исключением, конечно, тех случаев, когда они полностью ошибаются в том, что они думают). решение — но это редкость).

Вот сигналы, которые я обычно ищу при найме разработчиков программного обеспечения, в порядке приоритета:

  1. Это не мудак — вы удивитесь, узнав, сколько людей проваливают этот сигнальный тест. Серьезно, меня не волнует, являетесь ли вы рок-программистом; быть мудаком замедляет всех. Не говорите, что «я знаю лучше» — это слишком высокомерно для людей, включая меня.
  2. Может придумать примерный план решения — мои задачи на собеседовании просты и представляют собой повседневные проблемы, с которыми мы сталкиваемся на работе, например, поиск уникальных элементов в массиве. Они должны быть легкими, потому что что-то более сложное займет слишком много времени и заставит кандидата молчать слишком долго. Если они не смогут выполнить этот минимум, то команда, вероятно, потратит слишком много времени на их наставничество.
  3. Может хорошо общаться — это спектр, который я хотел бы видеть, где вы находитесь. Я не ожидаю, что инженеры смогут поддерживать разговор на совещаниях высшего уровня, но они должны, по крайней мере, иметь возможность общаться и обсуждать со мной свои идеи. Самое главное, я понимаю, что дисбаланс сил зависит от меня, поэтому я очень стараюсь успокоить кандидата и сделать первый шаг, чтобы поощрить дискуссию.
  4. Опыт работы с лучшими практиками — обычно я обращаю внимание на то, хорошо ли кандидат разбирается в лучших практиках (например, объявление vars в JS перед их использованием — вздрагивает). Это может быть обоюдоострый меч, но обычно это то, что я могу «понюхать», увидев их код. Я не вижу проблемы в «сознательном неуважении к правилам», но неспособность объяснить, почему вы отклонились от протоптанной тропы, сигнализирует мне о том, что вы, вероятно, не знаете, что была протоптанная тропа в первое место.

Итак, как бы я разработал тест вокруг него? Если вы помните из предыдущего раздела: мне нравятся тесты, отражающие реальные проблемы. Итак, я просто извлекаю свою историю коммитов за последний месяц.

исправлено: предотвращение многократного дублирования выборки и возникновения условий гонки в обработчике useConfig

Когда я просматривал различия кода, я видел вещи, которые я реализовал примерно за 30 минут (исключая WTF и ожидание компиляции моего кода): использование мьютексов для предотвращения множественных отправок.

Опять же, я не пытаюсь заставить вас решать сверхсложные задачи, и меня абсолютно не волнуют мелкие детали реализации (включая типы мьютексов, которые вы используете): проблемы, которые я выбираю, - это то, что люди часто делают. на роль, на которую я нанимаюсь. Что еще более важно, у проблемы есть несколько решений: вы можете использовать мьютексы, вы можете использовать состояния, вы можете использовать ответный запрос или SWR и т. д.

Борьба с предвзятостью

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

Предвзятость хороша, потому что это ярлыки, которые помогают нам очень быстро принимать решения. Предвзятость также может быть плохой, потому что эти ярлыки могут увести нас по ложному пути. Я считаю, что изучение результатов вашего интервью очень полезно для борьбы с предвзятостью. Например, почему вы считаете, что ваш кандидат очень хорошо справился с вами на собеседовании? Вы чувствовали, что они ясно представили свои идеи? Как вы думаете, почему кандидат четко представил свои идеи? Это их акцент или то, как они решили проблему?

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

Чтобы бороться со своей предвзятостью, я обнаружил, что если оставить свои мысли в покое, это помогает предотвратить любые чрезмерно эмоциональные чувства, которые у меня могут быть (сон прекрасно помогает мне в этом). После того, как у меня было время «остыть», я выясняю, почему у меня было «хорошее предчувствие» по поводу этого кандидата, и пытался найти дыры в своих собственных доводах. Например, хорошо ли кандидат умеет общаться, потому что он может хорошо излагать свои идеи, или это потому, что он похвалил мой выбор наушников в начале собеседования?

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

Заключительные слова: не прячьтесь за количественными показателями

Слушайте, я понимаю: сводить все к количественным показателям — это хорошо и позволяет вам сказать: «Но, судя по цифрам, этот кандидат — рок-звезда!» Это снижает давление на ваше «суждение» и заставляет вещи выглядеть так, как будто они подтверждены эмпирически.

Но вот в чем дело: инженеры-программисты — это не синие воротнички. В нашей повседневной жизни происходит так много всего, что не поддается точному количественному измерению. Инженер может хреново выбрасывать задачи за дверь, но он может отлично объединять заинтересованные стороны. Или они могут быть на 20 % медленнее, чем ваш средний инженер, но создавать код на 20 % быстрее (в просторечии именно поэтому стори-поинты следует использовать не для измерения производительности, а для помощи в планировании и информировании об усилиях).

Кроме того, по моему опыту, баллы и показатели часто не могут сказать мне ничего значимого о кандидате. Например, как я должен узнать, подходит ли этот кандидат, исходя из оценки интервьюируемого 7/10 в балансировке кучи? Люди думают, что оценки объективны, но на самом деле они субъективны, потому что в 99 % случаев интервьюеры пытаются втиснуть свою качественную оценку в число, поддающееся количественному измерению.

В конце концов, я чувствую, что единственный показатель, который имеет значение, это: «Могу ли я представить этого кандидата как ценного члена команды?» Конечно: это субъективно и может привести к предвзятости, но, в конце концов, это все, что действительно имеет значение. Все, что вы делаете, служит этой цели; сигналы, которые вы ищете, должны привести к ответу на этот вопрос.

В конце концов, вам нужен кандидат, который может сбалансировать кучу, или кандидат, который может помочь вашей команде добиться успеха?