Как я оказался по другую сторону технических собеседований

Всем привет! Меня зовут Денис, я senior frontend-разработчик в компании “Исходный код”.

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

Вкратце расскажу предысторию. Наша компания открыла две вакансии в команду веб-разработки. Мы искали middle и senior.

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

С чего все началось

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

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

Очень быстро стало понятно, что я сильно недооценил объем работы. Само собеседование - это только вершина айсберга. До него нужно отсмотреть десятки резюме, обсудить кандидатов, подготовить вопросы и уникальные практические задачи (вместо банального копирования с литкода), а после, принять решение, которое далеко не всегда простое и очевидное.

Просмотр резюме

Первым этапом для нас стал просмотр резюме. Это было первое серьезное испытание.

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

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

В какой-то момент стало понятно, что искать универсальный шаблон бессмысленно. Поэтому мы скорее выработали для себя несколько ориентиров. Смотрели, насколько опыт человека пересекается с нашим стеком, какие задачи он решал, есть ли в описании проектов что-то конкретное, что позволяет понять его вклад. Больше интереса вызывали описания с понятными результатами или интересными техническими решениями, чем общие формулировки, которые можно встретить практически в любом резюме.

Но даже с такими ориентирами принимать решение было непросто.

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

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

Собираем интервью с нуля

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

Мы начали с самого простого - составили список тем, которые хотели обсудить. Это мы сделали за 10 минут, посмотрев описание вакансии, но после этого сразу возникло множество вопросов.

А какие темы действительно важны? Что спрашивать у middle, а что только у senior? Стоит ли делать упор на практику и задачи или на теорию? Нужно ли вообще спрашивать то, с чем человек в реальной работе почти никогда не сталкивается?

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

Дальше предстояло отфильтровать их и понять, какие вообще стоит оставить. Изначально хотелось сделать интервью максимально приближенным к реальной разработке: меньше теории, больше практики и обсуждения реальных задач. Но довольно быстро стало понятно, что только по вопросам почти невозможно понять, как кандидат применяет эти знания на практике. А если пытаться глубоко поговорить о теории, то есть риск просто задушить человека деталями.

Поэтому мы поступили так. В теоретическую часть мы заложили только вопросы, которые проверяют базовое понимания фронта - как работает браузер, асинхронность, типизация, знание верстки и css и т.д. Естественно, какие-то вопросы в глубину остались, но мы старались давать давать только 1-2 таких вопроса и только в рамках какой-то одной из базовых тем. Забегая немного вперед, после нескольких тренировочных собеседований на коллегах, мы поняли, что, фактически, на теорию у нас есть только 30-35 минут. И тут мы либо все это время пытаемся выяснить тонкости работы какого-нибудь garbage collector, либо успеваем рассмотреть несколько разных тем и прикинуть, насколько человек вообще ориентируется в технологиях, с которыми работает каждый день. Мы выбрали второе.

С практической частью нам повезло немного больше. Мы довольно быстро сошлись во мнении, что не хотим давать алгоритмические задачи. Все-таки в повседневной фронтенд-разработке алгоритмические задачи практически не встречаются.

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

Такой подход требует гораздо больше подготовки, но зато проверяет именно рабочие навыки. Собственно, мы постарались максимально приблизиться к этой идее. Завели небольшой React-компонент, в который специально заложили несколько багов. Баги мы не выдумывали, а взяли из нашего собственного опыта, что-то, что мы сами когда-то находили и исправляли на работе.

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

Первые собеседования

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

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

Второй проблемой оказался тайминг. С первыми кандидатам мы могли пропускать целые секции, просто потому что не укладывались. Очень легко уйти с ними в рассуждения, и забыть о том, что еще нужно спросить у него typescript, то, как он работал со стейт-менеджерами, и т.д. Тут нам помогло то, что мы разбили интервью на секции по приоритетам. Все наиболее важные (JS, React, CSS) поставили вперед, а те что не жалко было пропустить поставили после практических задач. К каждому вопросу мы также тезисно набросали то, что ожидаем в ответе и если понимали, что кандидат разговорился - останавливали его. 

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

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

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

В какой-то момент я настолько сосредоточился на процессе, что сам перепутал Virtual DOM с Shadow DOM. Так я узнал, что нервничать и теряться на собеседовании могут не только кандидаты.

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

Что в итоге?

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

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

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

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

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