IT-рекрутмент. Как найти лучших специалистов, когда все вокруг горит

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

Подводя итог этой главы, хочу лишь сказать, что рекрутер – это уже не просто человек, который может позвонить кандидату с hh.ru и пригласить его на собеседование. Рекрутер – сложная профессия, требующая большого количества скиллов. Это, конечно, немного усложняет нашу с вами повседневную жизнь, но в то же время делает ее безумно интересной.

Глава 3

Начало. Получение вакансии

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

Встреча с заказчиком и определение профиля кандидата, или, как это часто называют, «снятие заявки»,[3] – ответственнейший момент, который во многом будет определять, как работа сложится дальше. Не стоит недооценивать его важность. Облажаться на данном этапе – все равно что споткнуться и упасть в начале забега: догнать остальных еще есть шанс, но усилий для этого придется потратить в разы больше. И самое парадоксальное то, что многие рекрутеры к этому процессу не готовятся. На самом деле для того, чтобы этот этап прошел хорошо, важно обладать теми самыми коммуникативными навыками, о которых мы говорили вначале. Умение вести переговоры – одно из ключевых для рекрутера. Но зачастую их успешность зависит от этапа подготовки к ним. Чем лучше подготовка, тем меньше сюрпризов на самих переговорах. В то же время чем больше информации мы соберем на старте, тем точнее будут наши вопросы, тем правильнее мы составим профиль кандидата и тем лучше будем понимать, кого же мы ищем, а значит, и где нам его искать.

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

Поэтому, перед тем как идти на встречу с заказчиком, я настоятельно рекомендую вам обратить внимание на следующие нюансы.

● Чем занимается компания. Важно понимать сферу деятельности, потому что она может накладывать определенные «отягчающие обстоятельства» на поиск. Например, если компания работает в сфере беттинга или микрофинансов, большинство кандидатов отказываются от вакансии именно из-за сферы, с которой не хотят связываться. Какие у компании планы? Возможно, они писали об этом в блоге – и вы сможете лучше понимать перспективы позиции.

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

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

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

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

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

Итак, предварительная работа проделана: статус проекта понятен, заказчик изучен, вакансия испещрена комментариями и вопросами. Что дальше? Дальше – сама встреча. Основная ваша задача на ней – понять правильный профиль кандидата, которого вы будете искать. И очень важно, чтобы в этом вопросе заказчик вам помогал и был с вами на одной стороне. Хотя иногда его и нужно возвращать к реальности. Но сначала предлагаю разобраться с тем, какие вопросы по вакансии вы можете задать.

Я бы условно поделил их на несколько групп.

Первая – вопросы о компании. Это те вопросы, на которые вы уже частично могли получить ответы в интернете и задавая которые вы будете сверять соответствие загугленного действительности.

● Чем занимается компания?

● Сколько в ней человек, какая структура и география?

● Какие планы по развитию на текущий год?

● Кто основные конкуренты, есть ли среди них компании-доноры (то есть те, в которых можно будет искать людей на вакансию)?

● Почему сотрудники в принципе выбирают эту компанию?

● Почему клиенты ее выбирают?

Вторая группа – вопросы о проекте. По факту они очень тесно связаны с вопросами о компании и как бы вытекают из них.

● На какой проект ищут человека, на какой стадии сейчас проект?

● Сколько человек на проекте?

● Сколько человек в команде, в которую ищем кандидата?

● Какая методология разработки? Если гибкая, то насколько Scrum[4] (или не Scrum) чистый, какие элементы внедрены?

● От кого поступают задачи?

● Есть ли code review[5] (для разработчиков)?

● Есть ли система контроля версий (СКВ)[6], какая? (Скорее всего, это будет видно в описании вакансии, самые популярные СКВ – Git, SVN, Mercurial, TFS.)

● Как часто бывают релизы[7]?

Третья группа вопросов – самая важная и самая сложная для рекрутеров, потому что это вопросы о задачах. Сложно это для нас потому, что мы далеко не всегда можем реально понять, что означают те или иные задачи. Да и тимлиды, и IT-специалисты не всегда подробно их формулируют и часто ограничиваются довольно сухими примерами. Очень важно понять реальные задачи, чтобы впоследствии включить их в описание вакансии и сделать его наиболее привлекательным для кандидатов.

● Какие задачи будет выполнять кандидат?

● Какие задачи сейчас есть в бэклоге[8] (если по-простому – в пуле)?

● Назовите пример наиболее сложных задач, с которыми кандидату придется столкнуться и которые теоретически могут стать для него вызовом.

● Представим себе ситуацию, что кандидат сегодня вышел на работу. Какие задачи он получил бы прямо сейчас?

● А через месяц/полгода?

● Зачастую полезно узнать, в каком процентном соотношении и какие задачи будут у кандидата. Например, если мы ищем фронтенд-разработчика[9], важно понять, какой процент его времени будет занимать верстка, так как не все фронтенд-разработчики готовы заниматься ею в каком-то существенном объеме.

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

Четвертая группа вопросов – о технологиях. Еще одна очень важная и сложная группа. Потому что она тоже относится к той сфере знаний, которая дается рекрутерам зачастую довольно-таки сложно.

● Какой текущий стек[10]? Какая архитектура проекта?

● Планируются ли какие-то изменения в стеке? Этот вопрос можно конкретизировать. Например, если в вакансии мобильного разработчика указано знание Objective-C, обязательно стоит уточнить, планируется ли переход на Swift, так как Objective-C – устаревающая технология и специалистов с ней искать будет сложнее и дольше.

● Есть ли на проекте legacy-код[11]? Если да, какой процент задач будет составлять поддержка legacy, а какой – разработка нового функционала?

● Какие из указанных знаний наиболее критичны? Зачастую заказчик указывает в вакансии огромное количество технологий, с которыми в реальности кандидату работать придется не так много. Важно сразу понять, какие технологии наиболее критичны, а какие можно даже не вписывать в поиск, чтобы не сужать себе воронку.

● Важно также обратить внимание на сам стек и на мелочи, которые могут быть указаны в стеке, но существенно усложнят поиск или окажутся нелогичными. Так, если продолжить пример с вакансией мобильного разработчика, в ней может быть указан еще и такой язык программирования, как C++. Это язык, который напрямую не относится к мобильной разработке; важно понимать, для чего его добавили, какие задачи на нем будет выполнять кандидат.

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Сноски

1

Tegze Jan. Full Stack Recruiter: The Modern Recruiter's Guide. CreateSpace, 2017.

2

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

3

Кстати, именно такую формулировку чаще используют в кадровых агентствах.

4

Scrum – один из фреймворков гибких подходов к разработке. Подробнее мы о нем поговорим далее.

5

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

6

Система контроля версий – это специальное ПО, сохраняющее различные версии проекта, чтобы впоследствии была возможность вернуться к предыдущей версии. Например, если новые доработки оказались «кривыми» и повлекли много ошибок (багов), которые не были замечены при тестировании. Еще важная черта системы контроля версий – это возможность писать проект одновременно нескольким разработчикам и даже командам разработки.

7

Условно релиз можно назвать анонсом, выпуском нового функционала ПО.

8

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

9

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

10

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

11

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