Питання на співбесіді з AI-інженером: 15 питань і прапорці

Автор — Вадим Лобарєв, засновник MindHunt і Claude Certified Architect. Я особисто проводжу технічний скринінг кожного AI-інженера, якого ми презентуємо клієнту.

Майже всі добірки питань для співбесід з AI-інженерами написані для кандидатів: ось питання, ось як на нього відповідати. У цьому й проблема. Відповіді публічні, відрепетирувані й нічого вам не кажуть.

Цей гайд — для того, хто ставить питання: засновника, CTO чи інженерного менеджера, якому треба відрізнити реальний production-досвід від упевненого переказу чужих статей. Можливо, не будучи при цьому AI-спеціалістом.

Три правила до того, як писати питання

1. Питайте про те, що сталося, а не про те, що правильно. «Поясніть стратегії чанкінгу» перевіряє пам'ять. «Як ви обирали розмір чанка і що змінили після запуску?» перевіряє досвід. Усі питання нижче побудовані саме так.
2. Копайте на рівень глибше, ніж комфортно. Кандидати, яких варто наймати, під тиском стають конкретнішими — цифри, назви інструментів, те, що їх здивувало. Ті, кого варто уникати, стають загальнішими й упевненішими.
3. Не перевіряйте теорію тренування моделей для прикладної ролі. Якщо робота — будувати продуктові фічі поверх фундаментальних моделей, питання про backpropagation і градієнтний спуск відсіють саме тих інженерів, які вам потрібні, і пропустять ML-випускників, які нічого не запускали. Якщо не впевнені, кого саме наймаєте, спершу з'ясуйте це: AI Engineer vs ML Engineer.

Почніть із цього: базовий скринінг на п'ять хвилин

Перед глибшими питаннями я ставлю п'ять базових. Я додав їх через те, що постійно бачив на реальних скринінгах: дивовижно велика частка кандидатів — і на ролі AI-інженерів, і серед розробників, які кажуть, що щодня працюють із Claude Code, Cursor чи подібними інструментами, — не може назвати моделі, якими користується. Люди щодня працюють з AI і жодного разу не зазирнули під капот. Ці питання забирають п'ять хвилин і заощаджують вам годину.

A. «З якими моделями ви працюєте щодня? Назвіть їх — і скажіть, яку для чого використали б.»

Сильна відповідь називає конкретні моделі та їхні рівні, а не лише бренд. Для родини Claude від Anthropic, наприклад, це означає знати, що вона йде від малої швидкої Haiku через Sonnet та Opus до топової Fable, — і мати думку про розподіл: мала модель для класифікації, екстракції, маршрутизації й усього високонавантаженого; модель середнього рівня для більшості щоденного кодингу та продуктової роботи; найбільша — для складних міркувань, планування й оркестрації. Про ціну і latency кандидат згадує сам, без підказки.

Червоний прапорець: «я користуюся Claude» або «що Cursor обере». Людина, яка ніколи не обирала модель, ніколи не мусила думати про вартість, швидкість чи якість — тобто нічого не вела в production.

B. «Що таке контекстне вікно і що відбувається, коли воно заповнюється?»

Сильна відповідь: це ліміт на все, що модель бачить одночасно, — системний промпт, історію розмови, файли, результати інструментів, — виміряний у токенах. Якість починає падати задовго до жорсткого ліміту, а вартість і latency ростуть із кожним токеном. Кандидат може назвати способи керувати цим: саммаризація або компактизація історії, retrieval лише релевантного замість «вставити все», передача підзадачі саб-агенту з власним чистим контекстом.

Червоний прапорець: плутати контекстне вікно з пам'яттю моделі або з її тренувальними даними.

C. «Що таке prompt caching і коли він допомагає?»

Сильна відповідь: провайдер зберігає вже оброблений початок промпта, тож повторні запити зі спільним довгим префіксом — системний промпт, описи інструментів, великий документ — виходять значно дешевшими і швидшими. Працює це лише тоді, коли префікс лишається ідентичним, тому стабільний контент ставлять на початок, а змінну частину — в кінець; і кеш живе хвилини, а не дні.

Червоний прапорець: ніколи не чув. Для кожного, хто хоч раз оплачував рахунок за LLM, це одна з перших речей, про які він дізнався.

D. «Яка різниця між workflow та агентом і як ви обираєте?»

