Как нанимать IT-специалистов: чек-лист для HR

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

Как разобраться во всем этом людям, не погруженным в технологии, и качественно решить задачу подбора? Сергей Шапоров, IT-директор BetaOnline, рассказывает о своем опыте найма и делится советами, которые помогут эйчарам построить работу в IT-направлении.

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

Если же компания разрабатывает собственные продукты и речь идет о формировании/расширении проектных команд, то поработать над развитием ИТ-экспертизы придется. Как минимум, на уровне, достаточном для базового понимания лексикона. Например, рекрутеру не обязательно знать, чем отличается Django от Spring и Symfony, но нужно понимать, что все это фреймворки, то есть «каркасы», позволяющие ускорить разработку благодаря тому, что содержат код для выполнения базовых и самых частых процессов.

Итак, HR-отдел получил заявку на подбор ИТ-специалиста. Как с ней работать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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