Как проводить собеседования разработчиков

Однажды я понял, что дико не комфортно с ним работать, но поскольку я только прошел испытательный срок, а он уже работал пару лет, то пришлось валить.

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

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

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

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

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

Кейс из жизни

На заре своей карьеры мне посчастливилось провести одно из своих первых собеседований на первой работе. К нам в компанию пришел очень странный кандидат на позицию junior frontend developer. Ни на один из вопросов по javascript’у он не ответил. С html и css тоже были дичайшие проблемы. На вопрос, а зачем он вообще хочет стать разработчиком, последовал очень неожиданный ответ. Его знакомый на тот момент устроился в западную компанию за неплохие деньги и рассказывал ему как же хорошо работается почти ничего не делая. И наш кандидат решил что тоже так может. После открытого заявления о том, что он хочет сидеть и ничего не делать и за это получать деньги, мы были вынуждены указать ему на дверь.

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

Junior

Тут максимум можем услышать о каких-то пет проджектах, либо о каких-то учебных проектах.

Middle

Истории про базовые задачи (сверстать компонент, прикрутить api) — это то, что мы услышим от мидла.

Senior

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

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

Кейс из жизни

Однажды собеседовал кандидата на позицию senior frontend developer в одну всем известную в России компанию. За неделю до этого я столкнулся с проблемой интеграции typescript’а в проект. На собеседовании кандидат подкинул пару идей как можно ее решить. Не помню уже помогло это или нет, но факт в том, что у него было решение на мою проблему.

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

Кейс из жизни

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

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

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

Почему я ставлю технические навыки в самый конец? Потому что в первую очередь вы будете работать и общаться с человеком, а не с его кодом. Будете каждый день созваниваться на синках, разу в пару недель ретриться и планироваться. И тут важно что бы в команде царила максимально комфортная обстановка. А технические навыки быстро приобретаются, особенно если проект и задачи интересные.