Сильна відповідь: у workflow кроки визначає ваш код, а модель викликається у фіксованих точках. В агенті модель сама вирішує, що робити далі — який інструмент викликати, коли зупинитися, — у циклі. Workflow передбачуваний, дешевший і легше тестується, тож це правильний вибір щоразу, коли кроки відомі заздалегідь. Агент виправдовує свою ціну лише тоді, коли шлях справді неможливо передбачити. Хороші інженери починають із найпростішого рішення, яке працює, і додають автономію неохоче.

Червоний прапорець: називати агентом усе підряд.

E. «Що таке патерн orchestrator–worker і коли він має сенс?»

Сильна відповідь: головна модель (оркестратор, або менеджер) розбиває задачу на частини, роздає їх моделям-воркерам — часто меншим і дешевшим, часто паралельно, кожній із власним контекстом, — а потім зводить і перевіряє результати. Це окупається на широкій роботі, яка чисто ділиться: дослідження по багатьох джерелах, зміни в багатьох файлах, рев'ю за кількома вимірами. І не окупається на малих задачах або тісно пов'язаній покроковій роботі: ви множите вартість у токенах, а воркери, які не бачать контексту одне одного, ухвалюють неузгоджені рішення.

Червоний прапорець: ніколи не чув або «що більше агентів, то краще».

Як користуватися базовим скринінгом: це фільтр на вході, а не оцінка. Кандидат на роль AI-інженера, який провалює більшість цих питань, далі не йде — хоч би яким гарним було резюме. Для звичайного розробника, який просто користується AI-інструментами для кодингу, мінімум — питання A і B: якщо він не відповідає на них, «щодня працюю з AI» означає автодоповнення.

Retrieval і RAG

1. «Розкажіть про RAG-систему, яка спочатку працювала погано. Що було не так і як ви про це дізналися?»

Навіщо питати: retrieval-augmented generation — найпоширеніший патерн у production LLM-продуктах і найчастіше «намальований» у резюме.

Сильна відповідь розділяє провали retrieval і провали generation: «потрібного документа не було в топ-5 результатів» — це інша проблема, ніж «документ був, але модель його проігнорувала». Чекайте конкретики: чанки, що розрізали таблиці навпіл; ембединги, які збігалися за темою, але не за суттю питання; застарілий індекс; re-ranker або гібридний пошук за ключовими словами, доданий після запуску. І опису того, як вони про це дізналися: розмічений набір питань, логи retrieval, скарги користувачів, які вдалося простежити до причини.

Червоний прапорець: охайна екскурсія архітектурою — «ми взяли векторну базу і LangChain» — без жодного провалу. Або звинувачення моделі в усьому.

2. «Коли RAG був неправильним інструментом і що ви використали натомість?»

Сильна відповідь називає реальні альтернативи: покласти весь документ у довге контекстне вікно, бо корпус малий; звичайний SQL-запит чи пошуковий індекс, бо дані структуровані; fine-tuning, бо проблема була у стилі чи форматі, а не у знаннях. Плюс — якщо вартість і latency були частиною рішення.

Червоний прапорець: RAG як відповідь на все або відсутність власної думки.

Оцінка якості (evals)

3. «Звідки ви знаєте, що ваша LLM-фіча працює? Проведіть мене через систему оцінки на останньому проєкті.»

Навіщо питати: це найнадійніший розділювач між інженерами, які запускають продукти, й інженерами, які показують демо. Викликати API моделі може будь-хто. Довести, що результат хороший, — значно менше людей.

Сильна відповідь описує тестовий набір із реальних запитів користувачів, включно з незручними; що саме оцінювали і як — точні перевірки, де це можливо, LLM-as-judge з письмовою рубрикою, де ні, ручну перевірку вибірки; і як самого «суддю» звіряли з оцінками людей. Кандидат згадає, що набір проганяють перед кожною зміною промпта чи моделі.

Червоний прапорець: «ми протестували вручну, виглядало добре». Або згадка BLEU і ROUGE — метрик з епохи машинного перекладу, які майже нічого не кажуть про те, чи правильно відповів асистент.

4. «Розкажіть про регресію, яку ви спіймали до того, як вона дійшла до користувачів, — або про ту, яку не спіймали.»

Сильна відповідь — це історія: правка промпта, яка полагодила один кейс і зламала три інші; оновлення версії моделі, що змінило формат виводу; що eval-набір упіймав, що пропустив і що додали після цього.

Червоний прапорець: таких історій немає. Вони є в кожного, хто вів LLM-фічу довше місяця.

Агенти, tool use і MCP

5. «Опишіть агента, якого ви вивели в production. Що він умів, що йому було заборонено і як ви цю заборону забезпечували?»

