Эффективные приемы подбора персонала на "перегретом рынке"

Я руковожу различными командами уже в течение 10 лет, соответственно, одной из моих задач, как руководителя, является подбор персонала.

Шишек в этом нелегком деле я набил очень много, и сегодня хочу поделиться с вами лучшими практиками, чтобы вы мои шишки не повторяли. Я надеюсь, вы все умные и умеете учиться на чужих ошибках.

Как я начинал подбирать персонал

По моему опыту, истории провалов усваиваются намного лучше, чем истории успеха. Поэтому я начну с того, что расскажу, как я ошибался.

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

• Само собеседование я проводил по принципу беседы. Мы обсуждали опыт кандидата, беседовали по тем моментам, которые он обозначил в резюме, как свои ключевые навыки. Либо по его проектам. Соответственно, беседа с каждым потенциальным сотрудником была уникальная. По одному сценарию такие беседы, конечно, не проходят. Опыт у всех разный, поэтому беседа проходила в уникальном ключе.

• Тестовые задания я давал достаточно редко. Но по моему опыту эти тестовые задания все равно не выполняются. Кандидат говорит: «Да, хорошо», и уходит. Почему так происходит? Потому что спрос на 1С-программистов, на 1С-аналитиков превышает предложение, и у него рядом такая же компания, которая дает ему столько же денег, только без всяких тестовых заданий – конечно, он пойдет туда.

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

Проблемы, с которыми я сталкивался

Самый типичный кейс, как происходила дальнейшая судьба сотрудника, такой. Представьте себе, девушка – выпускница отличного вуза, мехмата МГУ. У нее 10 лет опыта работы программистом не 1С, потом 7 лет опыта работы 1С-программистом. Очень хороший опыт. Она хорошо рассказывала про свои предыдущие места работы, хорошо общалась на собеседовании. Конечно, я взял ее на работу. Но через месяц пришлось уволить. Почему? Потому что оказалось, что она мастер спорта по запросам, а у меня задачи такие, что нужно проектировать подсистемы, а не писать отчеты. Соответственно, моя ошибка, как руководителя, был в том, что я не проверил ее на соответствие тем критериям успеха, которые могли бы позволить успешно выполнять мои задачи.

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

Формализованный подход

К тому методу подбора, который я сейчас использую, я шел долго. У меня степень MBA в области финансов, я выпускник президентской программы подготовки управленческих кадров. В каждой из этих образовательных программ нас учили подбирать персонал, давали определенные методики. Я эти методики, естественно, адаптировал под нашу сферу, под нашу отрасль. И сегодня я с вами поделюсь теми лучшими практиками, которые у меня получились по итогам моих “шишек” и лучших практик, которым меня учили.

• Во-первых, когда вы подбираете персонал, вы должны четко сформулировать критерии, которым должен соответствовать тот сотрудник, которого вы подбираете.

  • На том примере, который я привел, критерием успеха будет – сотрудник должен уметь проектировать подсистемы.

  • Дальше – от критериев вы переходите к требованиям. Например, если сотрудник должен уметь проектировать подсистемы, то мы предъявляем к нему требования, что он должен знать, как работают регистры накопления, регистры сведений, как строятся индексы на уровне СУБД.

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

• Подбор должен быть системным процессом. В приведенном в начале доклада примере, для меня подбор был несистемным процессом: я брал первого понравившегося. Я смотрел резюме, приглашал человека на собеседование, и для меня подбор персонала тогда начинался на собеседовании. Так быть не должно. Вы должны четко планировать свою деятельность. Если вы знаете, что вам нужно вывести 10 человек, прособеседовать нужно 100 человек. Соответственно, первичная воронка должна быть в районе 1000.

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

Сейчас мы эти шаги подробно разберем.

Воронка подбора персонала

Как выглядит воронка подбора персонала:

