AI на співбесіді QA

Що насправді перевіряє інтерв'юер питанням про AI?

Не знання інструментів, а твоє інженерне судження. Назви Claude Code чи MCP цікавлять інтерв'юера набагато менше, ніж те, чи бачиш ти, де модель економить години, а де тихо додає ризик. Питання про AI — це проксі (proxy): по тому, як ти розповідаєш про роботу з моделлю, зчитують твоє мислення загалом — чи розумієш межі інструмента, чи верифікуєш вивід, чи береш відповідальність за результат. Тобто це та сама перевірка, що завжди в QA, лише під новою обгорткою. Кандидат, який називає десять інструментів, але не пояснює, як ловить помилки моделі, програє тому, хто назве один, але покаже дисципліну перевірки.

Тебе питають «якими AI-інструментами користуєшся і для чого?». Як відповісти сильно?

Це базовий скринінг, і слабка відповідь — просто список назв. Сильна прив'язує кожен інструмент до конкретної задачі й показує, що ти пам'ятаєш про помилки моделі: не «користуюсь ChatGPT», а «беру модель, щоб накидати чернетку тест-кейсів за acceptance criteria, далі відсіюю дублі й дописую негативні сценарії руками». Одразу видно реальний досвід, а не знайомство з хайпом. Добре тут згадати й межу: де саме ти моделі не довіряєш і що через це перевіряєш окремо. Інтерв'юер хоче почути, що ти пробував інструмент на власній роботі, а не переказуєш рекламу.

Як розповісти про AI-досвід так, щоб це не звучало як набір базвордів?

Будувати розповідь навколо конкретної задачі за схемою: що треба було зробити, що з цього віддав моделі, як перевірив її вивід, який вийшов результат. Фраза рівня «використовую AI для підвищення ефективності тестування» порожня — жодного факту, задачі чи числа, і інтерв'юер чує генератор буліт-поїнтів. Натомість історія «розписував регресію платіжної форми, модель дала близько сорока кейсів, третину викинув як дублі, дописав пропущені негативні сценарії, виграв приблизно годину» показує три речі одразу: ти знаєш що делегувати, бачиш дефекти у виводі, чесно міряєш виграш. Одна така історія переважує десяток загальних тверджень. Тому на співбесіду варто прийти з двома-трьома заготовленими реальними кейсами з цифрами.

Що означає принцип «підпис завжди твій»?

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

AI згенерував тобі 40 тест-кейсів на форму. Як переконаєшся, що вони повні?

Повнота — це не кількість рядків, а покриття вимог, тож звіряю кейси з acceptance criteria вручну, а не довіряю числу «сорок». Моделі добре вдаються позитивні й очевидні сценарії, а от негативні й граничні вона регулярно пропускає — подвійне списання, порожні поля, значення на межах, конкурентні дії. Тому проходжу техніками тест-дизайну (класи еквівалентності, аналіз меж) і перевіряю, чи кожен клас вводу представлений, чи немає дублів, які модель любить плодити. Практично це виглядає як «викинути зайве, дописати пропущене, звірити з вимогами» — і саме цей етап, а не сама генерація, показує кваліфікацію. Зелений список із сорока пунктів нічого не вартий, якщо в ньому немає перевірки головного ризику фічі.

AI написав автотест, він зелений. Як переконаєшся, що він реально щось перевіряє?

Зелений колір без асерту не гарантує нічого — тест міг просто виконати кроки й завершитися. Перше, що роблю, — читаю, що саме тест асертить: якщо після кліку по кнопці немає перевірки спостережуваного результату (редирект, повідомлення, токен, стан у базі), то тест зелений просто тому, що нічого не перевіряє. Класична пастка від моделі — Playwright-тест, який заповнює форму, натискає submit і на цьому закінчується без жодного expect. Друга перевірка — запустити тест на свідомо зламаному стані: якщо він лишається зеленим там, де мав би впасти, він фальшивий. Саме вміння відрізнити «тест пройшов» від «тест щось перевірив» інтерв'юер тут і шукає.

Де ти AI не довіряєш і чому?

