Взять в команду семь джунов и не поседеть — чему я научилась, пока нанимала сотрудников

Привет, я Даша — QA-лид команды iOS. Им я стала полтора года назад. За это время больше всего меня впечатлил наём сотрудников. Сфера была новой и я набила в ней шишек. Из опыта удалось вывести несколько правил, которые помогли не сойти с ума от поиска, отбирать хороших джунов и обучать их так, чтобы люди оставались в команде и приносили пользу проекту.

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

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

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

Расслабляться

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

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

Ещё болезненными оказались отказы: и получать, и отказывать самой. Давать обратную связь вообще непросто — невольно боишься обидеть человека, когда говоришь, что он с чем-то не справился. Поэтому стараешься чутко относиться к тому, что пишешь в отзыве и перечитывать его глазами кандидата.

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

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

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

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

Человека, который раньше не сталкивался с такими задачами, они могут выбить из колеи. Поэтому надо расслабиться и принять факт: поиск сотрудников полон неожиданностей. Может быть тяжело и придётся учиться новому. Это нормально.

Учитывать обстановку на рынке

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

Посоветовавшись с руководителем и эйчарами, решила снизить требования: искать не мидлов, а джунов. На поиски опытного человека могло уйти ещё столько же времени и ещё не факт, что мы бы его нашли. Джунов найти чуть проще, а опыт обучения у меня уже есть.

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

Правильно выбирать канал для связи с кандидатом

Ещё один неочевидный нюанс — использование разных каналов связи с кандидатом.

Ответы на мои письма приходили медленно или не приходили вообще. Хотелось это исправить. Эйчары подсказали: ошибка в том, что я пишу на почту, а лучше писать сразу в мессенджер.

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

Но против этого у эйчаров было два аргумента. Во-первых, на почту уже почти никто не отвечает (и я тоже). Во-вторых, подросло поколение, которому по всем вопросам удобнее общаться в Телеграме. Они не разделяют сферы как раньше: рабочее — в почту, личное — в мессенджер. 

Сотрудник был нужен как можно быстрее, поэтому я решила последовать совету. Мне выдали пачку из 70 резюме джунов, и я связалась с ними через Телеграм. 

Эйчары оказались правы — кандидаты реагировали на мои сообщения без злобы и быстро отвечали. Я радовалась: даже если кандидат отказывался, лучше узнать об этом поскорее. Если бы я по старинке писала на почту, вряд ли бы получила такой результат.

Не проводить джунам встречу-знакомство

Из первых 20 кандидатов ответили 15. Каждому я назначила встречу, чтобы познакомиться и пообщаться лично.

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

Летом 2020-го года 2ГИС присоединился к экосистеме Сбера. У нас открылось много вакансий и схема найма изменилась. Эйчаров не хватало, к подбору персонала решили привлечь лидов и инженеров. Во-первых, это разгрузило эйчаров, во-вторых, общение с кандидатами улучшилось. Инженеры быстрее понимали, какой кандидат подходит конкретно им. А кандидаты охотнее общались с теми, с кем в перспективе собирались работать. Это для обеих сторон важный момент — определить, что кандидат и инженер говорят на одном языке и понимают друг друга.

Новая схема стала такой:

1. Отбор из списка. Эйчар даёт лиду список резюме, лид отсматривает их и сам связывается с понравившимися кандидатами.

2. Знакомство. Кандидат и лид встречаются на первой встрече. Технических вопросов на ней не обсуждают, просто знакомятся и общаются. Говорят о рабочих процессах и ожиданиях, чем сейчас занимается кандидат и какие задачи ему интереснее всего выполнять. Здесь оба определяют, будет ли комфортно работать друг с другом.

3. Техническое собеседование. Если кандидат и лид друг другу понравились, лид проводит техническое собеседование. На нём определяют, достаточны ли скиллы кандидата для той работы, что ему предлагают. 