• На первом этапе HR анализирует резюме, назначает собеседование. На этом этапе чем качественнее те резюме, которые к вам зайдут, тем больше вероятность того, что по итогам интервью вы захотите человека взять. По моему опыту, не все хорошие специалисты умеют писать резюме. Поэтому нужно уметь балансировать. Люди, которых собирает HR, необязательно должны иметь идеальное резюме. Но нужен баланс, потому что собеседовать вчерашних бухгалтеров и студентов – удовольствие ниже среднего. Трудозатрат много, а результат маленький. Здесь нужно четко настраивать HR на то, как подбирать резюме.

• Дальше – проводите интервью. Интервью проводите четко по вопросам – никаких бесед, потому что, если вы начинаете с кандидатом беседовать, вы потом не сможете сопоставить этого кандидата с другим кандидатом, потому что с другим кандидатом вы беседовать будете о другом. У вас должен быть четкий опросник, по которому вы идете и отмечаете себе, фиксируете результаты каждого вопроса.

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

Анализ резюме, проведение интервью, выбор по критериям

Итак, на первом этапе – на анализе резюме:

• Совместно с HR настраивайте параметры поиска резюме. Простой пример неудачной настройки параметров поиска: у кандидата в резюме стоит: «Пять лет работал на конфигурации 1C:ERP», а вам нужен сотрудник на «1С:Управление торговлей». HR не увидел слово «1С:Управление торговлей» и, соответственно, резюме отклонил. Я надеюсь, на это уже никто не ловится. С «1C:ERP» и «1С:Управление торговлей» HR-специалисты уже более-менее разобрались. Но бывают более сложные ситуации. Например, «1С:Консолидация» и «1С:Управление холдингом». Если человек пять лет работал на «1С:Консолидации», то он, конечно, очень быстро освоит бюджетирование в «1С:Управление холдингом», и это будет хороший сотрудник. Поэтому аккуратно подстраивайте эти параметры с HR-специалистом.

• Самое плохое, что может быть – это если HR просто смотрит по ключевым словам. Критерии отбора резюме нужно настраивать совместно с HR.

• Идеально, если вы сядете совместно с HR-специалистом, посмотрите несколько резюме – и объясните, что это резюме вам подходит по таким-то параметрам, а это резюме не подходит по таким-то причинам. По моему опыту, человек с высшим образованием даже не из ИТ-отрасли, способен осознать, какие критерии вы предъявляете к резюме.

При проведении интервью:

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

• Все результаты записывайте в свой опросник.

Про выбор по критериям я уже рассказывал:

• каждого кандидата прогоняете по одной и той же схеме;

• все результаты фиксируете;

• и на выходе у вас получается информация для вашего управленческого решения.

Еще раз подчеркну – три этапа:

• сначала – критерии;

• потом на основе критериев – вопросы;

• и только потом уже интервью – то есть работа по подбору начинается задолго до того, как человек пришел к вам на собеседование.

И обязательно фиксируйте все результаты и принимайте решение на основании сопоставимых критериев.

Лучшая организация интервью – тест и опросник

Обратите внимание, 80% работы по подбору нужно проводить до собеседования.

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

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

Чуть дальше мы посмотрим, как тесты разрабатывать, какие опросники применять и т.д.

План хорошего интервью

Не могу не напомнить, что план хорошего интервью – это:

• Во, первых, представиться

• Рассказать о том, как будет проходить интервью. Это, вроде, мелочь, но это очень важно, потому что человек в стрессе – вы сами знаете, все ходите по интервью. Расскажите ему о том, что будет дальше – что нужно будет решить небольшой тест на 10 минут, это не займет много времени. Успокойте его, что этот тест – не тестовое задание, которое потом пойдет в продуктив, что вы не собираетесь использовать кандидата, как бесплатные руки.

• Далее нужно немного рассказать о вакансии.

• Провести само интервью.

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

Еще раз – формулируем критерии соответствия кандидата должности, от критериев вы вырабатываем требования, и от требований переходим к конкретным вопросам.

• Первым этапом идет тест – в нем представлены технические вопросы на проверку hard skills, например: «Регистр накопления нужен для… и три ответа».

