Захист портфоліо під питанням «ви чи AI?»

1. Сенс запитання з боку інтервʼюера

На перший погляд це запитання звучить трохи підозріло, майже як «ага, спіймали». Але насправді добрий інтервʼюер не ловить вас на використанні ШІ. Він перевіряє приземленіше: чи можна довірити вам задачу так, щоб ви не принесли в проєкт гарну, впевнену й погано перевірену катастрофу. ШІ тут не центр проблеми — це інструмент, який підсилює і дисципліну, і хаос.

Коли вас запитують «це зробили ви чи AI?», насправді перевіряють одразу кілька шарів: чи розумієте ви код, чи просто спостерігали, як Claude друкує текст зі швидкістю кулемета, чи чесні ви настільки, щоб відрізняти «я спроєктував і перевірив» від «я натиснув кнопку і сподіваюся, що всесвіт добрий».

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

2. Стислий захист проєкту до двох хвилин

На захисті capstone ви могли розповідати довше. На інтервʼю такої розкоші зазвичай немає: рекрутеру потрібна не десятихвилинна екскурсія репозиторієм, а коротка структурована відповідь із відчуттям «людина розуміє, що робила». Корисно думати про таку відповідь як про стиснену версію повного захисту — компактну упаковку того, що вже лежить у PROOF_OF_WORK.md, SPEC.md, README.md і PR-артефактах.

Нижче зручний розподіл за часом. Він не математичний, але дуже допомагає не розтікатися думкою по деревах.

Якщо говорити зовсім коротко, ваша двохвилинна відповідь — не «історія про Claude», а історія про інженерний контроль над задачею, де Claude був підсилювачем. Менш ефектно, ніж «я побудував SaaS за вечір», зате не розвалюється при першому уточненні. У наймі це цінується вище.

3. Чотири опори сильної відповіді

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

Перша опора — ownership. Тут важливі не загальні слова, а конкретні інженерні дії: не «я брав участь», а «я написав SPEC.md, зафіксував non-goals, ухвалював зміни за diff». Тут інтервʼюер бачить не оператора AI, а людину, яка керувала роботою.

Друга опора — роль Claude. Тут потрібна обережність: занизите до «іноді підказував» і прозвучить неприродно, завищите до «написав усе» і обнулите свою цінність.

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

Четверта опора — обмеження і наступний крок. Дуже багато хто боїться цього блоку, бо здається, ніби визнання обмежень послаблює відповідь. Навпаки: «цей шматок я б підсилив інтеграційними тестами, а тут звузив би scope заради demo-ready версії» звучить надійніше, ніж загадково ідеальний проєкт. Бездоганний capstone такий само правдоподібний, як принтер, що завжди друкує з першого разу.

Ось мінімальний каркас відповіді, який можна тримати в голові:

Я вирішував задачу [яку саме] і сам відповідав за постановку задачі,
межі змін і фінальне рішення щодо diff.

Claude допомагав мені в [дослідженні / чернетках / сценаріях тестів / docs].

Після цього я вручну перевіряв [diff, тести, основний сценарій, обмеження].

Якби я продовжував проєкт, наступним кроком я б покращив [що саме].

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

4. Привʼязка відповіді до артефактів, а не до слів

Сильна усна відповідь майже завжди тримається на невидимій внутрішній опорі: ви знаєте, який файл, PR і шматок evidence стоїть за кожним тезисом. Звідси точність: мова інженерних слідів, а не «про відчуття».

Тут дуже допомагає просте правило: на кожен важливий тезис — уявний якір-артефакт. Ставили задачу — SPEC.md або TASK_SPEC.md. Робили review — REVIEW_NOTES.md, PR або diff-walkthrough. Перевіряли результат — тести, smoke steps, demo script. Оформіть це прямо в INTERVIEW_NARRATIVES.md, щоб не тримати в голові:

## Питання: did you build this, or did AI build it?

Що робив я:
- написав `SPEC.md`
- зафіксував scope і non-goals
- ухвалював фінальний diff

Де допоміг Claude:
- дослідження codebase
- чернетка реалізації
- пропозиції щодо тестів

Що я перевіряв:
- `REVIEW_NOTES.md`
- smoke-check за `DEMO.md`
- 6 регресійних тестів

Якщо спростити ще сильніше, то для різних рівнів зазвичай працюють різні «якірні» артефакти.

Це не означає, що Junior не можна говорити про PR, а Senior — про demo. Просто у кожного рівня свої найпереконливіші точки опори. Тримайтеся за них — відповідь звучить із реального досвіду.

5. Відповіді на незручні уточнювальні запитання

Головне запитання майже ніколи не приходить одне — зазвичай за ним ідуть уточнення. І ось тут інтервʼю раптово стає дуже корисним: є структура — ви не розсипаєтеся; немає — починається сумна імпровізація «ну, ми там якось разом із Claude це довели». Краще до такого не доводити.