4. Финальное собеседование. Если пазл сошёлся, лид назначает финальное собеседование. На нём кандидат встречается с эйчаром и руководителем тимлида. Они определяют софт-скиллы и мотивацию.

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

Новую схему обкатали при найме разработчиков и она дала классные результаты: отвечать стали вдвое чаще! Раньше конверсия составляла 1 выход к 114 написанным письмам, а когда в подбору подключили инженеров, она стала 1 выход на 52 письма. То есть кандидаты стали соглашаться на предложения о работе чаще: раньше было 0,88%, а теперь — 1,92%.

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

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

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

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

Давать второй шанс, если видишь потенциал

После встреч-знакомств я разослала кандидатам тестовые. Кто-то сделал лучше, кто-то хуже.

На знакомстве запомнилась одна жизнерадостная девушка — Марина. Сфера тестирования была для неё новой, но она осваивала всё с таким заразительным энтузиазмом! По-моему, заинтересованный сотрудник — лучшее, что может случиться с командой. Поэтому я очень ждала сделанное тестовое именно от неё.

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

Через два дня я поговорила с Мариной ещё раз. Выяснилось, что ей понравился велком и она тоже понимает, где промахнулась.

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

Финалку назначили на утро выходного: у Марины уже был на руках оффер от другой компании и нам хотелось его перебить. Я на этой встрече не присутствовала и ужасно за неё волновалась. Настолько, что даже когда поехала в магазин за продуктами, не выпускала из рук телефон — ждала звонка эйчара с результатом. Марина прошла финалку, мы сразу сделали ей оффер и закрыли вакансию.

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

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

Создавать свою базу кандидатов

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

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

Кандидаты были классными, несколько людей из этой пачки дошли до финалки. Там они, к сожалению, срезались и в нашу команду не попали. Но зато нам подошёл другой джун, из подборки хороших кандидатов другого лида 2ГИС. В ту команду он не прошёл по техсклиллам, а мы его подхватили.

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

Привлекать сотрудников к собеседованиям и проверке тестовых

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

На этот раз я решила подключить к поиску Юлю, одну из наших инженеров. Она собеседовала кандидатов вместе со мной, помогала проверять тестовые и составлять отчёты о поиске. Профит для Юли — тренировка навыков, которые не развить тестированием: давать обратную связь и умение принимать решения — брать ли кандидата в команду, как его мотивировать, как учить. Плюс когда учишь человека, вспоминаешь что-то забытое, а порой и сам учишься — ведь взгляд новичка на проблему может быть совсем другим, новым.

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

Такой подбор вошёл у нас в практику. Сотрудник, который будет ментором, идёт на встречи с джунами вместе со мной. Сейчас кроме меня в команде наставничают два человека.

К разбору же тестовых, которые раньше проверяла Юля, я подключила ещё одного инженера по качеству из нашей команды. Это ускорило проверку и ответ кандидатам. А я вздохнула свободнее — появилось дополнительное время.

Нет смысла зашиваться и тянуть всё в одиночку. От этого страдаешь сам и страдает команда. Если поделиться задачами, то пользу получат все: и лид, и сотрудники. Однажды нужно решиться и делегировать.

Итог

Сейчас в нашей команде тестирования 11 человек, включая меня. За полтора года мы приняли 7 джунов, все прижились в компании: 6 работают в нашей команде, 1 перевели в другую после адаптации под нашим менторством.

За это время команда стала сильнее. Старички прокачались как наставники, новенькие выросли профессионально: двое уже стали мидлами, остальные джуны окрепли. Думаю, что до весны и они успеют подрасти. Скоро мы опять начнём искать людей. Поэтому я рада, что получила опыт найма: знаю, что он пригодится ещё не раз.

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

Точно знаю, что я не одна такая — кто решился нанимать без опыта поиска сотрудников и кто выбирал именно джунов. Поделитесь своим опытом в комментах, интересно же!