Сильна відповідь говорить про межі раніше, ніж про можливості: які tools були лише на читання, де дію мала підтвердити людина, ліміти кроків і бюджету, що відбувалося, коли виклик інструмента падав або повертав нісенітницю. Хороші кандидати розповідають, що проєктували описи інструментів і повідомлення про помилки для моделі так само ретельно, як API для живого розробника.

Червоний прапорець: ефектна демо-історія без жодного слова про обробку збоїв, права доступу чи вартість. «Він сам розбирається.»

6. «Ви будували або інтегрували MCP-сервер? Що ви відкрили моделі, а що вирішили не відкривати?»

Навіщо питати: Model Context Protocol став стандартним способом під'єднувати моделі до інструментів і даних, але майже жоден гайд зі співбесід його не покриває. У 2026 році це чесне базове питання для кожного, хто заявляє досвід з агентами.

Сильна відповідь охоплює проєктні рішення: менше добре описаних інструментів замість дзеркала всього API; автентифікація і те, до чого сервер узагалі має доступ; як тримати результати інструментів достатньо малими, щоб не заливати контекстне вікно; ризик під'єднання сторонніх серверів, які ви не контролюєте.

Червоний прапорець: плутати MCP із фреймворком чи моделлю або «ми під'єднали все».

Калібрування: не працювати з MCP — не дискваліфікація, він новий. А от не чути про нього, заявляючи актуальну роботу з агентами, — сигнал про те, наскільки уважно людина стежить за галуззю.

7. «Як ви гарантуєте, що модель повертає дані, на які може покластися ваш код?»

Сильна відповідь: structured outputs або tool calling зі схемою, валідація на вході (Pydantic, Zod, JSON Schema), повторна спроба з поверненням помилки моделі та визначена поведінка на випадок, якщо валідація все одно не проходить. У реальних вакансіях це прописано прямо; більшість добірок питань це пропускає.

Червоний прапорець: парсити вільний текст регулярками і сподіватися на краще.

Архітектурні рішення

8. «Промптинг, RAG чи fine-tuning — розкажіть про випадок, коли довелося обирати.»

Сильна відповідь подає це як послідовність, а не меню: почати з промптингу і якісного контексту; додати retrieval, коли моделі бракує знань; розглядати fine-tuning лише тоді, коли проблема в поведінці, форматі або вартості на масштабі, — і лише з eval-набором, який доведе, що це допомогло. Варто почути й про те, скільки коштує підтримка fine-tuned моделі, коли базову модель за пів року замінять.

Червоний прапорець: fine-tuning як перший крок або як ознака «серйозності».

9. «Як ви обираєте модель для конкретної фічі?»

Сильна відповідь: проганяє кандидатів через той самий eval-набір і порівнює якість, latency та вартість запиту; бере малу швидку модель для простих кроків і сильнішу там, де це важить; тримає код достатньо незалежним від моделі, щоб її можна було замінити. Має думку щонайменше про двох провайдерів — із власного використання, а не з прочитаних бенчмарків.

Червоний прапорець: «беремо найкращу» — без уявлення, скільки вона коштує на тисячу запитів.

10. «Розкажіть про випадок, коли ви відрадили когось використовувати LLM.»

Сильна відповідь називає ситуацію, де правило, запит або класична модель були дешевшими, швидшими й надійнішими, — і як вдалося пояснити це продакт-менеджеру, який хотів «AI».

Червоний прапорець: кожна проблема — це LLM-проблема. Найцінніше слово хорошого AI-інженера — «ні».

Production: вартість, безпека, observability

11. «Скільки коштував один запит у вашій фічі і що ви зробили, щоб це здешевити?»

Сильна відповідь знає цифру або хоча б порядок величини. Можливі важелі: prompt caching, скорочення контексту, маршрутизація простих запитів на меншу модель, батчинг офлайн-задач, стримінг для кращої відчутної швидкості, кешування однакових запитів.

Червоний прапорець: ніколи не дивився. На малому масштабі це можна пробачити; для людини, що заявляє production-систему з реальним трафіком, — ні.

12. «Як би хтось атакував систему, яку ви збудували, і що ви з цим зробили?»

Сильна відповідь відрізняє пряму prompt injection від непрямої — шкідливих інструкцій, захованих у вебсторінці, документі чи листі, які читає модель. Можливі захисти: вважати весь retrieved-контент недовіреним, мінімальні права для інструментів, підтвердження людиною для незворотних дій, фільтрація виводу, жодних секретів у промптах. Кандидат також має вміти сказати, які дані виходили за периметр компанії і за якою угодою.

