Епоха, коли достатньо було зазубрити сотню задач з LeetCode, стрімко завершується. Формати технічних співбесід розійшлися в різні боки: від повної заборони ШІ до інтерв’ю, де використання AI — обов’язкова умова. На Pragmatic Summit, де зібралися сотні інженерів і хіринг-менеджерів, обговорювали саме це — і їхні висновки, які систематизувала Marina Wyss – AI & Machine Learning, показують: готуватися «як завжди» вже небезпечно.
Фрагментована реальність: чому більше не існує єдиного формату
Ринок технічних інтерв’ю сьогодні не просто змінився — він розколовся. Дані CoderPad за 2026 рік показують, що:
- близько третини компаній повністю забороняють використання ШІ на співбесідах;
- майже половина дозволяє його в тій чи іншій формі;
- решта вирішує точково, залежно від ситуації.
Паралельно:
- 43% технічних оцінювань усе ще містять алгоритмічні задачі у стилі LeetCode;
- 78% розробників в опитуванні HackerRank вважають, що такі тести не відображають реальну роботу;
- 56% прямо кажуть, що алгоритмічні питання взагалі не релевантні їхнім щоденним задачам.
Натомість зростає частка:
- парного програмування;
- системного дизайну;
- симуляцій реальних сценаріїв (кожен формат — на рівні 30–38% оцінювань).
Результат: компанія А може вимагати «чистий» код без ШІ за 45 хвилин, компанія B — дати домашнє завдання з явним закликом користуватися Claude чи Cursor, а компанія C — будувати оцінку майже виключно на вашому GitHub. Це не варіації одного іспиту, а чотири різні ігри з різними правилами.
Чотири основні режими технічних співбесід
1. «AI-гонка озброєнь»: компанії, що тримаються за стару модель
Частина гравців ринку намагається зберегти класичний формат. Приклади:
- Google попереджає кандидатів, що використання ШІ під час інтерв’ю може призвести до дискваліфікації.
- Amazon у своїх онлайн-оцінюваннях:
- логуватиме активність браузера;
- обмежує копіювання-вставлення;
- дозволяє лише публічні ресурси, фактично відсікаючи більшість AI-інструментів.
Мета — зберегти старий сигнал: чи здатна людина написати коректний код з нуля під тиском часу.
Водночас саме в цій моделі найсильніше відчувається «AI-хаос» у воронці найму:
- резюме генеруються ботами;
- резюме фільтруються AI-системами;
- кандидати використовують ШІ, щоб проходити онлайн-тести;
- трапляються крайні випадки, коли після віддаленого найму на роботу виходить інша людина, ніж та, що проходила співбесіду.
У відповідь компанії вводять додаткові рівні верифікації:
- вимога записати Loom-відео, щоб підтвердити, що кандидат — реальна людина;
- подача резюме через POST-запит до API як фільтр: якщо не можеш зробити простий HTTP-запит — далі говорити немає сенсу;
- більша ставка на рекомендації та нетворкінг, щоб обійти зламаний масовий потік заявок.
Для кандидатів це означає: класична підготовка до структур даних і алгоритмів усе ще потрібна. Але навіть ці компанії посилюють прокторинг саме тому, що старий підхід дедалі гірше працює.
2. AI-native інтерв’ю: коли ШІ — частина завдання
На протилежному полюсі — компанії, які не просто дозволяють ШІ, а очікують, що кандидат вміє з ним працювати.
Прикладом став пілот Meta з AI-enabled coding interviews, де кандидатам прямо на співбесіді надають AI-асистента. Логіка проста: якщо ШІ — частина реальної роботи, оцінювати людину без нього не має сенсу.
Але тренд іде ще далі. Поширюється двоетапна модель:
-
Домашнє завдання з явним дозволом (або вимогою) використовувати ШІ.
Кандидат може залучати Claude, Cursor, Codex чи інші інструменти. -
Живе парне програмування на основі цього коду.
На цьому етапі перевіряють: - чи розуміє людина, що саме вийшло в результаті;
- чи може пояснити архітектуру та ключові рішення;
- чи здатна додати фічу, переробити частину коду, рефакторити.
Фокус зміщується з «написати все самостійно» на:
- якість промптів;
- уміння розбивати задачу на кроки (stepwise development);
- інстинкти код-рев’ю;
- стратегію тестування;
- навички дебагінгу;
- і навіть банальну, але критичну річ — чи здатен кандидат уважно прочитати згенерований код.
У світі, де ШІ за секунди видає тисячі рядків, ключовою стає не швидкість набору, а здатність:
- сповільнитися й уважно перевірити результат;
- помітити прихований баг;
- побачити потенційну вразливість;
- вчасно не погодитися з обраним AI-підходом.
AI-native формат не означає «AI усе зробить за вас». Він перевіряє, чи людина не віддає мислення «на аутсорс» моделі, а керує нею, перевіряє й розуміє.
3. Портфоліо як інтерв’ю: GitHub замість live-coding
Ще один помітний тренд — зміщення фокусу з абстрактних задач на реальні проєкти кандидата.
У такому форматі:
- замість live-coding сесій компанія детально розбирає ваші репозиторії;
- ставить конкретні питання:
- чому обрано саме таку архітектуру;
- які були альтернативи;
- що б ви змінили зараз;
- окремі хіринг-менеджери цілеспрямовано переглядають коміти в open source-проєктах і хантять людей без публікації вакансій.
Це радикально змінює підготовку:
- «проєкти з туторіалу» перестають мати будь-яку вагу;
- поверхневі демки, зібрані через «vibe coding» з AI без глибокого розуміння, легко виявляються під час уточнювальних питань;
- цінується саме мислення інженера:
- чіткі коміти;
- осмислені компроміси;
- пояснювані рішення.
Найкраща стратегія для такого формату — будувати проєкти, які справді цікавлять, і бути готовим говорити про них не як про «зробив по відео», а як про власні інженерні рішення з конкретними trade-off’ами.
4. «ML з нуля»: коли фундамент усе ще вирішує
Для ролей у машинному навчанні та data science картина інша. Попри загальну «практичнізацію» інтерв’ю, тут досі поширені завдання на реалізацію алгоритмів з нуля:
- логістична регресія;
- K-means;
- інші класичні методи.
Причина проста: ці позиції реально вимагають розуміння того, що відбувається «під капотом». Тому:
- фундаментальні знання з класичного ML залишаються обов’язковими;
- покладатися лише на високорівневі бібліотеки чи ШІ-асистентів небезпечно;
- очікується вміння вивести формули, пояснити кроки оптимізації, інтерпретувати результати.
У цій ніші інтерв’ю змінюються повільніше, і «ML з нуля» залишається окремим, стабільним режимом оцінювання.
Що шукають хіринг-менеджери незалежно від формату
Попри розбіжності у форматах, у вимогах до кандидатів простежується консенсус.
T-shaped інженер
Ключове поняття, яке часто звучить, — T-shaped engineer:
- глибока експертиза в одній області;
- достатня компетентність по всьому стеку.
Очікування «я займаюся тільки фронтендом» або «я лише бекенд» дедалі частіше вважаються нереалістичними. Від інженера чекають:
- розуміння, як працює весь продукт;
- здатності говорити однією мовою з суміжними командами;
- готовності брати участь у задачах за межами вузької спеціалізації.
Продуктове мислення
Важливим стає не лише «чи можеш ти це реалізувати», а й:
- навіщо це будується;
- чи розуміє кандидат потреби користувача;
- чи здатен поставити під сумнів специфікацію, яка не має сенсу;
- чи може запропонувати кращий варіант.
Це один із найсильніших диференціаторів, який мало хто свідомо тренує.
Комфорт з невизначеністю й хаосом
Особливо для ролей, пов’язаних з AI, де:
- системи працюють імовірнісно;
- помилки можуть бути дивними й нерепродуктивними;
- поведінка моделі змінюється після оновлень.
Цінуються люди, які:
- спокійно працюють у таких умовах;
- не ламаються від нестачі чітких інструкцій;
- здатні самі структурувати хаос.
Комунікація
Незалежно від формату інтерв’ю, завжди перевіряється:
- чи можете ви пояснити свої trade-off’и;
- чи здатні аргументувати рішення;
- чи вмієте проговорити ризики й обмеження.
Якщо мислення не можна донести, воно практично не існує для співрозмовника.
Найефективніша стратегія: не вгадувати, а запитати
В умовах чотирьох різних режимів інтерв’ю «готуватися наосліп» — найменш ефективний підхід. Компанії добре знають, що саме вони тестують, і часто готові це пояснити — якщо правильно запитати.
Робоча формула запиту до рекрутера може виглядати так:
«Я хочу підійти до інтерв’ю максимально підготовленим. Зараз існує багато різних форматів технічних співбесід, тому буду вдячний за будь-які орієнтири, на чому варто зробити акцент саме для цієї ролі».
Ключові моменти:
- ви не просите «дати відповіді»;
- демонструєте відповідальне ставлення до підготовки;
- даєте компанії шанс допомогти вам сфокусуватися.
Якщо у відповідь — лише розмиті формулювання на кшталт «production-level coding skills», варто уточнювати, що це означає на практиці: LeetCode, рефакторинг, дебаг, системний дизайн тощо. Іноді за красивими словами ховається звичайний алгоритмічний раунд.
Відмова компанії хоч якось описати формат теж є сигналом — часто про ширші проблеми з комунікацією.
Як готуватися, якщо інтерв’ю ще немає
Підготуватися до всіх можливих форматів одночасно неможливо. Але можна будувати базу, яка перекриває більшість сценаріїв.
Оптимальна стратегія:
- Будувати реальні проєкти з використанням ШІ — і розуміти кожен рядок коду.
Це: - готує до форматів «домашнє завдання + розширення на співбесіді»;
- створює портфоліо для GitHub-орієнтованих компаній;
- тренує AI-native навички: постановку задачі, перевірку, дебаг, рефакторинг;
-
природно розвиває продуктове мислення й інстинкти системного дизайну.
-
Підтримувати базову форму в алгоритмах і структурах даних.
Не обов’язково «гріндити» по 5 годин на день, але: - LeetCode Medium не має ставати катастрофою;
- регулярна практика допомагає не «випасти» з класичного формату.
Загальний принцип: дефолт — будувати речі, а не лише розв’язувати абстрактні задачі. Реальні проєкти дають найвищий «перекриття» між різними режимами інтерв’ю. А коли з’являється конкретна можливість — саме тоді варто звузити фокус, уточнити формат у рекрутера й адаптувати підготовку під конкретну гру, у яку грає ця компанія.
Джерело
YouTube: Coding interviews are completely different now (here’s why)