Візьмімо один приклад. На «Що саме ви перевіряли вручну?» слабка відповідь звучить так: «я подивився, що все працює». Сильна звучить інакше: «читав diff, проганяв smoke-сценарій із DEMO.md, перевіряв крайній випадок із порожнім вводом і переконувався, що регресійний тест падає до фіксу та проходить після». Видно дію, порядок і артефакт.

А якщо звучить запитання «Що ви б не делегували AI?», не йдіть у пафос «я взагалі все розумію сам». Набагато сильніше спокійна межа: Claude — для дослідження, чернеток і тестів, але не для фінального merge, секретів, руйнівних операцій і продакшена. Це показує risk model, а не ентузіазм.

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

6. INTERVIEW_NARRATIVES.md і STAR-історії

На інтервʼю погано працює стратегія «я все скажу за натхненням»: натхнення — річ прекрасна, але дуже любить зникати під поглядом людини, яка щойно запитала про змістовні тести. Набагато надійніше тримати файл із відповідями на 6–8 типових запитань і пару односторінкових історій за схемою STAR: Situation, Task, Action, Result.

INTERVIEW_NARRATIVES.md потрібен не для того, щоб заучити текст, як актор шкільного театру, а як стабілізатор: у голові правильні рейки (ownership, роль Claude, перевірка, обмеження), і ви говорите живо, але не розвалюєтеся. Його й папку STAR_stories/ зручно тримати в тому ж career/, де вже лежать PROOF_OF_WORK.md і NARRATIVE_MAP.md. Тоді усна версія історії не живе окремо від доказів.

Мінімальна структура файла може бути такою:

# INTERVIEW_NARRATIVES.md

## Це зібрали ви чи AI?
[коротка 2-хвилинна відповідь]

## Що ви перевірили вручну?
[коротка відповідь з артефактами]

## Що ви б не делегували AI?
[межі та ризики]

А окрема STAR-історія може виглядати так:

# STAR_stories/capstone-bugfix.md

Situation: у capstone був ризик регресії в основному сценарії.
Task: виправити поведінку і не розширити scope.
Action: написав `SPEC.md`, попросив Claude підготувати чернетку,
додав регресійний тест, прочитав diff, прогнав smoke-check.
Result: основний сценарій запрацював, 6 тестів зелені, README оновлено.

Чому це працює добре? Тому що STAR-історія змушує говорити не абстрактно, а через епізод. Технічний інтервʼюер майже завжди краще сприймає конкретний випадок, ніж філософію: «я вмію працювати з AI дисципліновано» слабше за історію з однією задачею, одним ризиком, однією перевіркою і одним результатом. Ще один корисний нюанс: у кожної історії — коротка версія (60–90 секунд) і довга, на випадок, якщо співрозмовник захоче піти глибше: ви не імпровізуєте наново, а розгортаєте готовий матеріал.

7. Слабка, нормальна і сильна відповідь

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

Слабка відповідь

Ну, якщо чесно, Claude багато чого написав. Я йому пояснив ідею, він згенерував код, потім я щось поправив. Загалом проєкт вийшов робочим, тому можна сказати, що ми зробили його разом.

Ця відповідь погана не тим, що згадано Claude, а тим, що немає ні ownership, ні артефактів, ні перевірки, ні меж. Після такого інтервʼюер не розуміє, що саме ви контролювали.

Нормальна відповідь

Я використовував Claude як помічника під час розробки capstone. Сам я задавав, що саме потрібно зробити, дивився зміни й перевіряв, що основний сценарій працює. Claude допоміг із частиною коду та документацією.

Це вже краще: зʼявилися ownership і перевірка. Але все ще занадто загально — незрозуміло, які саме рішення були ваші й на що можна спиратися.

Сильна відповідь

У цьому проєкті я сам зібрав SPEC.md, зафіксував scope і non-goals, а потім вів реалізацію маленькими кроками. Claude допомагав мені в трьох місцях: дослідження codebase, чернетки реалізації та пропозиції щодо тестових сценаріїв. Після кожного кроку я читав diff, проганяв smoke-check за DEMO.md і окремо перевіряв регресійний тест на основний сценарій. Тобто Claude пришвидшував роботу, але фінальне рішення щодо змін і перевірки було моїм. Якби я продовжував проєкт, наступним кроком я б підсилив інтеграційні перевірки й чесно звузив би один спірний шматок README, де зараз надто оптимістично описано майбутній функціонал.

Тут уже є все, що потрібно: ownership, роль Claude, ручна перевірка, обмеження і навіть зріле зауваження про наступний крок. Така відповідь не звучить як виправдання — це розповідь інженера про процес.

І в цьому, мабуть, уся суть лекції. Ви відповідаєте про AI не з позиції захисту, а з позиції керованого інженерного процесу — і розмова перестає бути про «чи підмінив вас інструмент». Вона про те, чи вмієте ви ставити задачу, утримувати межі, перевіряти результат і чесно говорити про якість. У такій відповіді чути не шум навколо ШІ, а вас самих. А карʼєрний пакет, привʼязаний до артефактів, перестає бути вітриною «в стіл»: його вже можна додавати до реальних вакансій, адаптувати під роль і вести через job tracker без імпровізації на ходу.