Предисловие

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

Начало карьеры управленца

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

Все ребята в нашей команде были амбициозными и настроены на успех, и мы быстро начали расти. В начале работы в IT-отделе нас было 4-5 человек, включая меня, а на пике штат отдела достиг 30 человек. При этом стоит учитывать, что по ходу развития от IT-отдела отделились два других — техническая поддержка и отдел ОТК, формированием которых тоже занимался я.

Цели стояли грандиозные: нужно было создать эффективный IT-отдел, способный быстро разрабатывать продукты, соответствующие требованиям рынка, а также заниматься разработкой программного обеспечения на заказ.

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

О наличии специалиста по найму, рекрутера, тогда никто не думал, и все занимались этим своими силами.

Вакансии размещались на HH. Помню, тариф был самым дешевым, и постоянно приходилось манипулировать размещёнными объявлениями: то одну вакансию размещал, то другую.

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

• Прочитал множество статей, на тот момент видео на YouTube по этой теме почти не было;

• Немного поспрашивал более опытных коллег в IT;

• Подготовил около 30–40 вопросов;

• Гордо распечатал их и прикрепил к планшету.

С энтузиазмом начал проводить интервью.

Какой процесс найма был у нас на тот момент:

1. Я размещал вакансии на HH.

2. Просматривал всех кандидатов.

3. Приглашал подходящих приехать на интервью в офис (тогда никто из нас не думал о удалённой работе).

4. QA, ассистентов, Ops-инженеров (тогда мы их просто называли админами) я полностью интервьюировал сам.

5. Для разработчиков мы с инженерами подготовили вопросы по каждой специальности.

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

Затем мы принимали решение, и я шёл к директору согласовывать кандидатов.

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

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

Прогресс

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

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

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

Необходим рекрутер.

Нужно было быстро обучить ассистента до уровня руководителя проектов. Если это не удастся, придётся нанимать нового сотрудника (впоследствии мы наняли одного РП и одного из разработчиков переобучили в РП).

Мы наняли рекрутера, и наш процесс найма значительно улучшился (это был 2016 год).

Изменения после найма рекрутера:

• Мы наконец-то приобрели хороший пакет услуг от HH, что позволило нам размещать много вакансий.

• Рекрутер совместно со мной и инженерами составлял вакансии.

• Рекрутер вел коммуникацию с кандидатами.

• Потенциально подходящих кандидатов направлял ко мне и инженерам.

• Он приглашал кандидатов на интервью и проводил первую часть (HR-интервью) длительностью около 30 минут.

• Если по мнению рекрутера кандидат подходил, я подключался к интервью и проводил свою часть.

• Если нужен был инженер, мы сразу его приглашали.

Таким образом, интервью могло включать в себя HR-часть, техническую часть и финальное интервью.

После этого мы с рекрутером и инженерами принимали решение о кандидате. Я и рекрутер согласовывали кандидата с директором. После этого рекрутер отправлял кандидату оффер.

Что это дало:

• Я разгрузился и мог сосредоточиться на проектах и продуктах.

• Рекрутер сразу отсеивал неподходящих кандидатов, и мне не приходилось тратить на них время.

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

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

Завершение пути длиною в четыре с половиной года

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

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

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

• Я обучил одного из коллег, руководителей проектов, проводить интервью.

• Мы разделили деятельность отдела на две части: продуктовую и заказную. Для основного продукта был нанят опытный руководитель проектов, которому я передал функцию найма сотрудников под этот продукт.

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

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

Чем закончилась моя деятельность в этой организации:

• Был сформирован IT-отдел, разделенный по секторам бизнеса компании. Его численность на тот момент составляла около 30 человек, а общая численность сотрудников компании составляла 200 человек.

• Создан отдел технической поддержки, в котором работали 3 человека.

• Организован отдел ОТК, где работал один постоянный сотрудник.

Простыми словами, у нас был боевой отдел с пост-релизной поддержкой и ОТК продукции перед выходом к заказчику.

Новое начало

