Подкаст УТ-2 у спеціальному випуску «МВД», записаному спільно з DOu, зібрав трьох добре відомих в українській техтусовці інженерів і менеджерів: Юрка Федоренка, Євгена Ковалевського та Сашу Соловйова. На тлі буму LLM-інструментів і втоми від класичних «алгоритмічних» співбесід вони обговорюють, що саме сьогодні варто міряти в кандидатах і як це робити без ілюзій та самообману.
У центрі розмови — поняття judgment: здатність інженера оцінювати якість рішень, коду й компромісів, а не просто вміти швидко писати функції під таймер. Паралельно учасники переосмислюють роль алгоритмів, фундаментальних знань і поведінкових інтерв’ю в епоху, коли будь-яку «задачку з літкоду» можна розв’язати з підказкою великої мовної моделі.
Judgment як новий головний скіл: від «умію писати код» до «умію обирати правильний код»
Класична технічна співбесіда десятиліттями будувалася навколо двох стовпів: алгоритмічних задач і системного дизайну. Вважалося, що якщо людина може на дошці реалізувати quicksort і намалювати високорівневу архітектуру, то з продакшеном вона теж впорається. Сьогодні ця логіка дедалі частіше викликає сумніви.
Учасники дискусії прямо називають judgment одним із ключових сучасних скілів інженера. Йдеться не про «інтуїцію» в абстрактному сенсі, а про здатність:
розрізняти хороші й погані рішення в реалістичних умовах,
бачити наслідки вибору того чи іншого підходу,
зважувати компроміси між швидкістю, надійністю, вартістю підтримки, ризиками.
У продакшені інженер рідко працює в стерильному вакуумі алгоритмічної задачі. Натомість він постійно приймає дрібні й великі рішення: який підхід обрати, де спростити, а де, навпаки, інвестувати в якість; коли варто рефакторити, а коли краще не чіпати працюючий код; як пояснити ризики менеджеру чи замовнику.
Саме це, на думку співрозмовників, і є тим, що реально відрізняє сильного інженера від посереднього. І саме це майже не міряють класичні співбесіди, які зводять оцінку до «написав код — не написав», «пройшли тести — не пройшли».
Звідси й радикальні пропозиції: замість того, щоб змушувати кандидата під тиском часу реалізовувати алгоритм, варто прямо тестувати judgment — здатність оцінювати вже написаний код і аргументувати свій вибір.
Два шматки коду замість однієї задачі: як напряму міряти інженерний judgment
Один із запропонованих форматів інтерв’ю звучить майже провокаційно просто: показати кандидату два варіанти коду, які реалізують одну й ту саму функцію, і попросити обрати кращий та пояснити, чому саме.
На перший погляд це виглядає як «дрібниця» порівняно з повноцінною задачою. Насправді ж такий формат дозволяє побачити те, що в класичному кодінтерв’ю часто залишається в тіні.
По-перше, він змушує кандидата читати й аналізувати чужий код, а не лише писати свій. У реальній роботі це базова активність: рев’ю пул-реквестів, розбір легасі, інтеграція з чужими модулями. Людина, яка не вміє швидко зрозуміти чужий код і побачити в ньому проблеми, буде слабким ланцюгом у будь-якій команді.
По-друге, завдання на вибір «кращого» варіанту неминуче виводить розмову на критерії якості. Кандидат мусить проговорити, що для нього важливо: читабельність, простота, продуктивність, безпека, передбачуваність поведінки, тестованість. Саме в цих поясненнях і проявляється judgment.
По-третє, такий формат добре масштабується під різні рівні. Для джунів це може бути порівняння двох простих функцій з очевидними smell’ами. Для сеньйорів — аналіз двох архітектурних підходів чи різних реалізацій складнішого модуля. В обох випадках інтерв’юер бачить не лише «чи знає людина синтаксис», а й те, як вона мислить про код як про систему.
Нарешті, цей підхід значно стійкіший до «чітерства» через LLM. Навіть якщо кандидат теоретично може підглянути в модель, саме пояснення вибору, аргументація, вміння тримати лінію міркувань у діалозі — те, що важко підмінити підказкою в навушнику.
Алгоритми як індикатор глибини, а не як самоціль
Окрема лінія розмови — ставлення до алгоритмів. З одного боку, учасники визнають: люди, які добре розуміють алгоритми, зазвичай краще працюють і глибше розуміють інші аспекти інженерії. Це не випадковість.
Алгоритмічне мислення вчить:
бачити структуру задачі,
оцінювати складність рішень,
розуміти, де вузькі місця,
мислити в категоріях ресурсів — часу, пам’яті, мережі.
Ці навички прямо переносяться на дизайн систем, оптимізацію запитів, роботу з великими обсягами даних, побудову надійних сервісів. Людина, яка колись серйозно розбиралася з алгоритмами, зазвичай і в інших сферах інженерії мислить структуровано й системно.
З іншого боку, реалії продакшену такі, що більшість розробників майже ніколи не пишуть з нуля quicksort чи інші класичні алгоритми. Для цього існують бібліотеки, стандартні колекції, готові фреймворки. Переважна частина роботи — це інтеграція, оркестрація, побудова бізнес-логіки, а не винайдення нових структур даних.
Через це питання на кшталт «реалізуй quicksort на дошці» мають, на думку співрозмовників, дуже обмежену користь. Вони слабо корелюють із тим, що людина робитиме щодня, і часто відсікають сильних практиків, які давно не тренувалися в «олімпіадному» форматі, але чудово тягнуть продакшен.
Баланс, який вимальовується з дискусії, виглядає так: фундаментальне розуміння алгоритмів і операційних систем залишається важливим, але не як прямий предмет допиту на співбесіді, а як база, що впливає на judgment. Інженер, який розуміє, як працює пам’ять, кеші, планувальник ОС, мережеві стеки, зазвичай приймає кращі рішення — навіть якщо на співбесіді його не змушують це все відтворювати.
LLM проти літкоду: коли алгоритмічні співбесіди втрачають сенс
Ще один фактор, який змушує переглядати цінність класичних задачок, — поява й масове поширення LLM-інструментів. Учасники прямо говорять: сьогодні «читити» на алгоритмічних співбесідах стало набагато простіше.
Підказки в навушнику, «шиїшки» й інші напівжартівливі згадки — це не фантастика, а реальність ринку. Кандидат може отримувати поради від моделі в реальному часі, а інтерв’юер не завжди здатен це виявити, особливо в онлайн-форматі.
У відповідь багато компаній уже переводять кодінтерв’ю в офлайн, намагаючись мінімізувати можливості для підглядання. Але навіть це не розв’язує головної проблеми: якщо завдання саме по собі не дуже корелює з реальною роботою, то боротьба з «чітерством» виглядає як спроба зберегти ритуал за будь-яку ціну.
На цьому тлі пропозиція змістити фокус із «написати алгоритм» на «оцінити рішення» виглядає не лише сучаснішою, а й більш чесною. LLM чудово справляються з генерацією коду, але значно гірше — з розумінням контексту конкретної команди, бізнесу, обмежень продакшену. Саме judgment, а не швидкість набору, стає тим, що важко автоматизувати.
Це не означає, що алгоритми треба повністю викинути з процесу відбору. Але їхня роль змінюється: замість того, щоб перевіряти, чи пам’ятає кандидат конкретну реалізацію, варто дивитися, як він міркує про складність, компроміси, граничні випадки — у поєднанні з реалістичними задачами й кодом.
Переказ, твір і поведінкові інтерв’ю: чому вміння формулювати важливе не менше за вміння кодити
Окремий пласт розмови стосується того, що зазвичай вважають «софт-скілами», але в сучасній інженерії вони дедалі більше стають хардовою необхідністю. Йдеться про здатність формулювати й переказувати інформацію.
Учасники наводять показову історію: співробітниця сервісної компанії справляє враження кваліфікованої й приємної в спілкуванні людини, але результат її роботи систематично не відповідає домовленостям. Після кількох ітерацій стає зрозуміло, що проблема не в мотивації чи компетенції, а в банальному «зламі» на етапі переказу: те, що обговорили, не так потрапляє в нотатки, а потім — у виконання.
Керівник просить її вголос прочитати, що саме записано, і виявляється розрив між домовленістю й зафіксованим текстом. Це і є той самий навик переказу, який у школі тренували творами й викладами, а в дорослому житті часто недооцінюють.
У технічних командах ця здатність критична з кількох причин.
По-перше, інженер постійно спілкується з кастомерами, продакт-менеджерами, суміжними командами. Якщо він неточно передає вимоги, ризики, обмеження — це неминуче перетворюється на баги, зриви дедлайнів і взаємні претензії.
По-друге, в епоху LLM саме людина формулює запит до моделі. Якщо інженер не може чітко описати проблему, контекст, очікуваний результат, то й відповідь моделі буде такою ж розмитою. «Як ти Клоду розкажеш, що робить?» — це не жарт, а дуже практичне питання.
По-третє, здатність структурувати думки й викладати їх письмово чи усно — це основа для якісної документації, RFC, технічних рішень. Команда, де всі «все тримають у голові», погано масштабується й болісно переживає будь-які зміни складу.
Звідси й напівжартівливі, але показові пропозиції: замінити частину літкоду на «твір» або «переказ». Для мідлів — завдання на переказ: послухати опис задачі й зафіксувати його так, щоб інший інженер міг за цим працювати. Для сеньйорів — «твір»: сформулювати підхід до складної проблеми, пояснити, як вона лягає на бізнес-цілі, які ризики й компроміси.
Усе це напряму пов’язано з поведінковими інтерв’ю. Учасники наголошують: навіть в епоху LLM поведінковий блок залишається одним із найстійкіших інструментів оцінки. Якщо кандидат описує реальні ситуації зі свого минулого досвіду, пояснює, як діяв, що пішло не так, що змінив би — це важко сфабрикувати «на льоту» за допомогою моделі. А ще легше перевірити референсами, якщо ставити конкретні запитання.
Показовий приклад — детальні референс-форми в Superhuman, де від реферера вимагають не загального «норм/не норм», а конкретики: що саме людина робила добре, як це проявлялося, які були слабкі сторони. Такий підхід різко підвищує якість сигналу й дозволяє краще зрозуміти, як кандидат поводиться в реальних ситуаціях, а не лише в умовах інтерв’ю.
Фундамент проти ритуалів: що залишиться важливим у співбесідах завтра
Якщо звести дискусію до кількох висновків, картина виглядає так.
По-перше, класичні алгоритмічні задачі на кшталт quicksort як головний інструмент відбору відживають своє. Вони погано відображають реальну роботу, легко піддаються «чітерству» через LLM і часто перетворюються на ритуал заради ритуалу.
По-друге, фундаментальні знання — алгоритми, операційні системи, розуміння того, як працює комп’ютер «під капотом» — не втрачають цінності. Вони просто зміщуються з площини «що питати на співбесіді» в площину «що формує judgment і якість рішень». Інженер, який розуміє ці речі, рідше робить грубі помилки й краще бачить наслідки своїх дій.
По-третє, на перший план виходить оцінка judgment: здатності читати й оцінювати код, обирати між альтернативами, аргументувати свій вибір. Формати на кшталт «два варіанти коду — обери кращий і поясни» дають прямий доступ до цього скіла й краще відображають те, що інженер робитиме щодня.
По-четверте, вміння формулювати й переказувати інформацію, працювати з вимогами, чітко описувати проблеми й рішення стає не менш важливим, ніж уміння писати код. Це критично і для командної роботи, і для взаємодії з замовниками, і для ефективного використання LLM-інструментів.
По-п’яте, поведінкові інтерв’ю та якісні референси залишаються одним із найнадійніших способів зрозуміти, як людина поводиться в реальних ситуаціях. На відміну від алгоритмічних задач, їх складніше автоматизувати й підмінити підказками.
Усе це не означає, що завтра технічні співбесіди зникнуть. Але їхній фокус уже зміщується: від перевірки пам’яті й «олімпіадних» навичок — до оцінки judgment, комунікації та здатності працювати з реальними, а не штучними задачами. І ті компанії, які першими адаптують свої процеси під цю реальність, матимуть відчутну перевагу на ринку, де сильних інженерів менше, ніж вакансій, а LLM давно навчилися писати код не гірше за середнього кандидата.