Про технические (frontend) собеседования

Не популярное мнение того, кто побывал с обеих сторон в больших количествах.

Технические собеседования на позицию фронтенд разработчика, что с ними не так и как это исправить. Обычно, тех. интервью состоит из двух этапов: теория и “лайф-кодинг”. Давайте по порядку:

Теория

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

Самое худшее что вы можете сделать, это просто сухо пройтись по вопросам, начиная от того что такое замыкание и прототипное наследование, до каких-то специфических кейсов библиотеки которую вы используете (например, React). Если для начинающих такая схема ещё терпима, то для разработчиков с опытом 10+ лет это просто плевок в лицо. Например, от просьб рассказать в каком порядке выполнятся console.log в коде с тайм-аутами и промисами разного вида, хочется сказать “удачи в поисках” и прекратить пустую трату времени.

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

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

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

Лайф-кодинг

Как по мне, этот этап ни каким образом не даст вам представление о том как именно кандидат думает и пишет код. Никто и никогда не пишет код в браузере в незнакомом редакторе без автодополнений, без интернета, да ещё и когда на него смотрят “следователи” и ждут что он это всё как-то будет комментировать. Даже очень опытные, в такой ситуации, могут забыть про элементарные вещи и выглядеть глупо.

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

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

Если у кандидата есть GitHub, посмотрите код там.

За сим, хороших вам собеседований и отличных вакансий.

Больше информации в Telegram канале https://t.me/around_dev