Чому DevOps-кандидати отримують відмови: розбір з рекрутеркою (Частина 1)

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

Ірина Козенюк — рекрутерка у NETFORCE Group, має 5 років досвіду та спеціалізується на підборі DevOps-інженерів різних рівнів. У її практиці — закриття позицій від Junior до Senior, найчастіше Middle, для аутсорс- та аутстаф-проєктів, у штат компанії та для партнерів під ключ.

Без довгих передмов — переходимо одразу до питань.

Як виглядає процес найму DevOps-інженера очима рекрутера? З якими викликами ви стикаєтесь?

Процес найму DevOps-інженера — це значно складніше, ніж просто «знайти класного технічного спеціаліста». Це постійний баланс між потребами бізнесу, технічними вимогами, дедлайнами та очікуваннями людей.

Оскільки DevOps — досить широка роль, спершу важливо чітко визначити, хто саме потрібен компанії: DevOps-фахівець у класичному розумінні із хмарною експертизою, SRE, AWS чи Platform Engineer. Процес починається із запиту від CTO: затверджується бюджет, терміни закриття вакансії та стек критичних технологій, якими має володіти спеціаліст. Водночас важливо розуміти, що рекрутер не приймає рішення одноосібно. Навіть якщо я хочу дати офер — усе залежить від фінального фідбеку технічної команди та бізнесу.

Щодо основних викликів, з якими мені довелося стикатися, насамперед виділю такі:

• DevOps — це кандидатський ринок

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

• Бюджетні обмеження

Часто вимоги формують «ідеальну картинку» кандидата, а бюджет — ні. Тоді я опиняюся між ринковими очікуваннями кандидатів (на рівні $6-8k) та бюджетом компанії, обмеженим у $4,5-5k. Саме тут виникає розрив між ідеальним кандидатом і реальністю.

• Оцінка технічної глибини

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

Які найпоширеніші причини відмов кандидатам у DevOps після співбесіди трапляються на вашому досвіді?

Причини відмов залежать від конкретної компанії, її ресурсів та можливостей. Якщо говорити про наш досвід у NETFORCE Group, я можу виділити кілька ключових факторів:

• Недостатня глибина продакшн-досвіду

Часто кандидат володіє інструментами (AWS, Kubernetes, Terraform), але не будував інфраструктуру з нуля самостійно, не приймав критичних рішень і не працював з інцидентами рівня «горить прод». Це — найчастіша причина. 

• Слабка експертиза в Linux

Ця причина притаманна саме нашій компанії, оскільки у нас достатня кількість завдань по Linux як на аутсорс-, так і на аутстаф-проєктах.

• Пет-проєкти замість реального досвіду

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

• Невідповідність стеку та зарплатні очікування

Іноді кандидат сильний, але компанії потрібен AWS, а в нього досвід з Azure, чи потрібен hands-on Kubernetes, а досвід обмежується базовим використанням.

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

• Soft skills та комунікація

Важливий фактор навіть для highly technical ролей: як людина взаємодіє з командою, реагує на фідбек, вирішує конфлікти та чи вміє пояснювати складні речі просто. DevOps-фахівець часто працює між різними командами, тому сильний індивідуаліст може не підійти.

Траплялися ситуації, коли відмова виглядала дивно для кандидата: «Все ж було добре — чому відмова?». Серед типових причин:

• знайшли кандидата з більш релевантним стеком;
• інший фахівець мав глибший досвід з конкретним продакшн-середовищем;
• змінився бюджет або позицію заморозили;
• виник ризик по soft skills.

Іноді справа не в тому, що кандидат слабкий — просто інший трохи ближчий до конкретної потреби.

Чи відрізняються причини відмов для Junior, Middle та Senior?

Так, різниця є — і вона напряму пов’язана з очікуваннями від кожного рівня.

• Junior

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

• Middle

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

• Senior

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

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

Найчастіше цим кандидатам відмовляють через те, що їхній профіль ще не відповідає DevOps-ролі повністю.

• Системним адміністраторам часто бракує навичок автоматизації та IaC-підходу.
• Розробникам не вистачає глибини в розумінні інфраструктури та реального продакшн-досвіду.

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

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

Ще один можливий мінус під час світчу — завищене позиціонування. Коли кандидат хоче зберегти свій рівень доходу (наприклад, Senior розробника), але як DevOps-фахівець він ще об'єктивно не володіє достатнім досвідом, щоб виправдати такий бюджет.

Проміжні висновки

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

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

Очікуйте на другу частину розмови у нашому блозі 4 березня.

Христина Донченко