Рекрутинг має бути smart. Робити масові розсилки розробникам в LinkedIn, не розуміючи специфіки позиції, — жахливо. Навіть меми про Java і JavaScript вже всім остогидли.
З іншого боку, є й менш очевидні хибні підходи, які будуть впливати на якість та результат рекрутингу. При цьому їх може припуститися навіть досвідчений IT-рекрутер.
Раніше на Highload я писав про те, чому важливо спілкуватися з розробниками однією мовою та як цього досягти. Зараз хотів би скоріше поділитися антикейсами: що стається з відкритими позиціями, якщо рекрутер не розбирається в технічних нюансах… І які можуть бути рішення цих ситуацій.
У рекрутинговій агенції ITExpert ми побудували процеси так, щоб рекрутер завжди міг проконсультуватися з технічним фахівцем. Крім того, я вже сім років брифую кожного клієнта, випитуючи важливі деталі та попереджуючи про те, як вимоги вакансії впливають на місткість ринку релевантних кандидатів (та їхні зарплатні очікування).
Цей досвід допоміг мені проаналізувати найбільш популярні проблеми в роботі над позиціями, з якими може зустрітися рекрутер на практиці.
Коли рекрутингом займаються одночасно кілька фахівців із розробки, стає складніше узгоджувати опис позиції. Кожен може бачити її по-різному і додає кілька вимог від себе. Так можна створити позицію, що не закриється ніколи, бо таких фахівців просто не існує на ринку.
Наприклад, ML-фахівець може займатися як прикладною частиною (впровадженням алгоритмів у код програми), так і теоретичними питаннями (більше як Scientist, який підбирає відповідну модель та її параметри). В розрізі рекрутингу для першого випадку потрібно конкретизувати мови програмування, фреймворки, а для другого — перевіряти математичну базу та знання у доменній сфері.
Якщо ці вимоги змішати між собою, то строк на закриття вашої вакансії буде подовжуватися роками.
Це неочевидна проблема, але, знаючи її, можна переглянути мастхев, nice-to-have вимоги. Для рішення краще переглядати кількість кандидатів, які відповідають вимогам, та консультуватися з зовнішніми фахівцями.
Наприклад, вашій команді потрібно знайти розробника зі знанням C++ для створення серверного програмного забезпечення. Зазвичай на C++ пишуть вбудовані та настільні програми. Вони дуже відрізняються від серверних (потрібно треба знати, як працювати з мережевими протоколами). Цю деталь не уточнюють в описах вакансії, оскільки вона є очевидною для програмістів і менеджерів. Вона може згадуватися хіба десь у детальному описі проєкту.
Рекрутер не завжди знає, які технології повинні бути за замовчуванням на таких проєктах, і може навіть не здогадуватися, що такі деталі потрібно уточнити ще до початку роботи над вакансією. Але якщо це не враховувати, то ви отримаєте безліч невідповідних резюме і витрачатимете час на марні співбесіди та переузгодження вимог.
Як це вирішити? Якщо ви працюєте в продукті, такі нюанси прийдуть до вас з часом. Якщо ви працюєте з великою кількістю різних доменів, проєктів (або не хочете чекати роками, наступаючи на граблі), є сенс більш глибоко брифувати вакансію.
Перш ніж почати роботу над позицією, запитуйте про загальні дані:
Інколи, розуміючи, що компанія і продукт будуть рости, менеджери додають у вимоги додаткові пункти. Це технології, які допоможуть розробнику у майбутньому, але не такі вже й критичні зараз.
За моїм досвідом, опис деяких вакансій на ¾ складається з таких вимог. При цьому, звичайно, вони впливають і на кількість потенційних кандидатів, які будуть релевантними, і на їхні зарплатні очікування.
Таке ускладнення фактично призводить до того, що рекрутинг побудований неефективно, а до кандидатів висувають завищені вимоги.
Щоб уникнути цієї проблеми:
Ви ніколи не помітите 100% проблем і нюансів, які можуть виникнути під час рекрутингу в IT. І це цілком нормально. Тренди на ринку технологій загалом швидко змінюються: можливо, сьогодні ви працюєте над вакансією з плюшкою «сучасний стек», а вже завтра кандидати будуть сміятися, бо він вже вважається застарілим.
Єдина універсальна порада від мене: аналізуйте свої результати, робіть висновки та комунікуйте. Спілкуючись з менеджером, який наймає, кандидатами та зовнішніми консультантами, і ставлячи правильні запитання, можна дійти кращого рішення 🙂
Успіхів!
Щодня ми носимо в своїй кишені пристрій, що в сотні мільйонів разів потужніший за комп’ютер,…
Оце сиджу, працюю і задумався: «А де ж проходить та тонка межа між фіксом, який…
«Коли вимірюваний показник стає метою, він перестає бути хорошою мірою» Закон який значною мірою відповідальний…
Інколи здається, що ви врахували все. Упевненість у рішенні настільки висока, що ви вже подумки…
Блогер та розробник Джозеф Круз розповів, як він працює програмістом, маючи доволі серйозні проблеми із…
Голова може боліти з безлічі причин. Але один з найпоширеніших різновидів — так званий головний…