Червоний прапорець: «ми написали в системному промпті, щоб модель так не робила».

13. «Вівторок, ранок, якість відповідей просіла. Ніхто нічого не деплоїв. Як ви з'ясуєте, що сталося?»

Навіщо питати: observability — найменш покрита тема в AI-співбесідах і одна з найпоказовіших.

Сильна відповідь починає з того, що вже мало б бути налаштовано: трейси кожного запиту з промптом, retrieved-контекстом, викликами інструментів і виводом; якість, яку постійно вибірково оцінює автоматичний суддя; дашборди latency, вартості та частки відмов моделі. Далі гіпотези: тихе оновлення моделі провайдером, зміна джерела даних вище за течією, зсув у структурі запитів користувачів, індекс, який перестав оновлюватися.

Червоний прапорець: почати з «я б подивився логи», не уявляючи, що в них є.

Судження і комунікація

14. «Ваш продакт-менеджер хоче запустити фічу, яка помиляється приблизно в 10% граничних випадків. Що ви робите?»

Сильна відповідь відкидає рамку «так чи ні». Скільки «помилка» коштує користувачеві тут — трохи гірше саммарі чи неправильна медична інструкція? Чи можна зробити збій видимим, зворотним або перенаправити до людини? Чи можна звузити запуск до випадків, де все працює? Ризик пояснюють мовою бізнесу, а не мовою моделей.

Червоний прапорець: «запускаємо» або «ніколи» — без питання про те, що це за помилки.

15. «У чому ви змінили думку за останні пів року?»

Сильна відповідь конкретна і свіжа: техніка, від якої відмовилися; інструмент, який почали використовувати; щось, що новий реліз моделі зробив непотрібним. У галузі, яка рухається так швидко, сеньйор, чиї погляди не змінилися за рік, перестав стежити.

Червоний прапорець: нічого не спадає на думку.

Калібрування під рівень

Ті самі п'ятнадцять глибоких питань працюють на будь-якому рівні. Змінюється відповідь, на яку варто розраховувати.

	Middle	Senior	Lead / Platform
Масштаб історій	Фіча, збудована в чужому дизайні	Система, яку спроєктував і вів від початку до кінця	Платформа, на якій будували інші команди
Провали	Може описати баг і фікс	Може пояснити першопричину і що змінив у процесі	Може описати, як зупинив цілий клас збоїв у кількох командах
Evals	Користувався eval-набором	Збудував його і провалідував суддю	Зробив evals обов'язковим гейтом релізу для чужої роботи
Вартість і latency	Знає важелі	Знає цифри	Встановлював бюджети і будував інструменти для їх контролю
Уміння сказати «ні»	Висловлює сумніви	Пропонує альтернативу	Змінював роадмап

Одне застереження щодо років досвіду: прикладній LLM-інженерії в її нинішньому вигляді близько трьох років. Вимога «5+ років досвіду з LLM» відсікає майже всіх кваліфікованих. Шукайте сильний загальний інженерний сеньйоріті плюс один–три роки реальної production-роботи з LLM. Скільки такий профіль коштує на різних ринках — у нашому гайді із зарплат AI-інженерів.

Проста оцінна картка

Оцінюйте кожен напрям від 1 до 4 одразу після співбесіди, до обговорення з колегами. До кожної оцінки — одне речення доказу: цитата, а не враження.

Напрям	Питання	1 — сигналу немає	4 — сильний сигнал
Retrieval	1–2	Описує лише архітектуру	Діагностує провали retrieval і generation на прикладах
Evals	3–4	Ручні вибіркові перевірки	Тестовий набір із реальних даних, провалідований суддя, історія регресії
Агенти й інструменти	5–7	Історія рівня демо	Межі, обробка збоїв, валідація схем
Рішення	8–10	Один інструмент на всі проблеми	Чіткі компроміси, вміє сказати «ні»
Production	11–13	Ніколи не дивився на вартість, безпеку чи трейси	Знає цифри, модель загроз і як би дебажив
Судження	14–15	Бінарні відповіді, застиглі погляди	Пояснює ризик мовою бізнесу; погляди еволюціонують

Для прикладного AI-інженера я надаю найбільшу вагу Evals і Production. Кандидат із 4 за обома і 2 за агентів вивчить агентів за місяць. Навпаки — значно важче.

Якщо ви самі не експерт з AI

