
Зачем CTO в команде рекрутеров
Клиенты привыкли видеть в агентстве десятки рекрутеров, но никак не разработчика. CTO рядом с рекрутерами выглядит диковинкой. По крайней мере, пока вы не почувствуете эффект на собственном найме. Именно техническая экспертиза превращает хаотичный поиск в четкий процесс: меньше пустых интервью, более быстрые оффера, более релевантные кандидаты. И экономия в тысячи долларов.
В этом интервью Николай Клестов, CTO ITExpert, делится историей, как из собственного опыта выросла идея подключить экспертизу разработчика к команде рекрутеров и как именно эта роль меняет скорость и качество найма для международных IT-бизнесов.
Как появилась эта позиция в рекрутинг-агентстве?
История началась еще задолго до ITExpert. Тогда мы занимались внутренним наймом в собственный продукт — и быстро почувствовали, насколько непросто найти людей не «под тайтл», а под конкретные задачи. Для предпринимателей на этапе MVP рекрутинг — сплошной хаос: требования размытые, кандидаты случайные, а процесс изнурял и команду, и бизнес.
Когда позже появилась агентство, этот опыт помог сформировать наш подход. Условно за тайтлом Java Developer могут скрываться десятки разных профилей. Задача рекрутинг-компании в том, чтобы представить клиенту только наиболее релевантных, а не спамить резюме.
Мы органично пришли к тому, что я как разработчик буду полезен не только для написания кода. Вакансий было много и все достаточно разнообразные. Чтобы закрывать их быстро и качественно, пришлось создавать внутренние гайды для рекрутеров. Они объясняли нюансы стеков, технологии-альтернативы и связи между инструментами. Это снимало лишние вопросы к клиенту и позволяло работать эффективно, даже когда одновременно «горело» с десяток направлений.
Сразу ли клиенты поняли «фичу»?
По правде, сначала реакция клиентов была неоднозначной. Кто-то удивлялся: «Зачем вам технарь в рекрутинге, если он не проводит собеседования?». Но после первых успешных кейсов скепсис исчезал. Вакансии формировались четче, нерелевантные кандидаты отсеивались еще на этапе скрина, а оффер давали после 5–6 интервью, а не десятков встреч.
Конечно, в агентстве я — не только технический эксперт, но и рекрутинг-консультант. Мой опыт в найме помогает глубже понять вакансию и задавать те вопросы, которые часто остаются вне фокуса. Я называю это инженерным подходом: определить, какую именно задачу должен закрывать человек, что действительно ключевое среди десятков строк в резюме и как найти совпадение с ожиданиями бизнеса.
Этот подход работает даже там, где речь не о разработчике, а о маркетологе, саппорте или дизайнере. Ведь типичное описание вакансии — это лишь плоская проекция, скрывающая настоящие грани роли. CTO помогает эти грани увидеть.
То, что когда-то казалось диковинкой, стало понятным преимуществом. И сегодня клиенты уже ожидают такого уровня сервиса от ITExpert.
Что именно делает разработчик в команде рекрутеров?
Среди моих основных тасок:
- Анализ требований.
Разработчик расшифровывает вакансию и сразу видит критические нюансы.
👉 Например, в QA Manual вакансиях часто указывают api-тесты, хотя на самом деле требуется полноценное backend-тестирование с Linux и анализом логов. Более того, иногда веб-интерфейса нет, так что привычные manual-практики имеют лишь условное отношение к такой вакансии — и большинство кандидатов просто не понимают, чего именно от них ожидают. А бизнес сталкивается с простоями. CTO может быстро понять, кто именно нужен.
Также я часто подсвечиваю моменты, которые клиент просто забыл упомянуть, хотя они критически влияют на поиск. То ли специфическая платформа для разработки, то ли зависимость от облачного провайдера / базы данных, что резко сужает пул кандидатов.
👉 Частый кейс: маленькая компания с микросервисным продуктом на PHP или Python. Про микросервисы как таковые забывают упомянуть, потому что это кажется очевидным из описания проекта (конечно, только для тех, кто уже в команде). На практике лишь БД или фреймворков будет недостаточно. И те, кто работал только с монолитом, не подойдут. В целом это другой уровень требований — и по пулу кандидатов, и по бюджету. Важно подсветить это на старте поиска, чтобы не тратить время клиента — именно это и делает CTO.
- Технический скрининг.
Нет, я не провожу технические собеседования. Для этого мне понадобились бы навыки кодинга на гораздо большем количестве языков разработки, чем может «потянуть» человек, прежде чем сойдет с ума 😉 Однако один взгляд инженера на резюме экономит десятки часов на собеседования.
👉 Кейс с DevOps-вакансией. Резюме выглядит сильным — DevOps с пятью годами опыта, Ansible, Terraform, CI/CD, работа с облаками. Но более глубокий технический скрин выявляет, что вместо мощного Kubernetes-стека для оркестрации сотен микросервисов, который нужен на вакансии, кандидат имел опыт только с Amazon ECS и почти не работал с кубером. В итоге — mismatch, так как эта технология требовала бы слишком много времени на дообучение. Здесь я экономлю время на технических интервью, чтобы клиент получил наиболее релевантных кандидатов.
- Консультации клиентов.
Самая интересная часть работы начинается там, где клиент еще сам не знает, что ему нужно. Например, когда продукт только формируется и стек не выбран. Или же когда рынок больше не может предложить новых кандидатов и требования нужно пересматривать.
👉 Был кейс со стартапом, который хотел строить сервис на современном Blazor (.NET + WebAssembly для frontend). Звучит круто, пока вы не начинаете считать, сколько кандидатов с коммерческим опытом найдете на рынке. Мы объяснили: поиск может растянуться на месяцы, а поддержка и масштабирование — под вопросом. Вместо этого стек .NET + Angular решал те же задачи, но давал в десятки раз более широкий выбор специалистов для сотрудничества. Это сэкономило клиенту и время, и бюджет.
Здесь внешний консультант выступает советником на уровне архитектора — помогает сопоставить цели продукта, учитывая возможности рынка.
- Обучение и координация рекрутеров.
Даже наше длительное обучение (4+ месяцев), которое проходит каждый наш рекрутер, не закрывает все вопросы. Важно держать переводчика с «айтишного» рядом — это может быть ваш представитель команды, а может быть внешний консультант.
👉 Кейс: Java-вакансия без Spring кажется сложной для «продажи» кандидатам, ведь Spring — мейнстрим и проверенная временем технология. Но именно здесь помогли технические объяснения относительно продукта клиента. Так, в микросервисах Spring Boot создает проблемы с использованием ресурсов, и компания сознательно внедрила Quarkus / Micronaut. Поэтому рекрутеры смогли подать это не как недостаток, а как плюс — возможность поработать с новыми подходами, которые решают реальные боли и дают дополнительную ценность опыту кандидата. В результате мы привлекли больше талантов для рассмотрения.
На самом деле чем лучше рекрутер понимает требования вакансии и подает соответствующих кандидатов, тем меньше средств вы тратите. Скажем, позиция закрывается за два месяца, а команда проводит собеседования 20 кандидатам (с тремя этапами интервью). Тогда это может «съесть» более 100 часов работы технических специалистов. В деньгах — это до нескольких тысяч долларов, потраченных только на общение с неподходящими кандидатами. Добавьте к этому еще и недополученную прибыль из-за «простоя» в разработке.
Так что каждая описанная функция — про релевантность результата и комфорт наших клиентов.
Что тебя лично удивило в этой работе?
Наверное, больше всего удивило, насколько многие вещи в рекрутинге выглядят как «секретные техники», хотя для разработчика они очевидны. Например, понимание, что некоторые технологии всегда идут в паре, или что определенные инструменты — это базовый минимум, а не дополнительный плюс. В книгах или на курсах для рекрутеров эти знания могут подавать как сакральные инсайты, а для меня это было чем-то обыденным.
Для инженера это как знать, что в машине есть руль и педали. А в рекрутинге это может звучать как целая глава из учебного пособия.
А еще рекрутеры — не джуниор-разработчики. Им не нужно кодить. Но курсы и материалы часто дают слишком много лишнего, превращая обучение в хаотичный набор технических деталей. Они только запутывают, вместо того чтобы объяснить главное — как общаться с кандидатами, понимать контекст и видеть связи.
И вот тут появляется желание делиться: объяснять простыми словами то, что технари воспринимают как «само собой разумеющееся», а потому и не проговаривают. Именно эти маленькие подсказки помогают рекрутерам двигаться быстрее, точнее формулировать вакансии и лучше понимать кандидатов. А бизнесу — закрывать вакансии быстрее и дешевле.
В чем самый большой челлендж твоей роли?
Самое сложное — постоянно отслеживать, что происходит в мире технологий. Они появляются и меняются настолько быстро, что каждый день приходится обновлять знания: от новостей в отрасли до запросов клиентов.
Fun fact: у нас в команде есть хэндбук с технологиями для рекрутеров. Во время последнего обновления, которое длилось до месяца, некоторые страницы пришлось переделывать дважды из-за все новых изменений на рынке.
Конечно, я не могу одинаково хорошо кодить на Go, Java и .NET, но должен четко понимать, какие требования действительно железные, а какие лишь nice-to-have, даже если речь идет о редкой позиции DevSecOps. И главное — нужно уметь объяснить клиенту, когда его ожидания завышены, а кандидатов с такими параметрами просто не существует.
Второй вызов — сочетать это с пониманием, как работают рекрутеры и какие инструменты они используют. Например, какие-то вещи кандидат может не указать в резюме или профиле LinkedIn, а на job-борде вообще нет фильтра под нужную технологию. Поэтому важно уметь еще и «перевести» технические требования в реальные возможности поиска — иначе идеальный кандидат останется невидимым. Это то, чего не сможет сделать разработчик из внутренней команды.
Часто нюансы вакансии нужно перевести еще и в правильные уточняющие вопросы. Например, есть запрос на серверную разработку на C++ — но это про сервер для умных вещей или для игр? По ответам кандидата рекрутер должен отличить одно от другого, чтобы не путать абсолютно разные профили. За свои 10+ лет в найме я научился добавлять нужные вопросы для отбора специалистов.
Мой челлендж — знать тонкости технологий и одновременно видеть ограничения рекрутинговых инструментов. И только на стыке этих двух миров рождается классный результат.
Станет ли подобный подход стандартом в рекрутменте?
Честно говоря, я не думаю, что подобный подход станет стандартом даже в далекой перспективе. Для таких функций разработчику нужен очень широкий опыт: понимать стек разных проектов, видеть разницу между продуктами и доменами, знать связи между технологиями и различать альтернативы. Это не только про знание отдельных языков — это как видеть всю картину, а не отдельные детали. Таких специалистов на рынке немного. И чаще всего они не готовы посвящать все свое время найму.
Но есть более реалистичный сценарий для рынка: качественная коммуникация между рекрутером и Tech Lead/CTO вашей компании. Если технические специалисты готовы объяснять детали как новичку, а рекрутер не боится задавать много вопросов, то этот мостик уже работает. Помочь могут:
- внутренние лекции по стеку проекта для нужд рекрутеров;
- регулярные sync-up звонки, где разработчик вслух анализирует CV специалистов;
- стандартизированный и развернутый набор вопросов для портрета кандидата.
Мой опыт здесь был органичным. Мы не планировали делать из этого «фишку» — все началось со стартапа. Просто хорошо делали свою работу и лишь позже осознали, что у нас есть козырь, которого нет у конкурентов. Поэтому далеко не всегда, имея преимущество, ты сразу его понимаешь. Успех — это обычно смесь большого труда и простого стечения обстоятельств.
Напоследок: совет для компаний, которые хотят улучшить свой рекрутинг-процесс
Позаботьтесь о качественной коммуникации между рекрутерами и техническими людьми в вашей компании. Самая большая ошибка — когда рекрутер получает «сырые» требования и сорсит кандидатов чуть ли не вслепую. Выигрывают те бизнесы, где рекрутеры могут без барьеров задавать «неудобные» вопросы, а CTO или техлиды готовы объяснять даже базовые вещи.
Сильный рекрутинг — не в количестве резюме, а в общем понимании задач бизнеса. Чем быстрее вы научите команду говорить на одном языке, тем быстрее появятся классные кандидаты, принятые оффера и выполненные задачи проекта.
Насколько полезной была эта статья?
Click on a star to rate it!
Средняя оценка 5 / 5. Количество голосов: 32
Оценок пока нет! Будьте первым, кто оценит этот пост.