• Но это не все, что вам нужно – вам же еще нужно понять опыт кандидата, а для этого используется опросник. И здесь тоже напоминаю – не уходите в беседу! В опросник очень хорошо вставлять вопросы, которые нужны именно вам. Например, у вас есть интеграция через REST и SOAP, поэтому спрашивайте: «Расскажите про ваш опыт интеграции через REST», «Расскажите про ваш опыт интеграции через SOAP», «Расскажите, какие еще способы интеграции вы знаете». Таким образом, вы не уйдете в сторону – вы точно выясните то, что нужно именно вам.

Принципы формирования теста

Принципы формирования теста:

• Тест должен быть коротким, на 10-15 минут. Не нужно писать талмуды, потому что человек тогда первую страницу более-менее внимательно ответит, вторую – уже не вчитываясь, а дальше будет просто галки ставить «от балды». Поэтому небольшие тесты, но максимально разнообразные вопросы, которые должны покрывать различные требования (критерии соответствия кандидата). Например, в примере из начала доклада:

  • Критерий – сотрудник должен уметь проектировать подсистемы.

  • Требование – сотрудник должен знать регистры накопления и регистры сведений

  • Соответственно, вопросы: «Чем отличается регистр накопления остатков от регистра накопления оборотов?». Или: «В регистре накопления остатков виртуальные таблицы формируются по принципу… (варианты принципов формирования этих таблиц на выбор)».

• В тесте должно быть несколько разделов – нужно обязательно спросить про код, про управляемые формы, про принципы проектирования.

• И в каждом разделе по 3-4 вопроса. В принципе, это вам даст достаточную информацию, чтобы понимать все скиллы человека, все его умения.

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

Принципы подготовки опросника

Принципы подготовки опросника:

• Лучше – открытые вопросы, но максимально точные. Например: «Расскажите ваш опыт интеграции через REST». Максимально точный вопрос.

• Также опросник лучше делать по группам, чтобы в каждой группе было по несколько вопросов. И использовать шкалу оценок – я использую шкалу 1-5.

• И здесь в опроснике очень важно использовать единую шкалу оценок. Например, вы спрашиваете кандидата: «Расскажи про твой опыт интеграции через SOAP». Если то, что он делал на предыдущем месте работы, он будет делать у меня – я ставлю оценку 5. Его опыт абсолютно валидный для меня. Если он делал что-то другое, например, у меня используются запросы GET, PUT, POST, DELETE, а он использовал только GET-запросы, то я ему ставлю 4, потому что скорее всего он с этим разберется. Если он адаптировал модуль HTTP-сервиса и сам сервис не проектировал, я ему ставлю 3.

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

Одно собеседование я запомнил на всю жизнь. Все собеседование кандидат меня поражал своими знаниями, у него стандарт ITIL «отскакивает от зубов». Мы дошли до этого раздела, я начал его спрашивать: и понимаю, что здесь что-то “не то”.

В итоге я напрямую спросил: «А чем вы вообще в жизни хотите заниматься, что вам нравится?», и он отвечает: «Мне нравится работать руками, я вечерами делаю товары для продажи через Авито. Пару лет пробовал заниматься только этим, но денег это много не приносит». Раз у человека такие интересы, это для меня означает, что он будет формально подходить к работе, ему работа нужна для того, чтобы деньги получать, он не увлечен своим делом. Тогда у нас был “старт-ап” и нужны были проактивные специалисты: кандидату пришлось отказать.

Вопросы тестов

Итак, давайте посмотрим, какие вопросы я задаю на тесте.

Я применяю такие разделы – это:

• Код

• Управляемые формы

• Запросы

• СКД

• Клиент-серверное взаимодействие.

Давайте рассмотрим несколько примеров вопросов из теста.

Например, первый пример вопроса – укажите, как используется в СУБД свойство «Индексы» таблицы значений.

Правильный вариант – d, но мне все равно, какую галку вы поставили, потому что обычно есть два варианта – те, кто сталкивался с оптимизацией кода, отвечают правильно (d), кто не сталкивался с такими задачами, отвечают b (для доступа к строке таблицы значений).

В обоих случаях мой следующий вопрос: «А для чего в принципе применяются индексы – например, СУБД?», «А какие индексы вы знаете?». Если я при этом слышу про бинарное дерево, а еще лучше про хэш-таблицу - я вопрос зачитываю. Даже если человек в этом случае поставил b, я все равно ему ставлю «плюс» и вопрос зачитываю, как правильный.

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

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

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

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

