Как нанять разработчика, который останется с вами надолго

Чек-лист, который мы используем в BestDoctor

В мае этого года BestDoctor закрыл второй инвестиционный раунд объемом $3 млн. Команде предстоит очень интересный период: развитие новых продуктов, выход на европейский рынок. Мы сейчас активно нанимаем сильных самостоятельных Python-разработчиков, которые помогут нам выйти на новый уровень.

Несмотря на рост, мы хотим сохранить теплую и одновременно драйвовую атмосферу в команде, поэтому придаем большое значение не только hard skills, но и «мягким» навыкам кандидата. Максим Хайкин, ведущий разработчик BestDoctor, рассказал, на что именно мы обращаем внимание на собеседовании.

Я пришел в BestDoctor почти два года назад и был первым нанятым разработчиком. За это время компания выросла с 1 000 до 10 000 подключенных клиентов. Значительно выросла и команда разработки, которую мы планируем и дальше расширять.

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

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

Очень важно вместе со всей командой выяснить, какие технические умения — hard skills — и личностные качества — soft skills — для вас действительно имеют значение. Большая ошибка, которую допускают многие команды — это фокусировка собеседований на хард скиллах, причем зачастую в объеме, который избыточен для проекта. При этом навыки командной работы, организованность и другие важные качества спускаются на тормозах.

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

1. Сформулируйте ключевые компетенции

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

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

2. Составляйте задачи на основе практики

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

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

3. Храните задачи в легкодоступном документе

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

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

4. Оптимизируйте затраты времени

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

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

5. Формулируйте итоги и обратную связь

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

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

И даже если он при этом пойдет не к вам, средний уровень умений на рынке все равно повысится :)

Общий подход здесь все тот же, что и в технической части: выясните, чего вы хотите от человека и какие вопросы для этого задаете.

1. Готовность к вашим задачам

Многие кандидаты в резюме или при разговоре упоминают, что хотят «интересных задач», и каждый под этим понимает что-то своё. Здесь для обеих сторон важно убедиться, что типовые и планируемые задачи разработчика в это определение попадают.

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

2. Умение задавать вопросы

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

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

3. Умение аргументированно отстаивать свое мнение

Очень важно уметь как озвучивать недовольство и критику, так и стоять на своем. Не всегда код разработчика будет принят на ревью с первого раза, не всегда предложенное новшество устроит его или его коллег. И вообще разработка в целом — среда, склонная к дискуссиям.

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

4. Умение отвечать за свою работу

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

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

5. Культурное соответствие

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

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

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