Как найти идеального кандидата, и что делать с неидеальными
Поиск, подбор и найм новых сотрудников — практические советы для тимлида
Привет, Хабр!
На связи Андрей Рыжкин, CTO AGIMA. В нашей компании более 30 команд разработки, и у каждой свой тимлид (или несколько). Людей много, а значит, их нужно нанимать, развивать, мотивировать, а иногда — расставаться с ними. Работа с людьми на мой взгляд — это одна из важнейших и при этом самых сложных функций тимлида или технического руководителя. Эта статья — об одном из аспектов этой работы: о том, как искать и нанимать разработчиков. В основе материала мой контент для курса «Руководитель команды разработки», а также мой опыт за весь карьерный путь от разработчика до CTO.
Дисклеймер
В данной статье я описал только те вещи, в которые верю сам или верят в нашей компании и которые я разделяю. Ни один из тезисов не претендует на звание абсолютной истины или аксиомы, а всего лишь иллюстрируют, что хорошо сработало в тех командах и компаниях, где мне посчастливилось поработать. Я допускаю, что в других условиях и ситуациях каждый совет в отдельности может не принести ощутимой пользы.
Почему тимлиду нужно участвовать в найме
Для начала хорошо бы пояснить, почему я считаю, что тимлид вообще должен участвовать в найме сотрудников глубже, чем просто проводить собеседования и реагировать на запросы от HR.
Я часто встречаю мнение, что «наймом должен заниматься кто-то другой»: HR, рекрутер, техдир, вышестоящие руководители и так далее. Вроде если для этого есть целые отдельные департаменты и людям там за это еще и платят, то зачем делать двойную работу?
Я разделяю процесс найма на две части.
Первая часть, которой занят только специалист по кадрам (сбор подходящих резюме с площадок, первичный контакт с кандидатом, размещение вакансий, отсмотр откликов и т. д.) — этой части я касаться практически не буду.
Вторая часть, которой может заниматься и кадровик, и заказчик вакансии (составление профиля, анализ причин провалов при найме, оптимизация процесса и т. д.) — про это пойдёт речь.
Первую часть логично возложить на профильных специалистов, а второй очень часто просто пренебрегают или вообще не занимаются. Хорошо, когда это не так, но в любом случае тимлид должен понимать, как этот процесс устроен и какие бывают приемы, чтобы, если вдруг что-то идет не так и нужный кандидат всё никак не находится, иметь возможность на это повлиять, а не ждать, когда подходящие условия сложатся сами собой.
Как я дошел до жизни такой
Мое первое желание пойти поразбираться, «почему найм идет так долго», возникло не от излишка свободного времени, а совсем наоборот. Мы с моими ребятами из команды часто сидели допоздна, пытаясь разгрести весь тот вал задач, который у нас копился, попутно стараясь гасить техдолг и пробовать новые подходы. Всё это происходило из-за нехватки пары разработчиков, найм буксовал (собеседований было много, но что-то не клеилось), техдир был и сам занят выше крыши, а мы не привыкли отступать перед трудностями и фигачили за себя и за того парня.
Некоторые из нас со временем стали выгорать: решение простых багов растягивалось на дни вместо пары часов, опоздания стали нормой (у меня не поднималась рука говорить что-то на эту тему человеку, который вчера ушел с работы в 11). В какой-то день один из моих сотрудников не выдержал напряжения и пришел ко мне с заявлением на увольнение. «Браво! — сказал я себе. — Теперь нам не хватает уже трех разработчиков». Стало очевидно, что надо что-то менять, иначе я рискую выжечь всю команду и себя в придачу.
Нет человека — есть проблемы
С этого началось мое осознание простого факта: если у меня, как у тимлида, не хватает сотрудника, то это в первую очередь моя проблема. Мой рефакторинг будет задвигаться, моя команда будет гореть, мне надо будет придумывать, как обойтись без нужных компетенций, и так далее. А для HR я всего лишь один из заказчиков: у них свои kpi, которые они могут закрывать и на других вакансиях.
Круто, когда можно просто сдвинуть сроки по проекту и подождать, когда мы доукомплектуем команду, но мой опыт общения с разными бизнесами показывает, что обычно ситуация этого не позволяет, и принимается решение сделать, «как получится», а «потом допилим». Конечно, это «потом» частенько так и не наступает.
Именно поэтому я считаю, что тимлиду иногда нужно влезать в чужую зону ответственности и полезно понимать, как устроены процессы по ту сторону найма. Из этого, конечно, не следует, что надо целиком взять найм на себя, но знание таких аспектов позволит сократить уровень напряженности у себя и своей команды.
Быстрый скоринг, или Чек-лист для HR
Что не так с текущей схемой
Первоначально процесс найма выглядел у нас так:
техдир инициировал поиск сотрудника в команду, или же тимлид приходил к техдиру с таким запросом;
HR снимал с нас требования к позиции;
HR формировал и аппрувил у нас вакансию;
HR по каким-то своим алгоритмам собирал нам резюме и приносил на отсмотр;
тех, кто нас устраивал, мы помечали как «годных», и HR приглашали их на собеседование.
Рабочая схема, но, посмотрев на трек времени своей команды, я увидел, что на собеседования мы тратим очень уж много времени, а выхлопа как такового ноль.
При этом немалая часть кандидатов «срезалась» в самом начале собеседований: им не хватало необходимых навыков, хотя в резюме они были отмечены. Сами понимаете, после первых трех минут разговора сказать кандидату, который ехал к тебе через весь город, что собеседование окончено — это невежливо. Поэтому зачастую мы проводили остаток собеседования «для галочки» и напрасно жгли время — свое и кандидатов.
Первое, что мне захотелось сделать, уменьшить процент таких кандидатов, которые не подходили нам на базовом уровне. Мы с командой составили 5 коротких вопросов, которые попросили задавать кандидату в момент обзвона HR«ом.
Вот пример для нашей тогдашней вакансии PHP-разработчика:
Нормально ли относитесь к перспективе работать и в бэкенд, и частично во фронтенд?
Приходилось ли писать коммерческие проекты на symfony за последний год?
Какие вообще фреймворки на PHP использовали на коммерческих проектах?
Был ли опыт работы с Bootstrap?
Приходилось ли работать с Gitflow?
Теперь HR приносил нам резюме с ответами на эти вопросы, а мы по набору ответов уже могли отсечь тех, кто нам точно не подойдет.
Конечно, первый наш набор вопросов выглядел не так однозначно, и пока мы его тюнили, выявили несколько правил, которым каждый вопрос должен соответствовать. О них ниже.
Правило №1. Вопрос должен быть сформулирован так, чтобы ответ укладывался в формат «да/нет» или простое перечисление. Вопрос исключает уточнения, диалог или размышления
Все варианты, когда кандидат может задавать уточняющие вопросы или начать пространные размышления, зло, так как, во-первых, HR может их неверно интерпретировать (или принесет очень длинный конспект ответа), а во-вторых, на уточнения HR может и не ответить правильно. Ну и в-третьих, такой ответ будет отнимать слишком много времени, что вредно для первого касания с кандидатом.
Плохо: «Знаете ли вы SQL?» — у каждого кандидата может быть свое представление об ответе на этот вопрос. Возможно, человек работал с БД через phpmyadmin и уверен, что этого достаточно.
Хорошо: «Был ли опыт написания запросов в MySQL с составными индексами? Шардирование? Репликация?» — сразу получаем понимание по нужным нам нюансам.
Правило №2. Вопросов не должно быть много
Запихивать всё собеседование в формат телефонного опроса — плохая идея. Во-первых, кандидату может быть неудобно или не охота тратить кучу времени на эти ответы. Во-вторых, связь может прерваться по разным причинам. В-третьих, некоторые вопросы лучше оставить на собеседование, чтобы там раскрыть их полностью.
Мы воспользовались правилом 5±2. Обычно нам хватало трех вопросов, иногда это число вырастало до 5-ти, редко — больше.
Правило №3. Вопросы сформулированы так, что любой HR (даже тот, который не в курсе технологий или проекта) может их задать
Тут всё просто: не надо надеяться, что HR погрузится в предметную область настолько, чтобы понимать вас с полуслова. Хорошо, когда он не постесняется помучать вас достаточное время, чтобы не упасть в грязь лицом перед кандидатом, но может получиться и так, что он добросовестно пойдет пытаться делать как понял, и это выйдет для вас боком.
Плохо: «Узнай, работал ли он с высокими нагрузками». Может, у кандидата был написанный через пень-колоду сайт без индексов и с циклическими запросами в БД, который падал от 5-ти одновременных посетителей, и это он считал высокими нагрузками («а что, сервер же не выдерживает!»). HR из его ответа этого не поймет, а корректно уточнить не всегда сможет.
Хорошо: «Был ли опыт разработки сервиса с более, чем 500 RPS или 3 млн уникальных посетителей в сутки?» Подставляем наше виденье нужной нагрузки и получаем конкретный ответ.
Правило №4. Не все вопросы обязаны быть отсекающими
Мы обычно формулировали список вопросов, миксуя обязательные пункты (must have) и желаемые (nice to have). Такой подход давал нам возможность не просто узнать, что человек пройдет первичный фильтр, но и вместе с другими данными взвесить, насколько нам интересно общаться именно с этим кандидатом.
Это отчасти помогло: количество ненужных собеседований сократилось, и мы выиграли немного времени для остальной работы, но желаемого результата (получения большего количества подходящих кандидатов) мы не достигли.
Профиль кандидата
Рассинхрон и потеря времени
Так как работы у нас было много, а сотрудник был очень нужен, то собеседованиями занимались почти все разработчики нужного уровня из команды. Иногда это делал я, часто (когда у меня горел релиз или были важные внезапные планерки) я просил своих ребят провести собеседование за меня. Бывало также, что я просил техдира или кого-то из другой команды прособеседовать специалистов, чтобы не упускать время. Главное, как я думал, это побыстрее пообщаться с кандидатом, пока он не принял чье-нибудь другое предложение о работе.
Иногда ребята браковали кандидатов, которые по резюме мне казались достаточно сильными, или, наоборот, предлагали сделать предложение кому-то, у кого отсутствовали навыки, без которых я не готов был брать человека в команду. Мне начинало казаться, что в этом процессе у нас очень много субъективных решений, я напрасно трачу время своих ребят на собеседования (если потом все равно принимаю другое решение) и надо как-то синхронизироваться.
Синхронизация и утверждение требований
Я решил создать некий профиль кандидата в нашу команду и согласовать его на уровне всех собеседующих. Это решение оказалось классным: уже на первой его версии мы сделали достаточно много открытий для себя.
Так, например, я знал, что новый человек обязательно в первую очередь будет заниматься работой с биллингом и ему надо будет знать SOAP & REST, а кто-то из моей команды считал это не таким важным, т.к. сам этого функционала почти не касался и работал на другом участке. Некоторые аспекты я сам упустил из фокуса внимания, а мои коллеги обратили на это внимание. Например, на собеседовании им часто задавали вопросы о перспективах карьерного роста, и они отвечали по своему усмотрению, которое иногда могло не отражать полной картины. В результате наш оффер выглядел менее привлекательным.
Через много итераций допила шаблона профиля и раскатки его на всю компанию мы получили несколько общих требований к такому документу.
Требование №1. Документ должен содержаться служебную информацию
Иногда бывало так, что собеседование мог проводить человек, который плохо знал специфику конкретной команды, проекта или должности, но мог хорошо проверить технические навыки. При этом на самом собеседовании кандидат мог задавать вопросы о будущей работе, а собеседующий не на все мог ответить, что выглядело не очень хорошо и попахивало бюрократией («Зачем ты меня собеседуешь, если даже не знаешь, чем я буду заниматься!»).
Чтобы устранить эту проблему, мы добавили в шаблон блок со служебной информацией.
1. Должность
«Разработчик» — плохо. «PHP-разработчик» — лучше.
«Middle PHP-разработчик» — хорошо!
Такая информация сразу позволяет задать нужный контекст для того, кто проводит собеседование и исключить домысливание.
2. Команда (коллеги, подчиненные)
Практически любого кандидата интересует, с кем ему предстоит работать. Будут ли подчиненные (какие и сколько), что за коллеги будут его окружать? Тут тоже были баги: кто-то писал «команда биллинга» и этим ограничивался. Но бывало так, что собеседующий не помнил или не знал, сколько там людей и какие у них роли. Поэтому мы попросили писали более конкретно.
Команда биллинга (7 человек):
1 teamlead
1 frontend (react)
2 backend (python)
1 devops
2 QA (manual + auto)
3. Руководитель и наставник
Кому кандидат будет непосредственно подчиняться после выхода на работу, какая иерархия руководства, будет ли у него закрепленный за ним наставник. Мне, как кандидату, безусловно, важно, с кем я буду чаще всего общаться и перед кем отчитываться. Поэтому, если кандидата собеседует кто-то другой, важно это подсветить, чтобы не было обманутых ожиданий. А чтобы проверить «химию», чаще всего нужна короткая повторная встреча.
4. Оклад, премия
Когда оклад написан только в вакансии, а у собеседующего с собой только профиль, иногда получался конфуз. Поэтому мы решили эту информацию хранить и в профиле тоже.
Вопрос премий важно не упускать, ведь это наша допценность: возможны ли премии, от чего они зависят и как часто бывают. Если премий не предусмотрено, это тоже ок. Главное — не формировать ложных ожиданий.
5. Возможность карьерного роста
Люди (в основном) выбирают то место работы, которое, помимо прочих важных критериев, будет их развивать. Поэтому нужно иметь возможность им рассказать, какие есть перспективы: что нужно, чтобы перейти на следующие грейды, дорасти до наставника или тимлида, какие вообще ветки развития перед ним открываются и как мы с этим помогаем — составляем индивидуальные планы развития или еще как-то.
6. Оценка эффективности/KPI
По каким критериям в команде отслеживается эффективность? Есть ли какие-то метрики или показатели, по которым оценивается сотрудник, будут ли у него конкретные ключевые цели, или всё зависит от субъективного мнения тимлида? Любой ответ, который отражает нашу объективную реальность, правильный. Наша задача здесь — рассказать кандидату, что мы от него ожидаем.
Требование №2. Hard skills
Тут всё просто: разделенный на два блока топик, который содержит в себе «обязательные требования» (must have), которые надо знать сразу при выходе, и «будет плюсом» (nice to have), которые можно подтянуть уже в процессе.
Здесь важно, чтобы каждый пункт был написан однозначно.
Плохо:
Linux;
PHP;
MySQL.
Хорошо:
Linux: базовый CLI / администрирование ubuntu;
PHP: массивы, переменные, циклы, основные паттерны / многопоточность, профилирование;
MySQL: CRUD / составные индексы и шардирование.
В случае с «хорошим» примером я точно знаю, на каком уровне мне стоит проверять кандидата. Иначе разброс может быть очень большой.
Требование №3. Soft skills
Самый сложный с точки зрения конечной эффективности блок. Тут целых две больших проблемы.
Во-первых, часто люди, заполняя его, попадают в ловушку собственного восприятия и пишут сложные вещи одним buzzword. Или забывают о том, что документом будут пользоваться их коллеги, у которых восприятие этого слова может быть совсем другим.
Плохо:
системное мышление (для меня это уметь строить диаграмму взаимодействий и умение декомпозировать задачу, для кого-то другого — вычленять тезисы из большого объема текста);
желание учиться («Человек учится играть на скрипке — можно ставить галочку!»);
Коммуникабельность («Поболтал со мной про сноуборд — коммуникабельный!»).
Хорошо:
желание изучать технологии A, B, C;
умение работать с большим объемом данных, вычленять главное;
навык проведения публичных презентаций перед большими аудиториями / умение отстаивать свою точку зрения / грамотная речь.
Вторая большая проблема — это как выбрать подходящие скиллы? Вводишь в поисковик soft skills и получаешь сотни таких (кажется) полезных buzzwords, и все такие нужные! Хочется просто скопипастить их все!
Мы добавили в шаблон два простых вопроса-подсказки:
Что помогает моим текущим сотрудникам хорошо выполнять работу? (ответственность, умение управлять ожиданиями других)
Что мешает моим текущим сотрудникам хорошо выполнять работу? (дисциплина, плохое управление собственным временем)
Они позволяют сфокусироваться именно на том, что действительно важно для моей команды или роли, и выписать только нужные навыки.
Требование №4. Общие требования к кандидату
Иногда у команд были требования, которые не запихнешь ни в hard skills, ни в soft skills. Этот блок как раз для таких пунктов. Иногда он оставался пустым, и это ок. Мы использовали его только тогда, когда требовалось что-то специфическое.
Например:
опыт работы в похожей отрасли от Х лет;
определенные сертификаты;
удаленность (надо обязательно присутствовать в офисе, находиться в том же городе, чтобы иметь возможность приезжать иногда, или должность допускает полную удаленку);
и т. д.
Требование №5. Зона ответственности
Хорошо бы описать, чем кандидату придется заниматься на своем новом месте и за что он будет отвечать. Может, это саппортные задачи, а может, развитие алгоритмов рекомендательных систем, рефакторинг старого модуля, верстка сайтов или проектирование архитектуры вперемешку с нагрузочными тестированиями.
Чем больше конкретики, тем лучше. От этого напрямую зависит, насколько кандидату будет с нами по пути.
Зачем еще нам нужны все эти требования
Каждое из этих требований, помимо облегчения задачи собеседующему, решало еще одну задачу: правильное управление ожиданиями кандидата. Иногда бывало так, что человек выходил к нам на работу, но быстро понимал, что то, чем ему приходится заниматься, ему не по душе.
Нужно понимать, что это означает просто огромное количество потерянного времени: мы зря делали оффер, ждали выхода сотрудника, тормозили поиск и тратили время на онбординг. Теперь всё придется начинать заново! Лучше, если такие вещи отсекаются еще на этапе собеседования.
Причем важно рассказывать всё как есть, не приукрашивая. Я до сих пор помню случай, когда я собеседовал разработчика, но он тогда выбрал другую компанию. Спустя неделю он спросил, актуально ли еще мое предложение. Когда он вышел к нам, я спросил его, что его заставило за неделю переменить свое решение. Оказалось, что на собеседовании в той компании ему рассказывали про большую команду крутых специалистов, а по факту он работал в паре с джуниор-разработчиком, учиться было особо не у кого, а остальные разработчики были на других проектах и недоступны. Очевидно, ожиданиями кандидата там не поуправляли как следует, и время они потратили впустую.
Чек-лист профиля
Последняя ловушка, о которой хотелось бы предостеречь, это попытка сделать идеальный и исчерпывающий профиль кандидата.
Не стоит тратить на это лишнее время. Как бы долго мы его ни составляли, всё равно придется дорабатывать: изменятся приоритеты, после некоторых собеседований станет понятно, каких требований не хватает или от каких можно отказаться и т. д.
Мы периодически актуализируем профили и сделали для этого несколько проверяющих вопросов:
Возникают ли у HR / других собеседующих проблемы при общении с кандидатам? Можно ли этого избежать, доработав профиль?
Часто ли HR уточняют у меня какие-то данные по данной вакансии? Стоит ли мне отразить их в профиле?
Все ли причины, по которым мы отказали последним кандидатам, действительно были учтены в качестве требований в профиле?
Было ли что-то важное, что обсуждалось с кандидатом на собеседовании, но не отражено в профиле?
Когда мы с командой согласились, что профиль нас устраивает, и стали обращаться к нему на собеседовании, проблема с рассинхроном ушла. Не знаю, благодаря ли этому, или просто звезды так сложились, но нам удалось найти сразу двух подходящих кандидатов, из которых оба приняли наше приглашение. Это была победа.
Что не так с вакансиями
Дальше процесс чуть притормозился: казалось, к нам просто не откликаются нужные люди. Тогда мы решили обратить внимание на вакансии.
Про них я много писать смысла не вижу: уж про это точно существуют тонны материалов более глубокой степени проработки, чем могу написать я сам. И мы вроде и так уже неплохо помогли коллегам из HR в этом вопросе, когда делали профиль кандидата.
Но есть буквально пара нюансов, о которых хочется рассказать и которые позволили мне чуть подтюнить количество и качество откликов.
Нюанс №1. Вакансия совпадает с профилем кандидата
Я обязательно проверяю, чтобы все важные пункты из профиля кандидата были отмечены в вакансии. Это позволяет сократить воронку неподходящих кандидатов, увеличить количество релевантных откликов и убедиться, что исполнитель (HR) учел все требования заказчика (т. е. меня и моей команды). Заодно позволяет мне не тратить много времени на отсмотр вакансий: открыл профиль, открыл вакансию, сверил — профит!
Если так не делать, то бывает очень обидно, когда в профиле всё детализировано и понятно, а в вакансии — поверхностно. Иногда начинаешь анализировать, почему у нас так мало откликов, и оказывается, что просто забыли перенести данные из профиля (где они расписаны круто и понятно) в вакансию (где опять пролезли все эти «django, linux, GIT, стрессоустойчивость, молодой коллектив и интересные задачи»).
Или, наоборот, в вакансию запихали столько всего, что получился супермен (должен уметь всё на свете). Смотришь на такую вакансию и с грустью понимаешь, что сам бы не откликнулся.
Нюанс №2. Не только мы выбираем кандидата, но и кандидат выбирает нас
Иногда мне на согласование присылают тексты вакансий, которые выглядят ну уж слишком пафосно: очень много написано про наши регалии и про то, какие мы крутые. Но совсем мало написано про то, что действительно важно для кандидата: зарплата, какой стек у команды, куда его приглашают, с кем придется работать и чем заниматься.
Всегда стоит помнить, что вариантов у кандидата действительно много, и наша задача (прежде всего) — рассказать ему про возможности, которые он получит при работе с нами: описать наши допценности в первой (материальной) потребности вроде всяких ДМС, оплачиваемого обучения и конференций, воркшопов, премий, белой зп и т. д. А уж потом добавить синтаксического сахара и нематериальные плюшки.
В этом плане мне кажется реально выигрышнее смотрятся те вакансии, где честно рассказывают про свои плюсы и минусы («У нас много легаси, но есть план по рефакторингу, и мы уже приступили к его реализации, надеемся найти человека, которому не будет зазорно копаться в лапше кода из PHP+HTML и переписывать всё это на аккуратненький Go в связке с React»).
Нюанс №3. Убирайте всё лишнее
Иногда у кого-нибудь из команды могут прорезаться писательские амбиции, или он начнет проецировать свои розовые мечты на нового кандидата. Такой человек может написать очень много лишних букв или добавить в требования что-нибудь вроде «быть готовым отвечать за все результаты команды, обладать хорошим чувством юмора и любить играть в покер».
Хорош! Мы же приглашаем его писать код и делать проекты, а не тусоваться. Понятно, что токсичных ребят следует отсекать, но для этого не обязательно любить играть в покер и знать кучу анекдотов, это проверяется по-другому. Я допускаю, что есть команды, для которых недопустимо работать с людьми, которые не всецело разделяют их интересы. Но на мой взгляд, это редкость и не совсем про бизнес. Тезис «отвечать за все результаты команды» без контекста вообще может зародить во мне лишние сомнения: «Возможно, там ищут нового козла отпущения взамен уволенного. Или что, кроме меня там некому ответить перед руководством? Пойду-ка я пока по другим вакансиям пооткликаюсь».
Заключение
Найти хорошего кандидата — непростая задача, и я верю, что даже увеличение эффективности найма на 5% — это уже победа. Здесь я постарался агрегировать самые эффективные (с точки зрения трудозатрат и выхлопа) приемы, которые сам применяю. Надеюсь, кому-то они покажутся интересными и помогут подтюнить найм в своей команде.
Если статья покажется интересной аудитории Хабра, я с удовольствием напишу вторую часть про дальнейшие этапы оптимизации найма: собеседования, отказы, кадровый резерв, аналитику по подбору, онбординг и прочее.
P.S. По тексту статьи может показаться, что, несмотря на мои слова вначале статьи о том, что тимлиду не надо брать на себя всю ответственность по процессу найма, он всё-таки должен это делать, иначе бестолковые HR всё завалят. Это не так: хорошие HR существуют, и они сами лучше нас знают, как и что делать, сами поправят процесс и оптимизируют наши действия, если это потребуется. Но на моем пути встречались разные HR-специалисты (как и разные тимлиды), поэтому этот текст родился как попытка сделать так, чтобы мы (тимлиды и другие техруководители) не зависели от условий, в которых окажемся, а могли сами влиять на происходящее.
А еще 24 августа в 18:00 выступаю с докладом на эту тему, приходите послушать.
