# Найм в 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-ов т.к много ручной работы и есть экспертиза по менторству в команде. И т.д...

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

1. Задачи, которые они решают являются для них вызовом.
    
2. В команде их окружают люди их уровня или выше.
    
3. Понятны общие цели, которые команда пытается достичь как коллектив.
    

Именно поэтому важно четко определить уровень экспертизы для каждой роли и синхронизировать требования по ним с HR.

## Этап 1. Воронка кандидатов

Все практики, о которых я рассказываю в этой статье, работают хорошо только на больших цифрах. Чем четче критерии отбора, тем больше необходимо создать входной поток из кандидатов, чтобы после всех раундов просева, до офера кто-то доходил более-менее регулярно. Для меня, как нанимающего менеджера, который участвует в процессе найма на поздних стадиях воронки, это что-то вроде магии, которую колдует HR-отдел. Вакансии бывают сложные и простые, вилки з/п высокие и не очень, на рынке кризис или расцвет, но кто-то обеспечивает стабильный поток кандидатов, а кто-то нет. Если потока из CV нет - на следующих стадиях воронки начинает снижаться планка требований и мы начинаем нарушать правила из этапа 0, чтобы хоть кого-нибудь нанять. Это всегда проигрышная стратегия в долгую.

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

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

## Этап 2. Процесс найма

Я не планирую в данной статье детально разбирать все этапы воронки найма, т.к количество раундов интервью зависит от роли и размера компании. Тут важны общие принципы, которые я для себя сформулировал так:

**1) Тщательно назначайте интервьюеров, они - это лицо компании для внешнего мира**

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

**2) В конце цепочки технических интервью, принимать решение о найме следует непосредственному руководителю для данной позиции**

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

**3) Полезно вести статистику воронки, сколько кандидатов доходит до каждого уровня и сколько проходит дальше**

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

**4) Обратная связь**

По каждому кандидату нужно фиксировать обратную связь на всех этапах интервью с момента как произошла первая коммуникация с ним. Поможет любая CRM вроде [Huntflow](https://huntflow.ai/). Если человек прошел на третий этап интервью, интервьюер должен иметь обратную связь с предыдущих двух этапов чтобы подготовиться. Если кандидат получает отказ на любом из этапов - следует отправить ему обратную связь и объяснить причины. Больше всего кандидаты не любят, когда не получают вообще никакого ответа. Это негативно сказывается на HR-бренде компании. Даже просто скопировать фидбек с последнего этапа интервью и отправить как есть будет лучше в таком случае. Кандидат отметит вашу компанию среди остальной массы и через год, набравшись опыта, может придти к вам снова.

**5) Техническое интервью должно включать практические задачи, желательно из реальной жизни**

Сразу пример из спорта. Невозможно определить уровень игры футболиста, если вы даже не видели его в спортивной форме на поле. Скауты смотрят матчи игроков, устраивают просмотры новичков в своих клубах, подписывают контракты с игроками на 10 дней, чтобы увидеть их в деле и потом предложить долгосрочный контракт. Я советую применять тот же подход в IT. Поговорить абстрактно об опыте работы, перечислить технологии с которыми кандидат работал, спросить пару заковыристых вопросов по языку или фреймворку - на мой взгляд это самый бесполезный вариант технического интервью. При таком подходе легко ошибиться в обе стороны: пропустить слабых и отказать сильным у которых мало опыта с конкретным стеком технологий (про важность стека я писал в [предыдущей статье](https://krasman.hashnode.dev/chto-yavlyaetsya-glavnym-sekretom-uspeha-effektivnoj-razrabotki-it-produkta#heading-glavnoe-zabluzhdenie-razrabotchikov)). Намного сложнее ошибиться, когда кандидат на ваших глазах сел и что-то сделал руками. Оффлайн интервью или онлайн с шарингом экрана - не так важно. Главное проверить что человек действительно хорош в том, чем он будет заниматься у вас в компании. Devops - дайте ему консоль или доступ в какой-нибудь k8s-кластер. QA - попросите написать тест-кейсы или протестировать несложный экран по заготовленным тест-кейсам. Разработчик - дайте несколько задач с [leetcode](https://leetcode.com/) или свои собственные, желательно не сильно завязанные на стек технологий. В практике человек раскрывается намного шире. Вы почувствуете по тому, как он работает руками, хотите вы его нанять или нет. Усилит ли он команду с первых дней работы или в него придется вкладываться и обучать.

**6) Ищите профессионалов, а не просто экспертов**

В чем отличие? Экспертность это про hard-skills: глубокие знания технологий и инструментов, опыт решения нестандартных задач. Это важно, но совсем не достаточно. Профессионализм - это про soft-skills. Приходить вовремя на встречи, чувствовать ответственность за результат, стараться не блокировать других своей работой, помочь коллегам если они не успевают что-то сделать к дедлайну. Выходить за пределы своего скоупа ответственности, если есть возможность принести пользу. Быть проактивным. Об этом я уже упоминал в [предыдущей статье](https://krasman.hashnode.dev/chto-yavlyaetsya-glavnym-sekretom-uspeha-effektivnoj-razrabotki-it-produkta#heading-kadry-i-najm). Как проверить эти качества на интервью? Для этого не нужны отдельные вопросы или задачи. Как я уже писал выше в п.2, процесс найма уже содержит достаточное количество коммуникаций нанимающей стороны и кандидата. Это своего рода уже испытательный срок. Интервьюерам нужно лишь считывать важные сигналы в процессе этой коммуникации и фиксировать все, что заслуживает внимания, в обратной связи. Таким образом эмоциональный окрас не выветрится к моменту, когда нужно будет принимать решение по оферу.

## Этап 3. Онбординг

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

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

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

## Этап 4. Испытательный срок

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

1. Успеть обеспечить человека реальными задачами, чтобы объективно оценить его профпригодность. Для этого и нужны отлаженный процесс онбординга.
    
2. Продемонстрировать компанию с лучшей стороны, чтобы сотрудник захотел остаться после испытательного срока. Тут тоже помогут процессы.
    
3. Собрать обратную связь по результатам работы. Принять волевое решение расстаться если сработаться по каким-то причинам не получилось. Увольнения не самый приятный процесс, но как и в спорте, он необходим для того, чтобы весь механизм продолжал работать и общий уровень внутри команды не опускался ниже заданной планки. Помните, слабые игроки в команде, тянут остальных вниз. Люди с токсичным культурным кодом наносят непоправимый ущерб всей команде и опускают остальных на свой уровень.
    
    Ваша задача не нанять всех кого сможете и научиться как-то худо-бедно работать с каждым. Ваша задача - найти именно своих людей и создать условия, чтобы такие люди хотели задержаться в вашей команде.
    

## Заключение

На этом все. Пишите ваши мысли в комментариях. В следующих статьях я хочу рассказать про свой опыт проведения технических интервью для frontend-разработчиков с примерами задач. Чтобы не пропустить - подписывайтесь на мой [телеграм канал](https://t.me/bro_science_dev).