Пастка-2025: Як ми в Landscape наймали Senior розробника в епоху ШІ і що з цього вийшло

💡 Усі статті, обговорення, новини про HR — в одному місці. Приєднуйтесь до HR спільноти!

Привіт, спільното! Це історія про наш недавній, трохи божевільний, але дуже показовий досвід найму FullStack Senior розробника в компанію Landscape. У 2025 році, коли штучний інтелект (ШІ) став не просто інструментом, а частиною ДНК розробки, процес найму перетворився на справжній квест. Особливо, коли ти шукаєш людину для роботи над самим ШІ. Це пастка, адже ті, хто добре розбирається в ШІ, можуть ним зловживати, особливо на етапі тестового завдання.

Частина 1: Сито для резюме та примари минулих помилок

Все почалося з лавини резюме. Більшість з них, як під копірку: стандартні фрази, схожий досвід. Ми відразу вирішили дивитися глибше: CV, особистий сайт, LinkedIn і, що найважливіше, — GitHub. І тут почалося найцікавіше. Більшість профілів були або порожніми, або неохайними, без жодного натяку на активність. Внесками в опенсорс могли похвалитися одиниці, що вже казало багато про що.

Нам потрібен був не просто виконавець, а талановитий інженер. Тому ми ретельно вичитували кожну заявку, витрачаючи години на первинний відбір. Досвід роботи зі ШІ, зокрема з агентами на кшталт нашої Amy (це не просто прокладка до ChatGPT, а система з власною пам’яттю та інструментами), був бажаним, але не обов’язковим. Я завжди казала і буду казати: робота з LLM — це не ядерна фізика. Це, по суті, робота з черговим API, і хороший програміст з цим розбереться.

Чому така прискіпливість? Ми вже обпеклися. Попередній досвід з розробником, який надмірно покладався на інструменти ШІ, залишив по собі купу низькоякісного коду, зірвані дедлайни та безліч моїх нервових клітин. Додайте до цього проблеми з комунікацією та незрозумілий робочий графік через різницю в часових поясах. Після цього ми прийняли важке, але необхідне рішення: зосередити пошук на кандидатах з Європи та Америки, щоб уникнути подібних ризиків у майбутньому.

Частина 2: Тестове завдання — пастка на три години

Після первинного відбору, який проводив наш CEO, на кандидатів чекало тестове завдання. І тут ми вирішили схитрувати.

Завдання: Створити елементарного AI-чатбота в командному рядку на Laravel, який би вмів відповідати на питання про погоду, використовуючи пакет Laravel Prism для роботи зі ШІ.

Умова: Ми чітко вказали, що на завдання слід витратити не більше трьох годин. При цьому обсяг роботи був свідомо більшим, ніж можна якісно виконати за цей час.

Мета пастки:

1. Перевірити адекватність та вміння слухати. Чи зрозуміє кандидат, що неможливо зробити все, і чи зможе він зупинитися?
2. Оцінити навички комунікації. Ми прямо попросили: якщо не встигаєте, опишіть, що зроблено, а що — ні, і сформулюйте завдання для наступного розробника.
3. Відсіяти «AI-наркоманів».

Перевірка тестових завдань стала для мене одкровенням. Ось як ми виявляли тих, хто сліпо довірився ШІ:

• Банальна неуважність: Деякі кандидати забували змінити URL в команді git clone зі зразка. Це був миттєвий провал.
• README, написаний роботом: Я багато працюю з ШІ і вже навчилася розпізнавати його стиль. Автоматично згенеровані README були переповнені непотрібною інформацією, яка не відповідала специфіці Laravel.
• Гігантські проєкти: Деякі кандидати надсилали проєкти з купою функціоналу, про який ми не просили. Очевидно, що це було згенеровано ШІ-асистентом, адже реалізувати такий обсяг за три години неможливо.
• Неідіоматичний код: ШІ, хоч і знає PHP, часто не розуміє глибинних концепцій Laravel. Я не побачила жодного сервісу, підключеного через Service Container з інтерфейсом та реалізацією. Це база, краса фреймворку, і її відсутність мене просто шокувала.
• Історія комітів: Лише кілька людей робили логічні, послідовні коміти, які дозволяли простежити їхній хід думок. Більшість просто закидала весь проєкт одним комітом з повідомленням «done».

Незважаючи на моє розчарування відсутністю сервісів, ми запросили на технічне інтерв’ю майже всіх, хто виконав завдання. Відверто поганих робіт не було, але й зіркових — теж.

Частина 3: Технічне інтерв’ю — комфорт проти стресу

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

Перша частина (30 хвилин, проводив лід-розробник Девід):

• Кандидат проводив walkthrough по своєму коду.
• Девід ставив уточнюючі питання: «Чому ти обрав таке рішення?», «Скільки ШІ ти використав?». Це допомагало виявити, наскільки людина чесна і чи справді розуміє свій код.

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

• Рефакторинг «товстого» контролера: Я хотіла почути про винесення логіки в сервіси чи моделі, а валідації — у Form Request класи. Бонусні бали — за згадку порушених принципів SOLID.
• Функція з 6+ параметрами: Очевидна архітектурна помилка. Я чекала на відповіді про використання DTO, class state або хоча б масиву.
• Питання-«пастка» на Senior-ність: «У нас є сервіс, який робить HTTP-запити до стороннього API. Як нам його тестувати, не надсилаючи реальні запити?». Хороша відповідь — моки (mocks). Ідеальна — створення фейкової реалізації інтерфейсу сервісу та її підключення (binding) в Service Container спеціально для тестів. До цього додумалися лише декілька кандидатів, і це був чіткий маркер їхнього рівня.
• Мінімальна перевірка фронтенду: Різниця між created та mounted у Vue.js.

Висновки, які я зробила для себе

1. Повальна відсутність теорії: Європейські розробники, схоже, нехтують теорією. Коли я запитала одного кандидата про SOLID, він образився і заявив, що він «практик, а не теоретик». Це мене вразило. В Україні люблять задовбувати теорією, і, можливо, це не так вже й погано.
2. Слабке знання Laravel «під капотом»: Базові, але потужні речі на кшталт Service Container, схоже, залишаються темним лісом для багатьох.
3. Ринок переповнений слабкими кандидатами: Якщо ви добре знаєте свій фреймворк, розумієте базові принципи ООП та архітектури, ви знайдете роботу. Конкуренція висока, але якість цієї конкуренції — низька.
4. Дилема хард- vs софт-скілів: Для мене софт-скіли надзвичайно важливі. Мені, як емоційній людині, важко уявити роботу з тим, хто уникає комунікації. Проте керівництво було підкорене хард-скілами одного з кандидатів, попри його очевидні комунікаційні труднощі. Це вічна дилема, з якою доведеться жити.

Врешті-решт, ми знайшли двох кандидатів котрим вислали оффер. Цей процес був виснажливим, але неймовірно корисним. Він показав, що в епоху ШІ головним критерієм відбору стає не вміння писати код (це може робити й машина), а здатність думати, проєктувати, комунікувати та, найголовніше, бути чесним.