Найбільше — фактам, які виглядають упевнено, але модель могла їх вигадати: селектори, яких немає на сторінці, неіснуючі методи API, застарілі через knowledge cutoff версії та поведінку інструментів. Модель генерує текст, що виглядає правильним, — це не те саме, що правильний, так само як зелений тест виглядає робочим. Тому локатори я завжди звіряю з реальним DOM, сигнатури методів — з документацією, а будь-яке фактичне твердження — з першоджерелом. Окрема зона недовіри — приватність: закритий код, секрети чи персональні дані замовника в публічну модель не йдуть. Назвати ці межі на співбесіді — не слабкість, а ознака зрілості; кандидат, який каже «AI не помиляється», лякає більше за того, хто чесно перелічує пастки.

Що інтерв'юер спостерігає, коли на live-завданні дозволяють користуватися AI?

Не результат, а процес: як ти формулюєш задачу моделі й, головне, що робиш з її виводом. Мовчазний copy-paste без погляду на екран — миттєвий мінус, бо показує, що ти не читаєш згенероване. Дивляться, чи ловиш вигадане — коли модель упевнено кличе неіснуючий метод чи селектор, помітити це коштує половину оцінки. Оцінюють і те, як ти ітеруєш: сильно виглядає не «запущу той самий промпт ще раз», а «уточню контекст, бо модель не знала про наш data-testid». Плюсом іде й уміння сказати «тут швидше написати три рядки руками, ніж пояснювати їх моделі» — знання, коли AI зайвий, теж частина навички.

Чому відповідь «AI написав мені весь фреймворк» — слабка?

Бо вона звучить як «я не розумію, що там усередині». Приписати моделі свою роботу — не плюс, а сигнал, що на захисті рішення ти не поясниш власний код. Сильніше розділити ролі чесно: скелет чи бойлерплейт згенерувала модель, а архітектуру, політику локаторів і межі відповідальності визначав ти. Це показує і те, що ти вмієш делегувати рутину, і те, що контролюєш суть. Нездатність пояснити «свій» код гірша за скромніше, але повністю зрозуміле рішення.

Як використати AI для підготовки до співбесіди і в чому головна пастка?

Модель — сильний спаринг-партнер: попроси її бути суворим інтерв'юером на конкретну роль, ставити питання по одному з фідбеком, пояснювати концепції під твій рівень, генерувати каверзні питання на тему, якої боїшся, репетирувати самопрезентацію англійською. Усе це добре тренує форму відповіді під тиском. Але головна пастка — модель не джерело істини: через галюцинації та knowledge cutoff вона впевнено видасть застарілий факт, вигадану версію інструмента чи неправильне визначення. Найгірший сценарій — завчити це з чату й озвучити на інтерв'ю як власне знання з абсолютною впевненістю. Тому будь-яке фактичне твердження звіряй із першоджерелом (документація, силабус, специфікація); AI тренує подачу, а за зміст відповідаєш ти.

Тобі дають live-завдання. Як правильно повестися щодо використання AI з погляду етики?

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

У take-home частину зробив AI. Що спитають на захисті і як не завалитися?

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

Як тестувати фічу, всередині якої LLM?

Головна відмінність — недетермінізм: та сама вимога до моделі дає щоразу трохи різний вивід, тож точне порівняння рядків не працює. Замість expect(output).toBe(...) перевіряють семантику — чи містить відповідь потрібний факт, чи витримано формат, чи немає забороненого, — часто через окремі перевірки або допоміжну модель. Галюцинації тут не рідкісний збій, а окремий клас дефектів, який треба свідомо покривати. Основа — golden set: набір типових входів з еталонними очікуваннями, на якому ловлять регресію після зміни промпту чи моделі. Це питання «на виріст» для middle+, тож навіть без такого досвіду варто розуміти напрямок; глибше — у главі про тестування AI-застосунків.

Що таке eval і як би ти його побудував?