Більшу частину цієї співбесіди ви все одно можете провести самі. Не треба знати правильну відповідь, щоб почути різницю між конкретною і розмитою. Три практичні прийоми:

• Тричі запитайте «а що було далі?». У справжнього досвіду є третій шар. Відрепетирувані відповіді закінчуються після першого.
• Просіть цифри. Запитів на день, вартість запиту, розмір eval-набору, скільки тривав інцидент. Хто там був — пам'ятає.
• Додайте один зовнішній технічний скринінг. Година розмови з людиною, яка сама будує на цих технологіях, перед вашим власним циклом інтерв'ю знімає більшу частину ризику. Саме цю частину процесу клієнти найчастіше просять провести нас.

Увесь процес найму довкола співбесіди — визначення ролі, сорсинг і помилки, на яких провалюється більшість AI-пошуків, — у статті Як найняти AI-інженера.

Як допомагає MindHunt

Кожен AI-інженер, якого ми презентуємо, проходить технічний скринінг на основі питань вище. Його проводить засновник із сертифікацією Claude Certified Architect, який щодня працює з цими технологіями. Разом із шортлистом — зазвичай за два-три тижні після старту — ви отримуєте письмову оцінку реальної глибини кожного кандидата: де він був конкретним, а де ні.

→ Обговорити пошук AI-інженера

Часті запитання

Які питання ставити на співбесіді з AI-інженером?

Питайте про провали, вимірювання й компроміси, а не про визначення: RAG-систему, яка не працювала, і як про це дізналися; як оцінюють якість виводу; що агенту було заборонено; скільки коштує запит; як систему можна атакувати; і випадок, коли кандидат відрадив використовувати LLM. Сигнал — конкретні відповіді з досвіду.

Чим співбесіда з AI-інженером відрізняється від звичайної співбесіди з розробником?

Залиште звичну планку з кодингу та system design — AI-інженер насамперед програмний інженер. Додайте оцінку суджень, специфічних для LLM-систем: оцінка недетермінованого виводу, керування вартістю і latency, робота з галюцинаціями та prompt injection, рішення про те, коли модель узагалі не потрібна. Алгоритмічні задачки нічого з цього не перевіряють.

Чи варто ставити питання з теорії машинного навчання?

Лише якщо роль передбачає тренування або fine-tuning моделей. Для інженера, який будує продуктові фічі поверх фундаментальних моделей, питання про backpropagation чи функції втрат відсіюють сильних практиків і пропускають кандидатів, які нічого не запускали.

Як проводити співбесіду з AI-інженером, якщо я сам не розбираюся в AI?

Просіть конкретику й цифри, після кожної відповіді питайте «а що було далі?» і слухайте, чи стають відповіді під тиском конкретнішими, чи загальнішими. Додайте один зовнішній технічний скринінг від людини, яка сама будує з LLM, перед вашими власними інтерв'ю.

Які базові питання про AI має знати будь-який інженер?

П'ять питань на п'ять хвилин: з якими моделями людина працює і яка для чого підходить; що таке контекстне вікно і що відбувається, коли воно заповнюється; що таке prompt caching; яка різниця між workflow та агентом; що таке патерн orchestrator–worker і коли він має сенс. На реальних скринінгах дивовижно багато кандидатів, які щодня користуються AI-інструментами для кодингу, не можуть назвати моделі, з якими працюють.

Які червоні прапорці на співбесіді з AI-інженером?

Немає історій про провали; оцінка якості описана як «тестували вручну»; кожна проблема вирішується через LLM; жодного уявлення про вартість роботи системи; безпека на рівні «написали в системному промпті»; і вільне володіння баззвордами, яке після уточнювального питання стає розмитішим, а не чіткішим.

Скільки років досвіду повинен мати AI-інженер?

Прикладній LLM-інженерії в нинішньому вигляді близько трьох років, тож вимоги на кшталт «5+ років досвіду з LLM» нереалістичні. Сильний сеньйорний профіль — це п'ять і більше років загальної розробки плюс один–три роки production-роботи з LLM.

Чи варто давати тестове завдання?

Коротке — може спрацювати: дві-три години, близько до вашої реальної задачі, з подальшою розмовою про ухвалені рішення. Виходьте з того, що кандидат користувався AI-інструментами для кодингу, — це і є робота. Ви оцінюєте, чи перевірив він власний результат і чи може пояснити компроміси. Довгі неоплачувані завдання відлякують найкращих кандидатів, у яких є інші офери.