Спеціальний випуск подкасту УТ‑2 у форматі «МВД», записаний спільно з DOu, зібрав трьох добре відомих в українській тех‑спільноті інженерів і менеджерів: Юрка Федоренка, Євгена Ковалевського та Сашу Соловйова. Вони говорили про те, як змінюється найм розробників, що робити зі співбесідами в епоху LLM і як будувати команди без штучного роздування штатів.
Ця розмова оголює одразу кілька болючих точок українського ринку: фетиш конкретного стеку, перебільшені вимоги до embedded‑досвіду в мілтеку, нерозуміння ролі поведінкових інтерв’ю та хаотичний «ріст заради росту». І водночас показує, що навіть McDonald’s і Superhuman можуть бути корисними орієнтирами для українських продуктів і сервісних компаній.
Коли «5 років з конкретним фреймворком» стає пасткою
Одна з головних претензій до українського ринку найму — одержимість конкретним стеком і роками досвіду саме з ним. В описах вакансій це виглядає знайомо: «3+ років з React», «5+ років з Nest.js», «обов’язковий досвід з таким‑то фреймворком».
На перший погляд, це виглядає прагматично: компанія хоче мінімізувати ризики й отримати людину, яка «одразу поїде». Насправді ж така практика різко звужує пул кандидатів і гальмує розвиток як ринку, так і самих компаній.
По‑перше, технології змінюються швидше, ніж встигають накопичуватися «роки досвіду». Якщо сьогодні компанія шукає лише тих, хто вже три роки пише на конкретному фреймворку, вона автоматично відсікає сильних інженерів, які здатні опанувати цей інструмент за тиждень, але формально не проходять за чек‑лістом.
По‑друге, така логіка підштовхує до консервації стеку. Коли HR і менеджери звикають мислити категоріями «N років з X», будь‑яка спроба перейти на новий фреймворк або мову перетворюється на кадрову кризу: ринку ще немає, а вимоги вже є. У результаті компанії або застрягають на застарілих технологіях, або змушені переплачувати за обмежену кількість «правильних» кандидатів.
По‑третє, фокус на стеку відсуває на другий план те, що насправді визначає якість інженера: здатність розуміти проблему, робити технічні компроміси, працювати з невизначеністю, комунікувати з командою й замовником. Ці речі не вимірюються роками з конкретним фреймворком, але саме вони визначають, чи буде людина корисною в реальній роботі.
У підсумку ринок отримує парадокс: вакансії «з досвідом саме в нашому стеку» висять місяцями, а сильні інженери, які могли б закрити ці задачі, навіть не потрапляють у воронку, бо не відповідають формальним вимогам.
Embedded як «священна корова» мілтеку: штучний дефіцит своїми руками
Найяскравіше ця проблема проявляється в мілтек‑компаніях. Саша Соловйов звертає увагу, що там часто вимагають попередній досвід саме в embedded‑розробці. Формулювання на кшталт «обов’язковий досвід embedded» стали де‑факто стандартом для вакансій, пов’язаних із дронами, бортовими системами, сенсорами.
Проблема в тому, що embedded‑розробників на ринку об’єктивно мало. Це історично вузька ніша, яка до повномасштабної війни не була масовим напрямком в Україні. Коли десятки нових мілтек‑компаній одночасно починають шукати людей з однаковим бекграундом, дефіцит стає неминучим. Але значною мірою він штучний.
Учасники дискусії наголошують: хороший інженер здатен розібратися зі специфікою embedded за тиждень, а іноді й за два дні. Йдеться не про те, щоб за цей час стати гуру низькорівневого програмування, а про те, щоб вийти на продуктивний рівень: зрозуміти обмеження платформи, базові патерни, інструменти дебагу, типові граблі.
Якщо людина вже має глибокий досвід у C/C++, системному програмуванні, роботі з мережами чи перформансом, перехід в embedded для неї — це радше адаптація до контексту, ніж повноцінне «навчання з нуля». Вимога «2–3 роки embedded» у такому разі перетворюється на бар’єр, який не має реального технічного сенсу, але суттєво ускладнює найм.
Особливо абсурдною ця вимога виглядає в умовах війни, коли швидкість створення й еволюції мілтек‑рішень критична. Коли компанія місяцями шукає «готового embedded‑сеньйора», замість того щоб узяти сильного інженера й дати йому тиждень на входження, вона фактично сама собі створює вузьке місце.
Це не означає, що специфіку embedded можна ігнорувати. Але замість того, щоб робити з неї фільтр «допуску до професії», логічніше будувати процеси онбордингу: внутрішні гайди, менторство, невеликі стартові задачі, які дозволяють швидко набрати критичну масу знань.
Інакше ринок опиняється в ситуації, коли мілтек‑стартапи конкурують за десятки людей, замість того щоб навчити сотні.
Поведінкові інтерв’ю проти епохи LLM: що ще можна міряти
На тлі стрімкого розвитку LLM і «підказувалок у вусі» логічно звучить теза, що класичні технічні співбесіди втрачають сенс. Якщо кандидат може під час інтерв’ю отримувати допомогу від моделей, а в реальній роботі й так користуватиметься ними щодня, що взагалі перевіряти?
Одна з відповідей — змістити фокус з «уміння писати код тут і зараз» на те, як людина мислить і поводиться в реальних ситуаціях. Саме тут на перший план виходять поведінкові інтерв’ю.
Учасники обговорення підкреслюють: поведінкові питання й розбір конкретних прикладів з минулого досвіду залишаються корисними навіть у світі, де LLM можуть згенерувати будь‑який фрагмент коду. Причина проста: вони міряють не знання синтаксису, а реальні патерни поведінки.
Класичний підхід — формат STAR (Situation, Task, Action, Result). Кандидата просять описати конкретну ситуацію: що сталося, яке завдання стояло, які дії він зробив і до якого результату це призвело.
Такі історії важко вигадати на льоту, якщо їх не було. Ще складніше — зробити їх консистентними між собою й узгодити з резюме. А головне, їх можна перевірити на референс‑чеку: запитати колишніх колег чи менеджерів, чи справді людина поводилася так, як описує.
Це не панацея: у глобальному наймі, де компанії працюють з людьми з десятків країн, частина попередніх роботодавців може вже не існувати, а контакти — загубитися. Але там, де референси доступні, зв’язка «поведінкове інтерв’ю + точковий референс‑чек» дає значно більше інформації, ніж абстрактне «ну він норм, працював добре».
Показовий приклад — Superhuman. Євген Ковалевський згадує їхні детальні референс‑форми з великою кількістю конкретних запитань. Це не формальність на кшталт «оцініть кандидата за шкалою від 1 до 5», а структурований інструмент збору зворотного зв’язку.
Форма може починатися з простого радіобатона, але далі обов’язково йде відкрите питання: «Чому ви так вважаєте?», «Опишіть, як саме це проявлялося», «Які сильні сторони ви виділили б?». Такий підхід змушує референта згадувати конкретні ситуації, а не давати загальні оцінки.
Так, це забирає час. Хтось, як у випадку зі швейцарською компанією, може відмовитися заповнювати півторагодинну анкету й запропонувати натомість п’ятихвилинну розмову телефоном. Але суть не в форматі, а в рівні конкретики. Чим точніші питання — тим менше простору для розмитих відповідей.
У світі, де технічні навички все легше підсилювати інструментами, саме поведінкові патерни — як людина домовляється, як реагує на фейли, як бере відповідальність — стають тим, що важко підмінити чи симулювати.
McDonald’s як еталон системності: що може запозичити ІТ
Згадка McDonald’s у контексті інтерв’ю може звучати як жарт, але насправді це один із найяскравіших прикладів того, як масовий найм може бути системним.
У McDonald’s поведінкові індикатори вимірюють за допомогою стандартизованих процедур на співбесідах. Для кожної ролі визначені ключові компетенції — від роботи в команді до стресостійкості — і під них підібрані конкретні питання та сценарії. Інтерв’юери проходять навчання, щоб однаково інтерпретувати відповіді кандидатів.
Результат — передбачувана якість персоналу в тисячах ресторанів по всьому світу. Це не означає, що кожен працівник ідеальний, але система дозволяє уникати крайнощів і тримати планку на стабільному рівні.
Для ІТ‑компаній, які часто наймають «по відчуттю» або покладаються на харизму техлідера, такий підхід може бути корисним орієнтиром. Стандартизовані поведінкові індикатори не означають бюрократію, якщо вони прив’язані до реальних задач.
Наприклад, для продуктової ролі можна чітко визначити, що означає «уміння працювати з невизначеністю»: скільки разів людина запускала фічі без повного набору даних, як документувала ризики, як комунікувала з командою. Для інженера — як він поводиться, коли прод падає вночі: чи бере участь у розборі, чи ініціює постмортеми, чи пропонує зміни в процесах.
McDonald’s показує, що навіть при масовому наймі можна міряти поведінку не інтуїтивно, а через стандартизовані процедури. Для українських ІТ‑компаній, особливо тих, що планують масштабування, це сигнал: без чітко описаних поведінкових очікувань ріст штату неминуче перетвориться на хаос.
Ріст з 20 до 40 за пів року: чому це майже завжди погана ідея
Ще одна важлива тема — темпи росту команд. На ринку досі живе уявлення, що швидке збільшення штату — ознака успіху. Компанія, яка за пів року виросла з 20 до 40 людей, часто подає це як досягнення.
Учасники дискусії дивляться на це значно скептичніше. На їхню думку, ріст компанії з 20 до 40 людей за пів року зазвичай є поганою або штучною метою, якщо ціль — якісний результат, а не роздування штату.
Аргументи тут радше операційні, ніж ідеологічні. По‑перше, онбординг. Навіть якщо припустити, що всі нові люди сильні, команда фізично не встигає їх якісно інтегрувати: пояснити контекст, процеси, технічні рішення, неформальні правила. У результаті частина новачків місяцями працює «в тумані», приймаючи рішення, які суперечать одна одній.
По‑друге, менеджмент. Коли кількість людей подвоюється, а кількість досвідчених продуктових і технічних лідерів залишається тією самою, навантаження на них зростає експоненційно. Вони починають гасити пожежі замість того, щоб будувати системи.
По‑третє, мотивація. Якщо ріст продиктований не реальними бізнес‑потребами, а бажанням «виглядати більшими» або отримати бонус за розширення штату, це швидко відчувається всередині. Люди бачать, що задачі розмиваються, пріоритети змінюються щотижня, а нові колеги з’являються швидше, ніж зникають старі проблеми.
Альтернатива, яку пропонують учасники, — структурований ріст через продуктових людей. Якщо компанія справді виходить на нові напрямки, замість того щоб одразу шукати «ще 20 інженерів», логічніше спочатку найняти кількох сильних продуктових менеджерів або лідерів напрямків.
Ці люди отримують мандат запускати під себе невеликі команди — по двоє‑троє інженерів на старті. Такий підхід дає кілька переваг.
По‑перше, кожен новий напрямок має власного «власника», який відповідає за результат, а не просто за кількість закритих вакансій.
По‑друге, маленькі команди легше онбордити й синхронізувати з рештою організації.
По‑третє, якщо якийсь напрямок не «злетить», компанія втрачає не 20 людей, а кілька, і може відносно безболісно перерозподілити їх на інші задачі.
У нинішніх умовах, коли ресурси обмежені, а невизначеність висока, такий обережний, але структурований ріст виглядає значно здоровішим, ніж агресивне подвоєння штату.
Від стеку до поведінки: як може виглядати здоровий найм
Якщо скласти всі ці фрагменти докупи, вимальовується альтернативна модель найму, яка суттєво відрізняється від домінуючої на українському ринку.
По‑перше, відмова від фетишу конкретного стеку. Замість «3+ років з X» — фокус на базових інженерних навичках, здатності вчитися й адаптуватися. Для embedded і мілтеку це означає готовність брати сильних системних інженерів і вкладатися в їхнє входження, а не чекати міфічних «готових» кандидатів.
По‑друге, зміщення акценту з технічних «олімпіад» на judgment і поведінку. Формати на кшталт «покажи, який з двох фрагментів коду кращий і чому» дозволяють міряти здатність оцінювати рішення, а не лише писати їх з нуля. Поведінкові інтерв’ю й структуровані референс‑чеки — міряти, як людина діє в реальних ситуаціях.
По‑третє, системність у масштабуванні. Замість гордих кейсів «ми виросли з 20 до 40 за пів року» — чесна відповідь на питання «навіщо нам ще 20 людей і хто ними керуватиме». Якщо відповідь зводиться до «так прийнято на ринку» або «так легше вибити бюджет», це сигнал, що ріст штату може стати проблемою, а не досягненням.
Ця модель не є революційною. Багато з її елементів давно використовують глобальні компанії — від McDonald’s до Superhuman. Але для українського ринку, який одночасно переживає війну, релокацію й трансформацію ІТ‑сектора, вона може стати способом уникнути найгірших пасток: штучного дефіциту кадрів, токсичного овернайму й ілюзії, що «правильний стек» вирішує все.
Висновок: найм як стратегічна інженерна задача
Найм у сучасних умовах перестає бути допоміжною HR‑функцією й стає стратегічною інженерною задачею. Від того, як компанія формулює вимоги, що саме міряє на співбесідах і як масштабує команди, залежить не лише швидкість закриття вакансій, а й здатність вижити й розвиватися в довгостроковій перспективі.
Вузький фокус на стеку й роках досвіду створює штучний дефіцит, особливо в таких критичних напрямах, як мілтек. Перебільшені вимоги до embedded‑бекграунду відсікають сильних інженерів, які могли б увійти в домен за тиждень. Ігнорування поведінкових аспектів призводить до команд, які технічно сильні, але не здатні працювати разом.
Натомість поєднання гнучкості в технічних вимогах, системних поведінкових інтерв’ю, продуманих референс‑чеків і обережного, структурованого росту дає шанс будувати команди, які не лише вміють писати код, а й приймати рішення, вчитися новому й тримати удар.
У світі, де LLM можуть допомогти написати будь‑яку функцію, саме ці якості стають головною конкурентною перевагою — як для інженерів, так і для компаній.