Навіщо CTO у команді рекрутерів

Дивитись детальніше

Клієнти звикли бачити в агенції десятки рекрутерів, але аж ніяк не розробника. CTO поруч із рекрутерами виглядає дивиною — принаймні доти, доки ви не відчуєте ефект на власному найманні. Саме технічна експертиза перетворює хаотичний пошук у чіткий процес: менше марних інтерв’ю, швидші офери, релевантніші кандидати. Та економія тисяч доларів.

У цьому інтерв’ю Микола Клєстов, CTO ITExpert, ділиться історією, як із власного досвіду виросла ідея долучити експертизу розробника до команди рекрутерів і як саме ця роль змінює швидкість та якість найму для міжнародних IT-бізнесів.

Як виникла ця позиція у рекрутинг-агенції?

Історія почалася ще задовго до ITExpert. Тоді ми займалися внутрішнім наймом у власний продукт — і швидко відчули, наскільки непросто знайти людей не «під тайтл», а під конкретні завдання. Для підприємців на етапі MVP рекрутинг — суцільний хаос: вимоги розмиті, кандидати випадкові, а процес виснажував і команду, і бізнес.

Коли згодом з’явилася агенція, цей досвід допоміг сформувати наш підхід. Умовно за тайтлом Java Developer можуть ховатися десятки різних профілів. Завдання рекрутинг-компанії — показати клієнтам лише найрелевантніших спеціалістів, а не спамити резюме.

Ми органічно прийшли до того, що я як розробник буду корисним не лише для написання коду. Вакансій було багато й усі доволі різноманітні. Щоб закривати їх швидко та якісно, довелося створювати внутрішні гайди для рекрутерів. Вони пояснювали нюанси стеків, технології-альтернативи та зв’язки між інструментами. Це знімало зайві запитання до клієнта й дозволяло працювати ефективно, навіть коли одночасно «горіло» десяток напрямів.

Чи одразу клієнти зрозуміли «фічу»?

По правді, спочатку реакція клієнтів була неоднозначною. Хтось дивувався: «Навіщо вам технар у рекрутингу, якщо він не проводить співбесіди?». Але після перших успішних кейсів скепсис зникав. Вакансії формувались чіткіше, нерелевантні кандидати відфільтровувалися ще на етапі скрину, а офер давали з 5–6 інтерв’ю, а не після десятків зустрічей.

Звісно, у агенції я — не лише технічний експерт, а й рекрутинг-консультант. Мій досвід у найманні допомагає глибше зрозуміти вакансію та ставити ті запитання, які часто залишаються не у фокусі. Я називаю це інженерним підходом: визначити, яку саме задачу має закривати людина, що справді ключове серед десятків рядочків у резюме та як знайти метч із очікуваннями бізнесу.

Цей підхід працює навіть там, де йдеться не про розробника, а про маркетолога, сапорта чи дизайнера. Адже типовий опис вакансії — це лише пласка проєкція, яка приховує справжні грані ролі. CTO допомагає ці грані побачити.

Те, що колись здавалося дивиною, стало зрозумілою перевагою. І сьогодні клієнти вже очікують такого рівня сервісу від ITExpert.

Що саме робить розробник у команді рекрутерів?

Серед моїх основних тасок:

• Аналіз вимог.

Розробник розшифровує вакансію й одразу бачить критичні нюанси.

👉 Наприклад, у QA Manual вакансіях часто вказують api-тести, хоча насправді потрібне повноцінне бекенд-тестування з Linux і аналізом логів. Ба більше, інколи вебінтерфейсу немає, тож звичні мануальні практики мають хіба умовний стосунок до такої вакансії — і більшість кандидатів просто не розуміють, що саме від них очікують. А бізнес стикається з простоями. 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 чи техліди готові пояснювати навіть базові речі.

Сильний рекрутинг не в кількості резюме, а у спільному розумінні завдань бізнесу. Що швидше ви навчите команду говорити однією мовою, то швидше з’являться класні кандидати, прийняті офери та виконані завдання проєкту.