Мой подход к техническим собеседованиям

/ ~8 мин.

Как я придумал нанимать отличных ребят без вращений деревьев, регистрации и СМС

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

До этого я полтора года обрабатывал входящий поток кандидатов в elonsoft, где чаще всего встречались либо совсем зелёные стажеры, либо джуны. Специфика таких собеседований была в том, что тебе нужно скорее смотреть не на текущие знания человека (хотя какая-никакая база всё равно должна присутствовать), а на то, что он делает, чтобы этот самый набор знаний увеличить. Проще говоря, я старался набрать проактивных людей, которые быстро могут набрать нужную для работы форму.

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

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

На простейшие вопросы о результатах собеса по кандидатам, которые проходили через базовый порог, потом не мог ответить уже я ¯\_(ツ)_/¯ Нейросетка за полтора года собеседований стажёров и джунов научилась только выдавать ответы уровня “ок/не ок”, но не понимать, есть ли у человека хоть какой-то значимый бэкграунд за плечами, и сможет ли он привнести ценность в продукт. Потом я, конечно, понял, что мои вопросы никуда не годятся, и начал придумывать, как это изменить. И вроде даже что-то придумал, т.к. список вопросов к следующей серии собеседований стал сильно лучше, но не дотягивал до идеала.

Цель собеседований link

Повзрослев и получив в свои руки ответственность за выбор (ведь именно с этими людьми мне дальше делить таски в жире!), я понял, что перед тем, как проводить собеседования, нужно понять, для чего я вообще занимаю своё и чужое время. Для себя я сформулировал цель так – техническое собеседование нужно, чтобы понять о человеке следующее:

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

В поисках хорошей модели link

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

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

Вообще, есть отличная статья от iOS-техлида Delivery Club, который рассказывал своё видение процесса технического собеседования. Мне статья очень понравилась, но прочитал я её уже после того, как закончил собеседовать.

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

Подготовка к собеседованию link

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

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

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

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

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

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

После этого дисклеймера мы переходим к самому разговору. Я включаю презентацию, где перечислено 10-15 базовых вопросов о Ruby, RoR, базах данных и Software Engineering в целом. Опытный человек способен пройти этот фильтр менее чем за 5 минут. Вопросы специально подобраны так, чтобы по ним можно было дать четкий ответ и двигаться дальше. Всё это нужно, чтобы отсеять совсем слабых кандидатов и не тратить на них время (и несколько раз это отлично помогло!).

Затем мы более детально говорим о предыдущем опыте кандидата, который он/она описал(-а) в своём резюме. Да-да, по тем вопросам, которые я перечислял выше. Обычно мы выделяем от 20 до 30 минут на эту секцию и очень предметно обсуждаем задачи, которые решал кандидат на предыдущих местах работы.

И дальше, на мой взгляд, самая крутая штука – мы показываем человеку список тем и предлагаем ему выбрать от двух до трёх, в которых он наиболее силён и о которых готов пообщаться. Темы сами по себе довольно широкие: Ruby и Ruby on Rails, архитектура ПО, Software Engineering, базы данных и их сопровождение, дизайн и разработка API приложений, Service Reliability Engineering и другие. По каждой из этих тем у нас заготовлен набор открытых вопросов, и мы подробно обсуждаем каждую тему и таким образом понимаем, насколько человек глубоко разбирается в своих основных темах.

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

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

Как развивать эту модель link

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

Например, очень хочется предложить кандидатам также выбор и относительно практической части: либо алгоритмические задачки на Codewars, либо небольшая задачка на system design или дизайн модели данных. В elonsoft я составил, на мой взгляд, отличное тестовое задание (осторожно, протухший сертификат!). Оно решается довольно быстро, и при этом специалисты разных уровней решат его по-разному.

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

Приходите в Telegram, с радостью готов обсудить выработанный подход :) А огонёчек к посту можно поставить в опять же в Telegram, но уже в канале.