Eval — це систематична оцінка якості виводу моделі на наборі прикладів, по суті регресійний тест для промптів і самої моделі. Будується він навколо golden set: репрезентативні входи плюс критерії, за якими вважаємо відповідь доброю (фактична точність, повнота, формат, відсутність шкідливого). Частину критеріїв міряють автоматично, частину — через LLM-as-judge, коли одна модель оцінює вивід іншої за рубрикою. Тут важливо пам'ятати про упередження судді: він схильний до багатослівних відповідей, до власного стилю, тому його рішення теж треба калібрувати на розмічених прикладах. Далі eval ганяють при кожній зміні промпту чи версії моделі — і саме він ловить деградацію, яку на око не видно.

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

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

Чому вставити закритий код чи персональні дані в публічну модель — червоний прапорець на співбесіді?

Бо це витік даних і сигнал про твою гігієну роботи з інформацією загалом. Код під NDA, секрети, ключі чи персональні дані замовника, відправлені в публічний чат-бот, можуть осісти в логах сервісу й вийти за межі контролю замовника. На live-завданні необдумано вставлений чужий закритий код читається інтерв'юером не як спритність, а як ризик: якщо так робиш на співбесіді, робитимеш і в проді. Приватність тут — частина етики нарівні з чесністю, і сильний кандидат озвучує, що перед використанням моделі перевіряє, чи можна взагалі давати їй ці дані. Обхід проблеми — приватні чи локальні інстанси моделей та знеособлені приклади замість реальних даних.

Три розбори з реального інтерв'ю: та сама відповідь у слабкій і сильній редакції, пастка зеленого AI-тесту на live-завданні та таблиця рішень «довіряти виводу чи звіряти». Скрізь — що саме бачить інтерв'юер і чому.

Кейс 1. Одна відповідь, дві редакції

Питання інтерв'юера банальне: «Розкажи, як AI реально допоміг тобі в роботі». Нижче — та сама людина, той самий досвід, але дві подачі.

Слабка редакція:

«Я активно застосовую AI для генерації тест-кейсів і автоматизації рутини. Це суттєво пришвидшує роботу й підвищує ефективність тестування».

Сильна редакція:

«На регресію платіжної форми треба було розписати кейси. Я дав моделі acceptance criteria й попросив покриття за класами еквівалентності й межами. Вона видала близько сорока — третину я викинув як дублі, дописав негативні сценарії з подвійним списанням, які вона пропустила, і звірив покриття з вимогами вручну. Вийшла приблизно година проти двох з половиною».

Що дивитися і чому:

• Слабка редакція не містить жодного факту. Немає задачі, немає числа, немає дефекту — інтерв'юер чує генератор буліт-поїнтів і не може оцінити нічого, крім знайомства з модними словами.
• Сильна тримається на схемі задача → що зробив AI → як перевірив → результат. Кожен елемент навмисний: конкретна фіча (платіжна форма), делегована частина (генерація за критеріями), етап верифікації (викинув дублі, дописав пропущене, звірив з вимогами), чесна цифра.
• Найцінніше в сильній — згадка про пропущені негативні сценарії. Вона доводить, що кандидат бачить дефекти у виводі моделі, а не приймає сорок кейсів наосліп. Саме це, а не терміни з тест-дизайну, купує довіру.
• Цифра подана чесно, без перебільшення. «Година проти двох з половиною» звучить достовірно; «прискорення в 10 разів» без пояснення дало б протилежний ефект — червоний прапорець.

Кейс 2. Live-завдання: зелений тест, який нічого не перевіряє

На технічному етапі дозволили користуватися AI. Ти просиш модель написати Playwright-тест на форму логіну й отримуєш ось це:

test('user can log in', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Password').fill('secret');
  await page.getByRole('button', { name: 'Log in' }).click();
  // зелено — але жодного асерту
});

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

test('успішний логін веде на дашборд', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Password').fill('secret');
  await page.getByRole('button', { name: 'Log in' }).click();

  // результат, який видно ззовні: редирект + вітання
  await expect(page).toHaveURL(/\/dashboard/);
  await expect(page.getByRole('heading', { name: /Вітаємо/ })).toBeVisible();
});

Що дивитися і чому:

• Зелений колір без асерту не гарантує нічого. Перше питання до будь-якого AI-тесту — «що саме він асертить», а не «пройшов чи ні».
• Асерт має чіплятися за спостережуваний результат. Редирект на /dashboard, вітання, наявність токена — те, що ззовні доводить, що логін відбувся, а не просто «кнопку натиснуто».
• Перевір тест на зламаному стані. Введи неправильний пароль: справжній тест почервоніє, фальшивий лишиться зеленим. Проговорити цю перевірку вголос — сильний хід.
• Проговорювання процесу — половина оцінки. Інтерв'юер слухає не фінальний код, а те, чи ти помітив порожнечу й пояснив, чому додаєш саме ці перевірки.

Кейс 3. Таблиця рішень: приймати вивід чи звіряти з джерелом

Під час завдання модель видає різні типи тверджень, і на кожен потрібна своя реакція. Груба помилка — ставитися до всього однаково: або сліпо довіряти, або перевіряти навіть очевидне до знемоги.

Що дивитися і чому:

• Найнебезпечніший рядок — визначення й цифри. Їх легко завчити з чату й озвучити на інтерв'ю як власне знання; саме такий сценарій найгірший, бо звучить упевнено, а факт вигаданий.
• Селектори й API йдуть у зону обов'язкової звірки завжди. Модель не бачить твоєї сторінки й не знає про твій data-testid — вона правдоподібно домислює.
• Сортування за ризиком — теж навичка. Проговорити «код, який я розумію, приймаю швидко, а визначення завжди перевіряю» показує інтерв'юеру каліброване, а не панічне ставлення до моделі.

Що насправді перевіряє питання про AI

• Розумію, що питання про AI перевіряє судження (межі, верифікація, відповідальність), а не список інструментів.
• Можу пояснити, чому відповідь про AI — проксі інженерної зрілості, і чому «виглядає правильно» ≠ «правильно» однаково для виводу моделі й для зеленого тесту.
• Знаю цикл «задача → чернетка від AI → верифікація → у продукт під моїм підписом» і метафору «AI — стажер»: делегую генерацію, не відповідальність.

Розповідь про AI-досвід без базвордів

• Відрізняю порожню відповідь («підвищую ефективність тестування») від сильної — конкретна задача з числом за схемою задача → що зробив AI → як перевірив → результат.
• Тримаю напоготові два-три реальні кейси з цифрами: одна історія переважує десяток загальних фраз.
• Називаю межі як силу: «селектори модель вигадує, тому локатори звіряю з DOM».
• Не приписую AI свою роботу (розділяю «скелет — модель, архітектура — я») й уникаю слів-порожнеч без цифри.

Практичні завдання з AI

• Розумію, що на live-завданні оцінюють процес, а не результат.
• Впізнаю зелений Playwright-тест без асерту й додаю перевірку спостережуваного результату.
• Ловлю вигадане (неіснуючий метод, селектор поза сторінкою) — помітити це коштує пів оцінки.
• Ітерую осмислено (уточнюю контекст) і знаю, коли AI зайвий: три рядки швидше набрати руками.

AI як інструмент підготовки

• Використовую модель як спаринг-партнера: mock-співбесіда, пояснення під рівень, каверзні питання, репетиція самопрезентації.
• Пам'ятаю головну пастку: модель не джерело істини (галюцинації, knowledge cutoff).
• Будь-яке фактичне твердження звіряю з першоджерелом, а не завчаю з чату: AI тренує форму, зміст — на мені.

Етика й приватність на інтерв'ю

• Знаю правило «прозорість перемагає приховування» і що спійманий обман коштує репутації, а не лише вакансії.
• Питаю дозвіл на AI прямо й озвучую, що роблю, — це демонстрація навички, а не слабкість.
• На захисті take-home готовий пояснити кожен рядок і не ллю закритий код чи персональні дані в публічну модель.

Питання на виріст (middle+/senior)

• Пояснюю, чому недетермінізм LLM вимагає семантичних перевірок замість точного порівняння рядків.
• Розумію галюцинації як окремий клас дефектів і роль golden set у ловлі регресій.
• Знаю, що таке eval, LLM-as-judge та його упередження, і можу накидати впровадження AI в процес (політики, гейти, приватність, вартість, навчання).