Летом 2018 года я начал работать в сервисной компании, занимающейся разработкой программного обеспечения под заказ, на должности руководителя проектов (РП). Компания была больше, чем предыдущая, и специализировалась исключительно на разработке ПО, без включения разработки аппаратных комплексов.

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

Как выглядел процесс найма:

1. Рекрутер составляет заявку на основе запроса на найм от проектного офиса.

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

3. Рекрутер запрашивает скрининг у нанимающих экспертов.

4. Рекрутер проводит HR-часть собеседования с кандидатом, используя скрининг.

5. Вся деятельность ведется в системе HF (Huntflow).

6. Рекрутер оставляет обратную связь и отправляет кандидата на валидацию экспертам.

7. Одобренным экспертами кандидатам назначается техническое интервью (ТИ).

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

9. Кандидат отправляется на валидацию руководителю проектного офиса (РПО) и СТО.

10. Один из них проводит финальную часть интервью и также оставляет обратную связь в HF.

11. После всех интервью рекрутер отправляет письмо с предложением согласования оффера на СТО и РПО.

12. После согласования рекрутер делает оффер кандидату.

Новая должность

Летом 2020 года ситуация изменилась. Было принято волевое решение о переходе к более прогрессивному пути развития IT-компании, в результате чего проектный офис как отдельная единица прекратил существование. РП были переведены в отдел разработки и стали частью производственного персонала. Меня, как специалиста, способного гибко адаптироваться к изменениям, назначили на должность Ресурсного Менеджера (РМ).

В мои обязанности входило:

• Проведение всех финальных частей интервью.

• Распределение инженеров по проектам с учетом их желаний и способностей.

• Совместная работа с HR и РП по решению проблем инженеров на проектах.

• Принятие решения по найму кандидатов.

• Проведение онбордингов в отдел разработки.

• Увольнение сотрудников.

• Подготовка инженеров к новым проектам.

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

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

В этой должности я проработал еще полтора года, но, как я уже писал ранее, ничего не бывает вечно.

Финальная часть моего пути

Осенью 2021 года компания пришла к выводу, что для следующего шага необходимо провести изменения. Был организован деливери-офис и наняты Деливери Менеджеры (ДМ), на которых, в основном, перешла ресурсная функция по управлению сотрудниками в рамках их портфелей.

А я куда? У меня появилась новая должность, и по сей день, 14 декабря 2024 года, я занимаю позицию HofSM — Руководитель Стек Менеджеров (ведущие инженеры специализаций).

Мои основные задачи:

• Организация части найма со стороны отдела разработки: актуальные скрининги, опросники и лайфкодинги по всем стекам (у нас их 10), формализация обратной связи как технической, так и общей для принятия решения и присвоения грейда кандидату. Контроль за качеством написания обратной связи.

• Организация обучающих мероприятий и ИПР для сотрудников стеков совместно с Центром профессиональных компетенций.

• Организация технической движухи в каждом стеке: проведение и организация встреч стеков совместно с менеджерами стеков (СМ).

• Организация проведения 1-на-1 встреч инженеров с СМ.

• Помощь ДМам в подборе персонала на проекты.

• Совместно с HR, СМ и РП решать проблемы производства.

• Введение должности Бенч-Менеджера (БМ), моя задача — быть руководителем БМ.

• Участие в процессе увольнения сотрудников.

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

Что важно отметить в части найма:

• Скрининг постоянно модернизируется. Сейчас для найма джунов и миддлов в ряде стеков проводим онлайн технический опрос на 10 минут с установленным проходным баллом. Этот подход уже зарекомендовал себя как успешный.

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

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

Что касается моего проведения интервью:

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

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

2. На каких стадиях SDLC могут находиться QA специалисты, а на каких — QC специалисты? Чем отличаются QA и QC? Почему большинство кандидатов, указывающих в своём резюме, что они QA, на самом деле ошибаются?

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

Кому понравились мои мысли — заходите в мой TG канал: https://t.me/Lazzy_IT