2019-09-30
Опять про хайринг. Whiteboarding
Я тут недавно решил, что пора бы встряхнуться, и походил по собеседованиям. Цели, как всегда, стандартные:
- узнать что нынче спрашивают, и что хотят
- освежит навыки прохождения собеседований
- подсмотреть на лучшие/худшие практики
Две компании очень понравились своими процессами, про них и расскажу.
Что Microsoft, что Facebook начинались с отлично отлаженной работы рекрутеров. На каждом этапе мне четко и подробно объясняли, что ожидать, какие требования, что будет. Предупреждали не просто на уровне "мы там попрограммируем, проверим, как ты умеешь в алгоритмы", а рассказывали что, как и зачем будут спрашивать. Обе компании прислали уйму материалов для подготовки. Это были и видео-лекции, и статьи, и книги. Были и примеры различных задач, которые будут спрашивать. По каждому из этапов интервью (алгоритмы, архитектура и менеджмент/работа в команде) были четко описаны критерии оценки. В итоге каждый раунд был просто сложным, но без неожиданностей. Что очевидным образом снизило фактор стресса. Да, я уставал, но не тупил просто из-за дискомфорта и паники.
Раньше я считал, что написание кода на доске или в редакторе это такая своеобразная дедовщина из мира IT. Ну не пишет же программист код на бумажке, да и не часто приходится "деревья вертеть" на работе. Оказалось, что дело было лишь в плохих интервьюерах. Ведь если не понимать, что и зачем ты делаешь, то даже скопировав процессы с гугла, ты получишь бессмысленное говно.
А оказалось всё просто, задачи на технический раунд должны быть:
- Сложные
- Решаться несколькими способами
- Не иметь только одного неочевидного решения в стиле "олимпиадная поебень"
- Не оцениваться бинарно (решил/не решил)
Если собрать все эти пункты вместе, и научить интервьюеров вытаскивать из этого процесса нужные сигналы, то получится приличное интервью и просто приятный процесс.
Почему задача должна быть сложной? Ну хотя бы потому, что это больше похоже на обычную работу. Есть проблема, не ясно как её решить. Для этого нужно обсудить её с кем-то, провести брейншторм. Тут интервьюер одновременно выступает в качестве коллеги, заказчика и пользователя. Решение должно состоять из нескольких этапов (часть из которых можно вынести за скобки и пропустить). Такой процесс хоть как-то эмулирует работу в команде, даёт интервьюеру возможность не только оценить навык написания кода, но и показывает каково это работать с кандидатом. Как он реагирует на трудности? Как он слушает? Может ли он признавать ошибки? Быстро ли схватывает идеи и понимает ли подсказки?
Задача должна решаться несколькими способами, ведь люди и думают чуть по-разному. А если способ только один, то трудно сказать, какой вывод можно сделать из того, что кандидат задачу не решил.
Пункт третий, про неочевидность решения, схож с предыдущим тезисом. Если решение требует знания какого-то хитрого факта, то такая задача не лучше типичного квиза в стиле российских компаний из 2010 года. Тогда было модно спрашивать какой-нибудь бестолковый факт, который интервьюер случайно прочитал на Хабре. Обычно на вопрос "зачем это спрашивать?" такой интервьюер отвечает что-то типа "ну это должен знать каждый программист". Кстати, если ты проводишь интервью и ты не можешь обосновать осмысленность своих вопросов как-то иначе, то мне очень жаль, но ты спрашиваешь хуйню.
Ну и оценка по "решил/не решил" тоже мало что говорит о кандидате.
Если понимать, зачем нужны такие этапы, и что ты пытаешься узнать, задавая тот или иной вопрос, то становится проще жить. Ведь тогда не нужно бояться что кандидат "засветит" твой любимый вопрос или задачку. Да и не придётся бегать за кандидатами и просить их удалить тестовое задание с гитхаба.
Потому, что фильтр основанный на знании факта — это плохой фильтр. А хороший фильтр секретности не требует.