Навдіп Сінгх, відомий як NeetCode, побудував один із найпопулярніших сервісів для підготовки до технічних співбесід — NeetCode.io. До цього він працював інженером в Amazon і Google, проводив і проходив класичні DSA‑співбесіди, а зараз спостерігає, як на ринок одночасно обрушились AI‑інструменти, віддалений формат і масові «чітинг‑ тулзи». Попри це, каже він, саме формат алгоритмічних інтерв’ю дивним чином залишається стабільним — і це багато що говорить про те, як індустрія реально вміє (і не вміє) оцінювати інженерів.
Формат, який «не вмирає»: чому DSA‑інтерв’ю такі липкі
Парадокс починається з очевидного контрасту. На буденній роботі, за його спостереженнями, «більшість інженерів уже не пишуть код, вони промптять». З’явився клас інструментів, з якими «ми дійшли до точки, де ти можеш спитати AI‑бота будь‑що про кодову базу, і він дасть доволі хорошу відповідь… можна попросити реалізувати фічу, зробити майже що завгодно — це може дістатися хоча б на 90% шляху, навіть якщо не на 100%».
На цьому тлі очікування було простим: як тільки ШІ навчився писати код, алгоритмічні співбесіди мали б зникнути. Та цього не сталося. NeetCode констатує: «Кодинг‑інтерв’ю — це одна сфера, яка на диво лишилася доволі консистентною… формат структур даних і алгоритмів дуже‑дуже липкий». Деякі компанії пробують AI‑асистовані формати, але кістяк — задачі на масиви, дерева, графи, часову й просторову складність — живе практично без змін.
Це не лише інерція. Алгоритмічний формат виявився зручним «стандартом за замовчуванням»: його багато хто ненавидить, але всі приблизно розуміють, що таке «легка», «середня» чи «важка» задача, як оцінювати коректність і як проводити порівняння кандидатів. У світі, де все інше стрімко змінюється, це рідкісний острівок передбачуваності.
DSA ніколи не були тестом «чи вмієш ти робити цю роботу»
Цей формат, утім, має фундаментальну ваду. NeetCode формулює це досить жорстко: «DSA‑інтерв’ю ніколи не були найкращим способом перевіряти, чи це конвертується в роботу… це було більше про те, чи людина вміє думати».
Тобто перевіряють не вміння підтримувати складну кодову базу, не здатність працювати в продукті, не чуття до бізнес‑пріоритизації. Перевіряють:
- чи може людина розкласти задачу на підзадачі;
- чи вміє аргументовано вибирати структуру даних;
- чи здатна на ходу будувати й коригувати план рішення;
- чи може зрозуміло проговорювати хід думки.
Ці навички важко прив’язати до конкретного стеку або домену. Сам NeetCode наводить власну історію: рік після виходу з Amazon він майже не займався «реальним девелопментом», зате системно розбирав задачі, записував розбори й навчався пояснювати. Коли потім прийшов у Google, відчував себе «слабкішим за інших» саме у сирому досвіді продакшн‑коду, але все одно отримав складний проєкт, впорався з ним і доволі швидко виріс до мідла — завдяки вмінню планувати, проговорювати підхід і тримати в голові трейд‑офи.
У цьому сенсі алгоритмічні інтерв’ю виявилися майже випадковим, але корисним тренажером мислення. Не тестом «готовності до позиції», а радше фільтром на базову здатність розбиратися зі складними абстрактними задачами під тиском часу.
Компанії не вміють оцінювати інженерів — і, можливо, ніколи не вміли
Ключова причина живучості DSA‑формату, за спостереженнями NeetCode, — навіть не це. «Компанії просто не знають, як оцінювати… навіть коли ти наймаєш когось, дуже важко знати, як він реально покаже себе в роботі».
Він посилається на розмови із знайомими, зокрема з Amazon, де робили внутрішні дослідження й приходили до банального, але неприємного висновку: зв’язок між процесом інтерв’ю й реальною ефективністю на посаді вкрай слабкий. Навіть якщо ви ідеально відбудували грейдинг задач, калібрування, бали й бари, залишається купа факторів, які неможливо передбачити на співбесіді:
- мотивація людини через пів року;
- те, наскільки їй зайде конкретна команда й культура;
- як вона реагує на стрес, невизначеність, конфлікти пріоритетів.
Це погано масштабується й ще гірше вимірюється. А будь-яка спроба «зламати» старий процес ризикує зробити результат ще гіршим. Звідси логіка «якщо не зламано — не лагодь», особливо у великих корпораціях.
NeetCode підкреслює й організаційний бік: змінити формат — це не лише написати новий гайд. Це бюрократія, перекалібрування тисяч інтерв’юерів, нові чек‑листи, ризик роз’їзду стандартів між командами. Навіть експерименти від Meta з AI‑асистованими інтерв’ю показують, наскільки це болісно: «тренінг інтерв’юерів на це — реально важка штука… інтерв’юери в цілому не дуже люблять інтерв’ювати». У таких умовах старий, знайомий DSA‑формат виглядає привабливо стабільним.
AI в інтерв’ю: Meta експериментує, Google закручує гайки
Ситуація ускладнюється тим, що змінюється сам майданчик співбесіди. За останні роки розквітли «чітинг‑інструменти» для онлайн‑інтерв’ю: від банальних шпаргалок до софту, що в реальному часі підказує рішення в браузері. Усе це підкріплено тим, що практично всі великі компанії перейшли на віддалений формат.
Тепер маятник починає хитатися назад. NeetCode відзначає: «Google pretty much gone to on‑sites at this point… it’s going to be in person and somebody’s going to be watching you code». Тобто повернення до класики: дошка або ноутбук, інтерв’юер у кімнаті, мінімум шансів підглянути в інший екран.
Одночасно інші велики гравці, на кшталт Meta, пробують протилежний вектор: інтегрувати LLM прямо в процес. Кандидату дозволяють користуватися AI‑асистентом, але фокус зміщують з «ручного набору коду» на розуміння. Важливо не те, чи може ти написати кожен рядок сам, а чи здатен:
- сформулювати промпт;
- розібрати й скоригувати відповідь моделі;
- пояснити, що саме в цьому рішенні відбувається.
NeetCode описує підхід, який він сам вважає перспективним у такому світі: інтерв’юер може спокійно дозволити кандидату покладатися на AI, але потім ставити запитання на кшталт «цей масив цілих чисел — що він представляє в домені задачі?» або «чому ти обрав саме такий підхід і які його мінуси?». Це перевіряє не швидкість друку, а глибину розуміння.
Проблема в тому, що такий формат ще складніше стандартизувати. Треба навчити тисячі інтерв’юерів не лише ставити однакові задачі, а й однаково інтерпретувати відповіді в гнучких розмовних сценаріях. Для великого масштабу це майже нерозв’язна задача, саме тому зміни йдуть набагато повільніше, ніж хотілося б інженерам.
Гейміфікація неминуча — але є один формат, який важко зламати
Ще одна теза NeetCode звучить майже як закон природи: «Будь-який процес, що стандартизований і скейлиться, завжди можна «загеймити»». Неважливо, чи це LeetCode‑френдлі алгоритмічний гриль, чи модна нова система з AI‑підказками й поведінковими питаннями — як тільки формат стає масово застосовним, з’являються курси, гайди, тулзи й тактики, які навчають «як пройти, не розуміючи по суті».
Єдиний антипод гейміфікації, який він бачить у реальній практиці, — це формати, максимально наближені до справжньої роботи: стажерства й trial‑періоди. «Найкращий спосіб обійти це — стажерство або trial‑період, де ти бачиш, як людина реально працює», — підсумовує він.
Сенс очевидний. На відміну від годинної дошки з бінарними деревами, кілька тижнів у проді показують:
- як людина поводиться з невизначеними задачами;
- чи вміє сама знаходити інформацію;
- як комунікує з продактами та колегами;
- як реагує на фейли й фідбек.
Не випадково маленькі компанії, з якими спілкується NeetCode, все частіше говорять про формат «робочої проби». Хтось робить кількаденно оплачуване тестове; хтось — місячний період, дуже схожий на стажування. Там AI може й має бути в арсеналі кандидата, але оцінюють не «чисту» DSA‑майстерність, а те, що справді доведеться робити щодня.
Втім, цей підхід теж далеко не універсальний. Взяти людину на місячний trial легко, якщо вона студент або вже звільнилася. Якщо ж кандидат працює у великій компанії, йому просто фізично важко виділити на це час. Тому NeetCode визнає: подібні формати добре працюють у стартапів і невеликих фірм, але майже нереально маштабуються до масштабів Google чи Meta.
Як у цій реальності змінюється сигнал, на який дивляться
У підсумку ландшафт виглядає суперечливо:
- повсякденне програмування дедалі сильніше зливається з промпт‑інженерією;
- кандидати мають доступ до інструментів, що реально можуть «закрити» до 90% чисто кодингової роботи;
- а інтерв’ю залишаються майже такими ж, як десять років тому.
NeetCode не робить з цього висновку, що алгоритмічні співбесіди — «правильні». Швидше навпаки: вони переживають час саме тому, що нічого кращого, масово працюючого й відносно чесного на ринку досі не вигадали.
На цьому тлі змінюється інтерпретація сигналу. Алгоритмічна задача стає не стільки перевіркою «уміння кодувати», скільки тестом на:
- здатність мислити в умовах обмежень;
- уміння проговорювати план, а не лише писати код;
- готовність робити вибір між взаємовиключними варіантами.
У світі, де «будь-яку інформацію ти можеш просто випросити з промпта», головною відмінністю між кандидатами стає не доступ до знань, а зусилля й характер. Це добре видно з того, як сам NeetCode будує власний невеликий продукт: для найму він майже не проводить класичні інтерв’ю, а дивиться на те, як люди вирішують реальні задачі й чи здатні пояснити, чому зробили саме так, а не інакше.
І поки великі компанії обережно експериментують з AI‑асистентами, поверненням до очних інтерв’ю й новими форматами, саме це зміщення фокусу — від «рук, що пишуть код» до «голови, що приймає рішення й може їх захистити» — виглядає найстійкішим трендом.