Как нанять разработчика, который останется с вами надолго
Чек-лист, который мы используем в 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. Культурное соответствие
В каждой компании есть свой сложившийся стиль общения, набор деловых и не только встреч и традиций. Обязательно проверяйте, насколько кандидат будет готов к вашим условиям.
У меня был довольно курьезный найм, когда человек вышел на работу и ушел через неделю, потому что принятый в компании стиль общения ему совершенно не подошел. Это, конечно, потраченная впустую неделя вашего и его времени, но это куда менее страшно, чем когда такой человек остается работать на несколько месяцев и при этом страдает и он, и все остальные.
Также некоторые разработчики очень высокомерно относятся к «гуманитариям» . Для нас важно этого не допускать, потому что говорить им придется, как минимум, со своими менеджерами, с дизайнерами, а иногда и вообще с людьми, чуждыми разработке.
Советы от капитана
в перерывах между написанием статьи на VC
Спасибо за советы
Где чеклист то?
С трудом дочитал "советы постороннему". Особенно мне понравились фразы из 4 пункта, которые нелогично переросли в 5-тый пункт. Давайте прочитаем для понимания вместе: "4. Умение отвечать за свою работу
Статус "Complete" в трекере не означает, что работа над фичей закончена. В ней могут найтись баги, могут поступить предложения об изменениях или улучшениях. Возможно, она не выдержит проверку временем и масштабом."
И тут же про понимание: "...человек вышел на работу и ушел через неделю, потому что принятый в компании стиль общения ему совершенно не подошел..."
Попробовал перефразировать японским стиле: "То, что закончено – может иметь бесконечность. Только засохшая сакура через время может зацвести новым цветом, ибо свежие корни способны могут дать жизнь новым формам".
Вспомнилось... как я к вам на собеседование приезжал, когда у вас был офис еще у bayer, кажется, на Сокольниках. Молодцы! Рад за вас, что так развились. :)
а можно подробнее как вы проверяете что человеку будет интересно работать с такими задачами?
то есть на собеседовании все кандидаты всегда говорят "хорошие, задачи, буду работать"
Если не секрет - что за культура от которой ушёл программист?