Коли меми вже не смішать: три найпопулярніші проблеми в роботі рекрутера

Микола Клєстов

Рекрутинг має бути smart. Робити масові розсилки розробникам в LinkedIn, не розуміючи специфіки позиції, — жахливо. Навіть меми про Java і JavaScript вже всім остогидли.

З іншого боку, є й менш очевидні хибні підходи, які будуть впливати на якість та результат рекрутингу. При цьому їх може припуститися навіть досвідчений IT-рекрутер.

Раніше на Highload я писав про те, чому важливо спілкуватися з розробниками однією мовою та як цього досягти. Зараз хотів би скоріше поділитися антикейсами: що стається з відкритими позиціями, якщо рекрутер не розбирається в технічних нюансах… І які можуть бути рішення цих ситуацій.

У рекрутинговій агенції ITExpert ми побудували процеси так, щоб рекрутер завжди міг проконсультуватися з технічним фахівцем. Крім того, я вже сім років брифую кожного клієнта, випитуючи важливі деталі та попереджуючи про те, як вимоги вакансії впливають на місткість ринку релевантних кандидатів (та їхні зарплатні очікування).

Цей досвід допоміг мені проаналізувати найбільш популярні проблеми в роботі над позиціями, з якими може зустрітися рекрутер на практиці.

1Неузгодженість щодо вимог вакансії

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

Наприклад, ML-фахівець може займатися як прикладною частиною (впровадженням алгоритмів у код програми), так і теоретичними питаннями (більше як Scientist, який підбирає відповідну модель та її параметри). В розрізі рекрутингу для першого випадку потрібно конкретизувати мови програмування, фреймворки, а для другого — перевіряти математичну базу та знання у доменній сфері.

Якщо ці вимоги змішати між собою, то строк на закриття вашої вакансії буде подовжуватися роками.

Це неочевидна проблема, але, знаючи її, можна переглянути мастхев, nice-to-have вимоги. Для рішення краще переглядати кількість кандидатів, які відповідають вимогам, та консультуватися з зовнішніми фахівцями.

2(Не)очевидні вимоги

Наприклад, вашій команді потрібно знайти розробника зі знанням C++ для створення серверного програмного забезпечення. Зазвичай на C++ пишуть вбудовані та настільні програми. Вони дуже відрізняються від серверних (потрібно треба знати, як працювати з мережевими протоколами). Цю деталь не уточнюють в описах вакансії, оскільки вона є очевидною для програмістів і менеджерів. Вона може згадуватися хіба десь у детальному описі проєкту.

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

Як це вирішити? Якщо ви працюєте в продукті, такі нюанси прийдуть до вас з часом. Якщо ви працюєте з великою кількістю різних доменів, проєктів (або не хочете чекати роками, наступаючи на граблі), є сенс більш глибоко брифувати вакансію.

Перш ніж почати роботу над позицією, запитуйте про загальні дані:

  • бекенд/фронтенд;
  • домен;
  • платформу (Web / Desktop / Mobile);
  • ОС;
  • інші інструменти.

3Вимоги «на перспективу»

Інколи, розуміючи, що компанія і продукт будуть рости, менеджери додають у вимоги додаткові пункти. Це технології, які допоможуть розробнику у майбутньому, але не такі вже й критичні зараз.

За моїм досвідом, опис деяких вакансій на ¾ складається з таких вимог. При цьому, звичайно, вони впливають і на кількість потенційних кандидатів, які будуть релевантними, і на їхні зарплатні очікування.

Таке ускладнення фактично призводить до того, що рекрутинг побудований неефективно, а до кандидатів висувають завищені вимоги.

Щоб уникнути цієї проблеми:

  • перепитуйте у менеджера, який поточний стек проєкту;
  • запитайте, який планується ріст (які технології будуть потрібні і коли саме, наскільки вони критичні зараз);
  • корисно порівнювати вимоги вакансії з описом технології проєкту.

Універсальне рішення всіх проблем в IT-рекрутингу

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

Єдина універсальна порада від мене: аналізуйте свої результати, робіть висновки та комунікуйте. Спілкуючись з менеджером, який наймає, кандидатами та зовнішніми консультантами, і ставлячи правильні запитання, можна дійти кращого рішення 🙂

Успіхів!

Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту та натисніть Ctrl+Enter.

Останні статті

Як я провела експеримент та отримала карʼєрну консультацію від ChatGPT

Одразу проговорю, що версія ChatGPT безкоштовна. Отже, попросила свого Альта уявити, що він — карʼєрний…

21.07.2025

Сервер MCP: навіщо він потрібен і для чого він підходить

Давайте відкинемо протокольний жаргон і скажемо прямо: якщо ви коли-небудь намагалися підключити свій ШІ до…

18.07.2025

AI-співбесіда або як я спілкувалась із Ші замість рекрутера

Нещодавно пройшла AI-співбесіду. Ух, оце був досвід! По-перше, мені здається, що вакансії взагалі не існувало…

17.07.2025

Як зробити біг регулярною звичкою, а не тимчасовим поривом?

Ще жодного разу я не прокидався з бажанням вийти на пробіжку. Завжди знаходяться переконливі причини…

16.07.2025

10 помилок, які роблять розробники при написанні API (і як їх виправити)

Блогер та розробник Марк Анрі розповів про головне помилки, які допускають розробники при створенні API.…

15.07.2025

Великий (несанкціонований) експеримент у Reddit та його результати

Reddit не має вишуканого інтерфейсу. У нього також немає крутих, вражаючих функцій. Його API коштує…

14.07.2025