А это – моя любимая задача.

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

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

Как максимум, я хочу услышать, что можно закешировать макет компоновки данных, потому что схема компоновки данных собирается очень долго – там 90% времени выполнения уходит на то, чтобы просто собрался запрос. Или хотя бы, чтобы кандидат мне сказал, что в макете можно увидеть запрос, который уходит на СУБД для исполнения.

Дальше – как можно применять функцию ВычислитьВыражение в СКД?

Опять же, кто знает, те отвечают.

Тут гадать бесполезно, угадать сложно.

Если кандидат этого не знает (я допускаю, что кандидат не сталкивался – невозможно всего знать), я начинаю на этом вопросе дальше “копать” – применял ли кандидат функцию ABC-классификации, расчет накопительного итога и т.д.

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

Спрашиваю, можно ли в ресурсе выполнить функцию общего модуля и т.д.

Это мне дает понимание, насколько кандидат умеет архитектурно мыслить и применять компоновку данных.

Итак, выводы по подготовке тестов:

• вопросы должны иметь «двойное дно»;

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

• и очень хорошо заходят мини-кейсы.

Например, можно использовать такой мини-кейс: «Вам нужно разработать документ ввода бюджетных данных, рассчитанный на большой бюджет (1000 строк на 1000 колонок). Как вы будете организовывать клиент-серверное взаимодействие? Должен ли алгоритм ходить на сервер при изменении каждой ячейки или не должен?» Ответ кандидата даст вам понимание того, как кандидат представляет себе клиент-серверное взаимодействие между клиентом и сервером 1С.

Разделы опросника

Теперь немного пробежимся по опроснику. Как я говорил, я применяю два инструмента – это тесты и опросник.

Опросник – самый важный инструмент. Я применяю такие разделы:

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

• Опыт разработки

• Интеграцию

• Теорию объектной модели

• Моделирование

• Документирование

• Модели разработки ПО

• И личные качества – как я ранее рассказывал.

Давайте посмотрим, как выглядит опросник. На слайде мой рабочий инструмент. Я на собеседования всегда прихожу с планшетом, в котором у меня такая таблица распечатана. В колонках ФИО людей, в строках – вопросы.

• Первый вопрос – это тест. Причем, его вопросы вы уже видели. По тесту можно максимум набрать 27 баллов. Градации у меня следующие – если кандидат набрал от 8 до 12 баллов – это 3, от 12 до 18 – это 4, и выше 18 баллов – это 5.

• Дальше – опыт разработки. Разработка подсистем: «Расскажите, какие подсистемы вы разрабатывали, с какими трудностями сталкивались». И здесь я ставлю оценку не за то, что он рассказывает, а за то, насколько это подходит именно мне, именно в мою компанию, под мои задачи.

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

Другие вопросы, которые я применяю:

• Теория объектной модели. Спрашиваю: «Что есть методы, что есть свойства?» – этот вопрос помогает отсечь тех, кто пришел в нашу отрасль за “длинным рублем”, не понимая теорию, как работает код.

• Web-интеграция. Я уже приводил пример про HTTP и SOAP-сервисы.

• Задаю вопросы про смежные технологии, которые могут быть мне полезны, могут быть применимы.

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

  • Что такое управление требованиями? – здесь я проверяю, знает ли кандидат, что такое требования, как ими управлять, спрашиваю, как вы требования обрабатываете, чем требования от задачи отличаются и т.д.

  • Какие нотации моделирования могут быть? IDEF, BPMN, UML – что из этого ты знаешь, что применял и т.д.

Каждый ответ я соотношу с тем, как устроен процесс в моей компании, и ставлю оценку.

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

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

В конце я получаю некую математическую сумму, усреднение. И таким образом в конце недели после пула собеседований у меня достаточно информации, чтобы я принял взвешенное управленческое решение.

На этом у меня все. Желаю вам минимальной текучки, хороших кандидатов, и чтобы кандидаты соответствовали вашим критериям!

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Kazan.