Как тимлиду не нанять себе разработчика
В моей практике были одни проблемы с наймом. Во-первых, есть длинный цикл обратной связи между точкой, когда мы начинаем процесс поиска наших разработчиков, и точкой, когда они начинают выдавать какие-то первые свои результаты. Во-вторых, у нас, как у тимлидов, достаточно мало информации для рефлексии, ведь мы нанимаем не так много людей, только, если не растем в 2 раза за год. Как следствие, плохо понимаем, насколько классные те люди, которые по каким-то причинам отсеяли.
Примечание. Эта статья выходит от имени Александра Птахина.
Александр ПтахинНачинал в РЖД, работал в Яндексе, стартапах, руководил группой разработчиков в компании Admitad.
Привет, меня зовут Александр Птахина. В последние годы работаю как руководитель. Нанимал как тимлид разработчиков в большие компании, в стартапы, в средние компании и даже есть опыт найма в госкомпанию. Расскажу про личный опыт найма разработчиков в компании разного размера, опишу проблемы, из тех, что я видел, и подскажу, как эти проблемы усугубить (что, конечно, не является руководством к действию).
Как нанимал в корпорациях
В больших компаниях нанимают конвейером, что не секрет, конечно.
Есть скрининг HR.
Есть технический скрининг, обычно на час, где дают какие-то задачки, покодить, порешать алгоритмы.
И несколько секций технических собеседований с разными разработчиками, для большей объективности, Это достаточно растянутый этап.
В корпорация найм формализованный, не всегда этот процесс логичен и понятен. Вряд ли вам получится что-то в нем поменять. Но даже с большим, формализованным и раздражающим процессом можно что-то сделать. Под «что-то сделать» имею ввиду как-то улучшить процесс для себя и своей команды. Как это делал я? Давал на техинтервью практическую задачу, которая и про математику, и про логику, и немного про уменьшение неопределенности в работе разработчика. Пример задачи — вывести все простые числа от 1 до N.
Она хорошо работает. Здесь кандидат:
и может задать вопросы, например, уточнить термины, потому что мало кто помнит точные определения из курса математики;
и написать решение на листочке, или на ПК, или в онлайн-редакторе;
и отладить сразу.
То есть здесь мы сразу понимаем и как кандидат мыслит, и как пишет код, и как его объясняет. Можно давать задачи и сложнее, но смысла в этом я не вижу, потому что если человек в стрессе пишет какой-то минимально работающий код, то и в работе пишет так же, плюс-минус.
Что делать, если кандидат решил эту задачу? Берем — как показала практика, он и в работе молодец. А если не решил? Здесь уже непонятно, насколько они классные, потому что у нас конвейер, мы же сейчас говорим в контексте найма в большую компанию. А в ситуации конвейера мы ограничены как временем, так и критериями отбора.
Да, это печаль и это наше ограничение как тимлидов. Но для большой компании, когда у тебя сотни вакансий и тебе нужен универсальный найм, другого способа не придумать. Возможно у вас есть решение? У меня пока нет.
Как нанимал в стартап?
Всё сам.
Это был 2019 год. Стартап. Конвейера нет. Денег на московские зарплаты нет. Опыта найма удаленщиков тоже нет. Ничего нет.
Сам писал вакансию на мидл Python, сам разместил на хедхантер, сам разбирал все заявки, сам интервьюировал и отказывал, понятно, тоже сам.
Здесь ситуация абсолютно противоположна корпоративному конвейеру. Но вот здесь-то можно развернуться и нанимать «по нормальному», как положено? А начать можно с текста вакансии — не так, как HR, а по-человечески, верно?
Так как я нанимал в стартап, то обнаружил, что корпоративные штампы вроде «молодой, дружный коллектив с офисом, кофе и печеньками» не работают. Это информационный шум, который кандидаты пропускают точно так же, как мы пропускаем в резюме слова «коммуникабельность» и «стрессоустойчивость». Такие вещи снижают уровень доверия ко всему остальному тексту.
Как же тогда писать? Я пошел от обратного и признавался в недостатках. «У нас на проекте сейчас нет тестирования, у нас кодовая база не в самом лучшем состоянии, но мы готовы тратить на это время, чтобы исправлять и вместе с бизнес-задачами двигаться дальше». А иначе никак — штампы в корпоративных вакансиях прощаются за счет зарплаты. Стартап так писать не может.
А еще это было полезно мне, как тимлиду. Пока описываешь недостатки работы сразу формулируется конкретное описание того, кто мне нужен с точнейшим списком обязанностей и задач.
Дальше разместил вакансию на хедхантер и в Фейсбуке. Что интересно, фейсбук не сработал. Аудитория была нерелевантной, а я не состоял в комьюнити и даже не осознавал, что это, на самом деле, очень ценно. Какие-то каналы вроде удаленщиков репостнули запись, но никакого выхлопа не было.
В итоге сработал хедхантер. Повозился я, конечно с хедхантером, разбирая отклики кандидатов с опытом 1–3 года, но всё же нашел того, кто мне нужен. Нанятый мной кандидат (предыдущий пункт) не решил задачу полностью на собеседовании, но я его взял — за софт-скилы. И был готов ждать, пока он подтянет харды. Это сработало. Вряд ли у меня бы получилось это сделать в корпорации.
Справедливости ради скажу, что он всё же прислал мне решение уже после интервью. И да, так можно было — у нас же не экзамен.
Как нанимал в компании среднего размера?
На примере последней компании, где я работал.
Начнём с ошибок.
Мы давали тестовые задания, если возникали сомнения и там, где мы можем профильтровать. Не все соглашались его делать — чаще соглашались джуны, остальные гораздо реже. Этим, кажется, мы просто срезали свою воронку найма и удлиняли найм тех, кто нам нужен.
С обратной связью тоже было слабовато, что тоже роняет мнение о компании.
В Admitad три этапа собеседований: технический скрининг на полчаса, техническое интервью на 1,5 часа и финальное интервью. И это долго — люди получают оффер от конкурентов быстрее, чем мы проводим интервью.
Воронка для средних компаний должна быть полегче — примерно 70% кандидатов проходили наш скрининг и только 10% добирались до финала (по статистике 20–30 интервью).
Скрининг фильтрует людей не так, как хотелось — скорее отсеивает.
Что делать? Стали проводить поэтапные эксперименты.
Сначала сменили текст вакансии, который был написан не так хорошо.
Начали сводить 3 интервью в 2 этапа — без скрининга и тестового сразу на техническое собеседование, чтобы было быстрее и мы сразу могли понять, умеет ли человек делать то, что нам нужно или нет. Здесь еще помогает «предупреждение»: зовем на техническое собеседование, но предупреждаем — «Ребят у нас встреча пройдет часа полтора, будьте готовы, но мы можем закончить и пораньше».
Уже эти два действия сильно улучшили ситуацию. Естественно, улучшения проходили итеративно — запланировали эксперимент с форматом, что-то поменяли, провели «опыты», проанализировали результат, всё заново. Обычный PDCA:)
Итого: вредные советы
Оглядываясь назад я понял, как испортить найм.
Шаблонный и скудный текст вакансии.
Код без возможности запуска на собеседовании.
Длинные тестовые задания.
Больше этапов собеседований, особенно нужен скрининг.
Между этапами нужно как можно больше времени.
Срочно менять текущий процесс, потому что-то кто-то об этом написал в статье или рассказал на конференции.
Все это ухудшит наше положение.
Ну, а чтобы такого не было, я сейчас постоянно «влезаю» в рекрутерские процессы, потому что опыт мне говорит, что ну не получается нанять хорошего человека без личного участия. Ну никак. Хочешь человека в команду — не отдавай найм на откуп.
Минутка рекламы: если ищете разработчиков — переходите на headz.io, AI-сервис подбора, который экономит, в среднем, до 40 часов сорсинга.
