У спеціальному випуску подкасту УТ-2 у форматі «МВД», записаному спільно з DOu, інженери та лідери команд Юрко Федоренко, Євген Ковалевський та Саша Соловйов обговорюють, як змінюється підхід до технічних співбесід. На тлі поширення AI‑асистентів, зростання віддаленої роботи та втоми ринку від класичного «літкоду» вони пропонують радикальніший сценарій: замінити більшість технічних інтерв’ю оплачуваними тестовими днями або тижнями реальної роботи в команді.
Це не просто ще одна мода у HR. Йдеться про спробу переосмислити саму логіку відбору інженерів: від абстрактних задач на дошці до вимірюваної продуктивності в реальному середовищі.
Кінець епохи літкоду: чому класичні технічні співбесіди втрачають сенс
Класична модель технічної співбесіди — задачі на алгоритми, структури даних, іноді системний дизайн — десятиліттями була стандартом у великих технологічних компаніях. Але сьогодні її корисність дедалі частіше ставлять під сумнів.
По‑перше, ринок змінився технологічно. Доступність LLM‑асистентів, готових бібліотек і стандартних реалізацій алгоритмів робить знання на рівні «напиши quicksort з нуля» дедалі менш релевантним до щоденної роботи. Учасники дискусії прямо визнають: у реальних проєктах розробники майже ніколи не пишуть такі алгоритми самостійно, вони беруть готові реалізації з бібліотек, стандартних бібліотек мов або фреймворків.
По‑друге, з’являється розрив між тим, що міряє співбесіда, і тим, що справді потрібно в роботі. Питання на кшталт «реалізуй quicksort» або «розв’яжи нетривіальну задачу з масивами» мають обмежену кореляцію з реальними задачами продуктового інженера, який працює з легасі‑кодом, інтеграціями, бізнес‑логікою, комунікацією з замовниками та командою.
По‑третє, зростає роль judgment — здатності оцінювати якість рішень, коду, компромісів. Саме тому Ковалевський пропонує замість класичного кодінтерв’ю формат, де кандидату показують два варіанти коду з однаковою функціональністю й просять обрати кращий та пояснити, чому. Це вже не про механічне відтворення алгоритму, а про інженерне мислення.
При цьому важливий нюанс: знання алгоритмів як таких не відкидаються. Учасники визнають, що люди, які добре розуміють алгоритми, зазвичай краще працюють і глибше розуміють інші аспекти інженерії. Проблема не в алгоритмах, а в тому, як і навіщо їх перевіряють. Коли співбесіда перетворюється на змагання з розв’язування штучних задач, вона перестає бути інструментом прогнозу реальної ефективності.
На цьому тлі ідея радикальної заміни технічних співбесід тестовими періодами реальної роботи виглядає не просто провокацією, а логічною відповіддю на зміну контексту.
Реальна робота як інтерв’ю: як мають виглядати тестові дні та тижні
Ключова пропозиція, яку обговорюють ведучі, — замінити значну частину технічної воронки найму оплачуваними тестовими днями або тижнями. Суть підходу проста: кандидат приходить у команду й кілька днів працює над реальними задачами, у реальному середовищі, з реальними людьми.
На відміну від абстрактних тестових завдань, які часто виконуються «у вакуумі», без контексту, такі тестові періоди дають компанії можливість побачити:
як кандидат взаємодіє з командою, чи вміє ставити запитання, домовлятися, уточнювати вимоги;
як він працює з існуючим кодом, інфраструктурою, інструментами;
як реагує на невизначеність, зміну пріоритетів, обмеження реального продукту.
З іншого боку, кандидат отримує шанс побачити реальну культуру, процеси, стиль комунікації, а не лише polished‑версію компанії з презентації рекрутера. Це важливо в умовах, коли помилка з вибором місця роботи може коштувати місяців часу й нервів.
Євген Ковалевський прямо говорить, що кодінтерв’ю з літкодом і системним дизайном можна й варто замінювати офлайн‑форматами та тестовими днями. На його думку, саме там найкраще проявляється реальна продуктивність кандидата. В онлайні, вважає він, доцільно залишати лише те, що складно або дорого перенести в офлайн: перевірку досвіду, поведінкову частину, базову валідацію адекватності очікувань.
Цікава деталь — оцінка ефективності різної тривалості тестових періодів. Учасники дискусії вважають, що за два інтенсивні дні спільної роботи з командою можна зрозуміти понад 80% того, що дає повний тиждень тестового періоду. Тиждень, звісно, дає більше сигналів, але з погляду балансу між витратами й користю два дні вже дають дуже насичений зріз.
Це важливий аргумент проти побоювань, що тестові тижні надто повільно «прокачують» воронку найму. Якщо за два дні можна отримати більшість потрібної інформації, компанія може будувати процеси навколо коротких, але інтенсивних офлайн‑сесій, не розтягуючи відбір на місяці.
Оплачувані тестові дні: як уникнути безкоштовної праці й зробити процес чесним
Одна з ключових етичних і практичних проблем тестових завдань — ризик перетворення кандидата на безкоштовну робочу силу. Коли компанія дає складне завдання, яке можна використати в продакшені, але не платить за нього, це викликає закономірне роздратування й недовіру.
Тому в обговоренні наголошується: тестові дні мають бути оплачуваними. Це не лише питання справедливості, а й інструмент підвищення залученості кандидата. Людина, яка отримує оплату за свій час, сприймає тестовий період як повноцінну співпрацю, а не як «іспит без гарантій».
Окремо розглядається практична схема для тих, хто вже працює й не може просто так «випасти» з поточного проєкту. Пропонується варіант, коли кандидат бере відпустку за власний рахунок на тестовий день або тиждень, а в разі успішного найму компанія компенсує це додатковою відпусткою пізніше. Таким чином, ризики розподіляються більш рівномірно: кандидат інвестує час, але не втрачає його остаточно, якщо отримає офер; компанія платить за реальну роботу й отримує можливість якісно оцінити людину.
Цей підхід також знижує токсичність процесу. Кандидат не відчуває, що його змушують працювати безкоштовно, а компанія демонструє готовність вкладатися в відбір так само серйозно, як очікує вкладення від кандидата.
Попри очевидні переваги, учасники визнають, що в Україні тестові дні або тижні як елемент воронки найму поки що дуже непоширені. Ринок досі тяжіє до класичної моделі: резюме, одна‑дві технічні співбесіди, можливо, невелике тестове завдання — і рішення. Причини можуть бути різні: інерція процесів, небажання компаній платити за відбір, страх «загальмувати» масштабування. Але саме тому дискусія про альтернативи виглядає своєчасною.
Український ринок і вузький стек: чому тестові тижні особливо потрібні тут
На українському ринку найму, за спостереженнями учасників, домінує підхід «наймаємо під конкретний стек і роки досвіду з певним фреймворком». Це означає, що вакансії часто формулюються як «N років з React», «M років з конкретним embedded‑стеком» тощо. Такий підхід спрощує фільтрацію резюме, але має серйозні побічні ефекти.
По‑перше, він штучно звужує пул кандидатів. Саша Соловйов наводить приклад мілтек‑компаній, які шукають розробників з попереднім досвідом в embedded. На ринку таких спеціалістів об’єктивно мало, і вимога «обов’язково embedded‑бекграунд» перетворюється на самосаботаж. При цьому, на думку учасників, хороший інженер може розібратися зі специфікою embedded за тиждень або навіть за два дні, якщо має сильну базу й мотивацію.
По‑друге, фокус на роках досвіду з конкретним інструментом погано вимірює реальну здатність вчитись і адаптуватися. Людина, яка п’ять років працювала з одним фреймворком у вузькому контексті, може виявитися менш гнучкою, ніж інженер з ширшим технічним кругозором, але без «правильних» років у резюме.
Саме тут тестові дні й тижні можуть стати критично важливим інструментом. Вони дозволяють компанії побачити, як кандидат входить у новий домен, як швидко розбирається з незнайомим стеком, як працює з документацією, як ставить запитання. Це особливо актуально для embedded, мілтеку, складних продуктів, де формальний досвід не завжди є найкращим предиктором успіху.
Показовою є й дискусія про темпи росту команд. Учасники скептично ставляться до сценаріїв, коли компанія зростає з 20 до 40 людей за пів року. На їхню думку, такі цілі часто штучні й продиктовані бажанням «роздути» штат, а не реальними потребами продукту. Якщо ж мета — якісний результат, а не цифри в презентації для інвесторів, то швидке нарощування кількості інженерів рідко буває виправданим.
У цьому контексті тестові дні й тижні природно вписуються в більш обережну, але якісну стратегію росту. Замість того, щоб одразу наймати десятки людей, логічніше спочатку взяти кількох сильних продуктових фахівців, які зможуть будувати напрямки, а вже потім добирати невеликі команди під кожен з них — знову ж таки через реальну спільну роботу, а не через формальні співбесіди.
Алгоритми, LLM і поведінкові інтерв’ю: що лишається в онлайн‑частині воронки
Попри критику літкоду, учасники не пропонують повністю відмовитися від інтерв’ю як таких. Радше йдеться про перерозподіл акцентів між тим, що варто робити онлайн, і тим, що краще перевіряти офлайн у форматі реальної роботи.
В онлайні, на їхню думку, логічно залишити:
перевірку досвіду — через обговорення попередніх проєктів, ролей, відповідальності;
поведінкову частину інтерв’ю — з використанням структурованих підходів на кшталт STAR, коли кандидата просять описати конкретні ситуації, дії та результати;
базову валідацію технічного рівня без глибокого занурення в алгоритмічні задачі, які легко делегуються LLM.
Цікаво, що поведінкові інтерв’ю розглядаються як відносно стійкі до впливу LLM. Щоб вигадати правдоподібні історії про минулий досвід, потрібно завантажити в модель багато контексту про реальні компанії, ролі, конфлікти, що робить такий обман складним і ризикованим. До того ж, ці історії можна перевірити через референси.
Саме референси теж зазнають переосмислення. Ковалевський наводить приклад Superhuman, де референс‑форми містять велику кількість конкретних запитань: не просто «як вам ця людина», а «що саме вона робила краще за інших», «які сильні сторони проявлялись у таких‑то ситуаціях», «опишіть конкретні приклади». Це контрастує з типовою практикою, коли рекрутер телефонує й ставить загальне запитання «ну як він/вона взагалі?», отримуючи настільки ж загальну відповідь.
Такий підхід до референсів добре поєднується з тестовими днями. Поведінкове інтерв’ю й референси дають картину минулого, а тестові дні — картину теперішнього в конкретній команді. Разом вони формують більш надійний прогноз майбутньої ефективності, ніж будь‑який набір задач на алгоритми.
Що ж до самих алгоритмів, то консенсус такий: розуміння базових структур даних і складності операцій лишається корисним, але перевіряти це через написання з нуля quicksort на дошці — сумнівна практика. У світі, де готові реалізації є в кожній стандартній бібліотеці, а LLM можуть за секунди згенерувати коректний код, важливішим стає вміння обрати правильний інструмент, зрозуміти його обмеження й інтегрувати в систему, а не відтворити його реалізацію по пам’яті.
Висновок: тестові дні як наступний логічний крок еволюції найму
Дискусія в подкасті УТ-2 показує, що ринок технічного найму стоїть на порозі суттєвих змін. Класична модель з літкодом, системним дизайном на дошці й абстрактними тестовими завданнями дедалі гірше відповідає реаліям, де:
алгоритми рідко пишуть з нуля;
LLM знімають частину «механічної» роботи;
ключовими стають judgment, здатність швидко входити в нові домени й ефективно працювати в команді.
На цьому тлі оплачувані тестові дні й тижні реальної роботи виглядають не екзотикою, а природним наступним кроком. Вони дозволяють чесно оцінити кандидата в умовах, максимально наближених до бойових, зменшують роль штучних критеріїв на кшталт «роки з конкретним фреймворком» і дають обом сторонам — і компанії, і інженеру — більше прозорості.
Український ринок поки що лише придивляється до таких форматів. Але якщо компанії справді хочуть наймати не «ідеальні резюме», а людей, які принесуть результат у реальних умовах, перехід від літкоду до тестових днів може стати не просто модною практикою, а конкурентною перевагою.
Джерело
Подкаст УТ-2, спеціальний випуск «МВД» спільно з DOu: https://www.youtube.com/watch?v=3oh4k_NFV5Y