Определяем направление, на которое ищем специалиста

Направлений в IT десятки: разработка, интеграция, администрирование, Data Science, машинное обучение и т.д. Каждому из них нужны свои специалисты — не только с определенными знаниями и навыками, но иногда и со своим психотипом. Например, прекрасный Data Scientist чаще всего не сможет быть ведущим разработчиком: они по-разному мыслят и решают задачи.

Мы будем говорить об IT-рекрутинге на примере разработки, так как с ней чаще всего связаны задачи для большинства коммерческих компаний. Хотя в целом информация применима и в других областях.

Разработка в свою очередь тоже бывает разной: мобильных и веб-приложений, под операционные системы, разработка драйверов для устройств, разработка систем, которые работают в оффлайне и т.д. Здесь мы снова сузим тему — предположим, что ищем специалистов под веб- и мобайл-разработку.

И наконец, свои направления существуют внутри команды разработки: фронтенд, бэкенд, тестирование и т.д.

Изучаем вакансию

У любого специалиста есть свой набор hard skills и soft skills. Их баланс определяет то, кем он является на данный момент и куда может развиваться.

Hard skills подразделяются на несколько уровней: начальный, базовый, средний, экспертный и глубокий. В IT они обычно соответствуют той роли, которую специалист может выполнять в команде: intern, junior, middle и senior-разработчик, архитектор.

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

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

Нужен junior-разработчик? Здесь soft-скиллы не принципиальны, главное — наличие базовых профильных знаний. Кандидат должен понимать, что такое алгоритмы, знать язык программирования, уметь решать практические задачи в своем направлении: бэкэндер — работать с базой данных, фронтэндер — работать с LocalStorage, возможно, знать фреймворк. Каждый навык должен соответствовать конкретным технологиям, которые используются в проекте вашей компании.

На позицию senior-девелопера ищем специалиста экспертного уровня. Но если нам нужен тимлид, имеет смысл перенести фокус на soft-скиллы. Задачи тимлида — управлять командой разработки, следить за задачами, выполнять код-ревью, быть наставником для junior и middle разработчиков. При топовых организаторских навыках в некоторых случаях ему может быть достаточно даже среднего уровня hard-скиллов.

Таким образом, искать просто «IT-специалиста» бессмысленно и, вообще говоря, невозможно. Чтобы составить портрет соискателя, эйчару нужно много вводных данных: направление его работы, набор hard-скиллов (в соответствии со списком технологий и платформ, которые используются в проекте), роль в команде.

Как собрать эту информацию?

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

На этой же встрече полезно получить от специалиста список вопросов, которые стоит задать соискателям при первичном собеседовании. Например, мы в BetaOnline используем CQRS и Event Sourcing. И я предлагаю эйчарам попросить кандидатов объяснить, что это и как работает. При этом эйчару не нужно знать ответ самому: если человек не использовал такие подходы, он не сможет дать сколько-нибудь внятного описания. Если же ответ звучит уверенно — кандидата можно звать на техническое собеседование, где точность и глубину его знаний оценят ИТ-специалисты.

Отбираем резюме

Как читать резюме и на что обращать внимание при общении с кандидатами?

1.Стек технологий, с которыми специалист готов работать.

Здесь есть тонкость: список «ключевых слов» по технологиям чаще всего не является точным и окончательным. Например, я могу искать специалиста по технологии А, но человек укажет в резюме не А, а ее составную часть или похожую технологию.

Так, если нам нужен разработчик на Symfony, есть смысл пообщаться со специалистом, который знает Zend, т.к. это фреймворки одного уровня и освоить нужный не составит особого труда. Но если он работает с CodeIgniter или Yii Framework — приглашать на собеседование мы не будем.

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

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

2.Стремление к профессиональному развитию.

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

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

Как определить стремление к развитию по резюме?

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

• Отличный сигнал — указание списка прочитанных книг из своей профессиональной области.

• Если специалист является контрибьютором opensource-проектов, это показывает высокий уровень hard skills и заинтересованность в профессиональном развитии.

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

3.Личностные качества и soft skills.

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

С другой стороны, есть резюме, где текста очень мало: по каждому месту работы перечислены только обширные списки технологий. Нередко такие специалисты оказываются отличными кандидатами на позицию не только senior-разработчика, но и тимлида. Это люди, влюбленные в технологии, для которых стек, с которым они работают, говорит сам за себя. «Прочитать» такое резюме, скорее всего, может только специалист. Поэтому эйчару не стоит его отбрасывать — лучше передать для оценки коллегам из IT.

4.Предыдущие места работы.

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

Проводим первичное собеседование

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

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

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

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

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

Итак, успех подбора персонала в IT-команду со стороны рекрутинга зависит от нескольких факторов:

• готовности эйчара погрузиться в специфику, освоить базовые понятия;
• качества подготовительной работы, проведенной совместно с техническими специалистами;
• способности уделить внимание деталям в процессе подбора.

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

Минусы

1.Высокий стартовый пакет.

Минимальный срок сотрудничества — 2 месяца, оптимальный — от 1 квартала. Если инхаус-маркетинг может начать работать с любым бюджетом, который ему выделят, то у нас есть определенный “входной билет” в виде сроков и бюджета проекта.

2.Более высокая стоимость лида.

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

3.Непрозрачные каналы привлечения трафика.

Конечно, заказчик знает, какие каналы мы задействуем, но тонкости настройки будут от него скрыты. Мы не предоставляем доступ к рекламным кампаниям и аккаунтам — они находятся и управляются на нашей стороне. (Оговоримся, что это условие касается модели работы с оплатой за лиды).

Классическое или специализированное диджитал-агентство?

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

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

Собрать такую команду в инхаус-маркетинге тоже можно. Но если до сих пор специалисты с разных сторон не взаимодействовали между собой, то отлаживание процессов займет время. Им нужно спланировать совместную работу, запустить ее, проанализировать результаты, провести работу над ошибками и дальше по кругу — это будет постепенная долгая работа. А главное — им нужно стать командой.

Подведем итоги

1. С помощью инхаус-маркетинга можно привлекать лиды и закрывать вакансии. Это будет дешевле (правда, это неточно). Но придется потратить много времени на прокачивание компетенций, пилотные проекты и метод проб и ошибок.
2. Благодаря нашим услугам компания может ускорить этот процесс и решить задачу в режиме “здесь и сейчас”, но с большей стоимостью привлечения лида.

Быстрее и дороже — или дольше, но дешевле? Вечный вопрос. Общего ответа тут нет. Зависит от остроты потребности, ограниченности бюджета, готовности специалистов и руководителей к освоению новых навыков. Если ваш выбор — скорость и гарантия результата, переходите на план B!