Найм в IT: Построение процесса
На мой взгляд, найм является ключевым фактором в построении успешной команды разработки. В то же время, во многих IT-компаниях не уделяют этому процессу должного внимания и считают его фоновым, стараясь отвлекаться на него лишь по мере необходимости. В этой статье я хочу поделиться практическими советами, которые могут помочь снизить вероятность ошибок при найме, стандартизировать процесс и определить кого на самом деле вы ищете. В качестве примеров я буду использовать найм на технические позиции, но принципы можно рассматривать как общие для всех ролей в команде.
Параллели со спортом
Мне нравится рассматривать продуктовую IT-компанию, как профессиональную спортивную команду в конкурентном виде спорта. Хорошие примеры - футбол, баскетбол, хоккей. Если подумать, между ними не так мало общего:
Рынок талантов. Спортивные клубы с большими бюджетами борются за лучших атлетов. Для достижения чемпионских целей нужно построить чемпионскую команду. Зарплаты в топовых лигах все время растут. После проведения 3-5 сезонов в высшей лиге, спортсмену больше не приходится самому искать работу, предложения с новыми контрактами поступают сами. Очень похоже на IT-рынок.
Конкуренция и цена ошибки. Спортивные команды, занявшие последние места по итогам сезона или регулярного чемпионата, либо выбывают из лиги, либо не проходят в стадию Play-off. В IT молодые стартапы, проигравшие конкуренцию или не пробившиеся на рынок - просто закрываются.
Командная работа. Один игрок, даже самый звездный, не может выполнить задачу без помощи партнеров. Каждый зависит от каждого и все работают на общий результат.
Поэтому мне кажется, что IT-компаниям имело бы смысл поизучать более пристально опыт коллег из мира спорта, т.к эта сфера намного старше чем IT. В своих примерах ниже я буду делать отсылки на эту тему.
Этап 0. Кто мы и кого мы хотим нанять?
Для того, чтобы построить эффективную команду, будет неплохо ответить на базовые вопросы:
Какие цели стоят перед компанией на ближайший год и как они связаны с разработкой продукта? Примеры: сделать и выпустить MVP за 6 месяцев, вырасти горизонтально в два раза по команде и деливери, оптимизировать процесс и снизить time to market.
Насколько технически сложен создаваемый продукт? Какой минимальный технический уровень специалистов требуется для работы в команде (можно определить стандартными рангами: junior, middle, senior)?
В чем мы видим наше конкурентное преимущество: скорость и объем функциональности / уникальность продукта / можем сделать дешевле чем конкуренты?
Эти вопросы, помогут правильно определить входные критерии по экспертизе кандидатов.
Пример из мира спорта. Если команда не обладает чемпионскими амбициями или ресурсами - она не пытается привлекать самых звездных игроков. И наоборот, если уровень конкуренции и ставки высоки (финальная стадия play-off), вы не можете позволить выпускать на поле новичков, для того чтобы они набирали опыт, или игроков не в лучшей форме. На важные игры выходят только лучшие и те кто готов приносить результат прямо сейчас.
Результатом данного этапа должен быть список ролей (вакансий), которых вы готовы нанимать с требованиями по опыту и критериями отбора. Пример: На бэкенд нанимаем от middle и выше, обязательно знание языка N и фреймворка M. На фронтенд нанимаем только senior из-за сложности проекта. Язык B обязателен, фреймворк C желателен, но необязателен т.к это не мейнстрим и для уровня senior инструмент вторичен. В QA готовы брать junior-ов т.к много ручной работы и есть экспертиза по менторству в команде. И т.д...
Почему нельзя сказать "просто нанимаем самых лучших"? Во-первых, это очень сложно и дорого. Не стоит ставить непосильные задачи, если в этом нет необходимости. Во-вторых, если даже вам удастся вначале нанять лучших, но вы не сможете обеспечить их задачами, соответствующими их уровню - они начнут терять мотивацию и со временем уйдут. По моим наблюдениям, людям удается сохранять мотивацию и стимул для роста на длинной дистанции, когда выполняются несколько условий:
Задачи, которые они решают являются для них вызовом.
В команде их окружают люди их уровня или выше.
Понятны общие цели, которые команда пытается достичь как коллектив.
Именно поэтому важно четко определить уровень экспертизы для каждой роли и синхронизировать требования по ним с HR.
Этап 1. Воронка кандидатов
Все практики, о которых я рассказываю в этой статье, работают хорошо только на больших цифрах. Чем четче критерии отбора, тем больше необходимо создать входной поток из кандидатов, чтобы после всех раундов просева, до офера кто-то доходил более-менее регулярно. Для меня, как нанимающего менеджера, который участвует в процессе найма на поздних стадиях воронки, это что-то вроде магии, которую колдует HR-отдел. Вакансии бывают сложные и простые, вилки з/п высокие и не очень, на рынке кризис или расцвет, но кто-то обеспечивает стабильный поток кандидатов, а кто-то нет. Если потока из CV нет - на следующих стадиях воронки начинает снижаться планка требований и мы начинаем нарушать правила из этапа 0, чтобы хоть кого-нибудь нанять. Это всегда проигрышная стратегия в долгую.
Нужно вкладываться в рекрутинг, привлекать HR, которые способны обеспечивать стабильную воронку, вводить KPI на объем кандидатов или закрываемых вакансий. Это окупится для компании.
Пример из спорта. В штате спортивных клубов есть агенты, которые ищут талантливых спортсменов по всему миру. Они летают на матчи других лиг, изучают статистику, пытаются высмотреть таланты на ранней стадии их карьеры и предоставляют отчеты менеджменту своего клуба.
Этап 2. Процесс найма
Я не планирую в данной статье детально разбирать все этапы воронки найма, т.к количество раундов интервью зависит от роли и размера компании. Тут важны общие принципы, которые я для себя сформулировал так:
1) Тщательно назначайте интервьюеров, они - это лицо компании для внешнего мира
В каждом этапе интервью участвуют две стороны и происходит два действия одновременно: кандидат пытается продать себя и свои навыки компании, компания пытается продать себя кандидату. Предположим HR-отдел обеспечил качественный поток кандидатов и вы готовы нанять каждого пятого (это очень хорошая конверсия), но офер принимают далеко не все. В чем может быть причина? Возможно, интервьюеры недостаточно хорошо продают. Это может быть как в прямом смысле - мало рассказывают о внутренней кухне компании и перспективах поработать в сильной команде над решением амбиционных задач, или косвенно - кандидат не впечатлен уровнем компетенций или коммуникацией с теми кто его собеседовал. Лучшие хотят работать с лучшими, поэтому вам нужно показать внешнему миру лучших. Если вакансия скромнее, как минимум интервью нужно доверить тем, кто с удовольствием коммуницирует с незнакомыми людьми, чтобы атмосфера интервью была живой.
2) В конце цепочки технических интервью, принимать решение о найме следует непосредственному руководителю для данной позиции
Интервью линейного менеджера с его потенциальным подчиненным, это короткая демо-версия их будущих профессиональных отношений. Опытный руководитель обратит внимание не только на то, справился ли кандидат с техническими задачами на интервью, но и на такие моменты как: Пришел ли кандидат вовремя на встречу? Насколько он серьезно относится к процессу? Как он отзывается о бывших коллегах и предыдущих местах работы? Играет ли он с вами в команде в процессе интервью или демонстрирует раздражение теми вопросами, которые ему задают или саботирует их? Будущий руководитель может представить по эмоциональной окраске беседы, как кандидат будет вести себя в коллективе и комфортно ли будет ему делегировать ответственные задачи, за результат которых будет отвечать он сам руководитель. Пример из спорта: игрок не может попасть в команду, без участия тренера.
3) Полезно вести статистику воронки, сколько кандидатов доходит до каждого уровня и сколько проходит дальше
Каждый этап воронки дороже предыдущего т.к требует участия более квалифицированных интервьюеров. Если на каком-то этапе у нас отваливаются 90% кандидатов - это повод подкрутить предыдущий этап (или добавить если его еще нет), дать обратную связь и синхронизировать критерии. Найм это живой процесс. Пример из спорта: статистика используется на всех уровнях, без нее не принимается практически ни одно решение.
4) Обратная связь
По каждому кандидату нужно фиксировать обратную связь на всех этапах интервью с момента как произошла первая коммуникация с ним. Поможет любая CRM вроде Huntflow. Если человек прошел на третий этап интервью, интервьюер должен иметь обратную связь с предыдущих двух этапов чтобы подготовиться. Если кандидат получает отказ на любом из этапов - следует отправить ему обратную связь и объяснить причины. Больше всего кандидаты не любят, когда не получают вообще никакого ответа. Это негативно сказывается на HR-бренде компании. Даже просто скопировать фидбек с последнего этапа интервью и отправить как есть будет лучше в таком случае. Кандидат отметит вашу компанию среди остальной массы и через год, набравшись опыта, может придти к вам снова.
5) Техническое интервью должно включать практические задачи, желательно из реальной жизни
Сразу пример из спорта. Невозможно определить уровень игры футболиста, если вы даже не видели его в спортивной форме на поле. Скауты смотрят матчи игроков, устраивают просмотры новичков в своих клубах, подписывают контракты с игроками на 10 дней, чтобы увидеть их в деле и потом предложить долгосрочный контракт. Я советую применять тот же подход в IT. Поговорить абстрактно об опыте работы, перечислить технологии с которыми кандидат работал, спросить пару заковыристых вопросов по языку или фреймворку - на мой взгляд это самый бесполезный вариант технического интервью. При таком подходе легко ошибиться в обе стороны: пропустить слабых и отказать сильным у которых мало опыта с конкретным стеком технологий (про важность стека я писал в предыдущей статье). Намного сложнее ошибиться, когда кандидат на ваших глазах сел и что-то сделал руками. Оффлайн интервью или онлайн с шарингом экрана - не так важно. Главное проверить что человек действительно хорош в том, чем он будет заниматься у вас в компании. Devops - дайте ему консоль или доступ в какой-нибудь k8s-кластер. QA - попросите написать тест-кейсы или протестировать несложный экран по заготовленным тест-кейсам. Разработчик - дайте несколько задач с leetcode или свои собственные, желательно не сильно завязанные на стек технологий. В практике человек раскрывается намного шире. Вы почувствуете по тому, как он работает руками, хотите вы его нанять или нет. Усилит ли он команду с первых дней работы или в него придется вкладываться и обучать.
6) Ищите профессионалов, а не просто экспертов
В чем отличие? Экспертность это про hard-skills: глубокие знания технологий и инструментов, опыт решения нестандартных задач. Это важно, но совсем не достаточно. Профессионализм - это про soft-skills. Приходить вовремя на встречи, чувствовать ответственность за результат, стараться не блокировать других своей работой, помочь коллегам если они не успевают что-то сделать к дедлайну. Выходить за пределы своего скоупа ответственности, если есть возможность принести пользу. Быть проактивным. Об этом я уже упоминал в предыдущей статье. Как проверить эти качества на интервью? Для этого не нужны отдельные вопросы или задачи. Как я уже писал выше в п.2, процесс найма уже содержит достаточное количество коммуникаций нанимающей стороны и кандидата. Это своего рода уже испытательный срок. Интервьюерам нужно лишь считывать важные сигналы в процессе этой коммуникации и фиксировать все, что заслуживает внимания, в обратной связи. Таким образом эмоциональный окрас не выветрится к моменту, когда нужно будет принимать решение по оферу.
Этап 3. Онбординг
Когда предыдущие этапы настроены правильно, выход нового сотрудника на работу становится будничным событием. Не стоит недооценивать важность этого этапа. Он должен быть так же формализован и проработан.
Первое впечатление новичка о компании составляется по уровню организованности внутри компании. Ему очень важно в первые дни быстро решить технические вопросы, познакомиться с проектом и начать работать над реальной задачей. Если этот процесс проходит хаотично - есть вероятность демотивировать вашего нового коллегу уже на старте.
Создайте базу знаний для своих сотрудников в Wiki и сделайте так, чтобы был всегда человек, который курирует новичка в его испытательный срок, тот кто может помочь ему быстрее влиться в процесс. Главный критерий - как быстро с момента прихода в команду человек начнет приносить какую-то реальную пользу команде.
Этап 4. Испытательный срок
Многие относятся к испытательному сроку как к формальности в трудовом договоре, но я, например, считаю по-другому. Мы уже обсудили почему ошибки в найме стоят очень дорого, и если уж мы их допускаем - испытательный срок, это последний рубеж, когда мы можем эти ошибки отловить и уменьшить их последствия. На испытательном сроке нам нужно решить три задачи:
Успеть обеспечить человека реальными задачами, чтобы объективно оценить его профпригодность. Для этого и нужны отлаженный процесс онбординга.
Продемонстрировать компанию с лучшей стороны, чтобы сотрудник захотел остаться после испытательного срока. Тут тоже помогут процессы.
Собрать обратную связь по результатам работы. Принять волевое решение расстаться если сработаться по каким-то причинам не получилось. Увольнения не самый приятный процесс, но как и в спорте, он необходим для того, чтобы весь механизм продолжал работать и общий уровень внутри команды не опускался ниже заданной планки. Помните, слабые игроки в команде, тянут остальных вниз. Люди с токсичным культурным кодом наносят непоправимый ущерб всей команде и опускают остальных на свой уровень.
Ваша задача не нанять всех кого сможете и научиться как-то худо-бедно работать с каждым. Ваша задача - найти именно своих людей и создать условия, чтобы такие люди хотели задержаться в вашей команде.
Заключение
На этом все. Пишите ваши мысли в комментариях. В следующих статьях я хочу рассказать про свой опыт проведения технических интервью для frontend-разработчиков с примерами задач. Чтобы не пропустить - подписывайтесь на мой телеграм канал.
