Assessments, take-home і feedback loop

1. Заготовка зустрічається з ринком

Щойно рядок у career/JOB_TRACKER.md доходить до screening, take-home або interview, охайні файли перестають бути просто файлами в папці. Тепер вони проходять через обмеження роботодавця, тестові завдання та зворотний звʼязок, який іноді пише особливо втомлений лінтер.

Чесна відповідь «що робив я, а в чому допоміг Claude» у вас уже є — але поки INTERVIEW_NARRATIVES.md лежить собі спокійно, це лише заготовка. А щойно приходять реальні вакансії, виявляється, що питають вони різне: одна про CI/CD, інша про міграції, третя про Claude Code в capstone, четверта — чи читаєте ви власний diff без моральної підтримки.

Тому тестове завдання та скринінг варто сприймати не як окремий страшний світ, а як звичайне продовження всього курсу: той самий знайомий workflow — прочитати brief, перетворити його на маленький task spec, визначити scope, не дати задачі розповзтися, зробити верифікацію, залишити зрозумілі артефакти, пояснити рішення. Coding assessment — це маленький capstone з дедлайном і трохи меншою кількістю романтики.

2. Межа disclosure для AI у тестовому

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

Найзручніше тримати в голові таку таблицю.

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

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

Якщо AI дозволено, ситуація стає простішою, але не настільки, щоб розслабитися: вам усе одно потрібна disclosure boundary — межа чесного розкриття. Роботодавець має бачити, що ви не натиснули чарівну кнопку «зроби красиво», а тримали Claude Code у контрольованому режимі — розбити задачу на кроки, чернетка документації, перевірка граничних випадків, чорновик тестів. Відповідальність, розуміння архітектури, вибір trade-offs і пояснення рішення — за вами.

Практично це зручно оформлювати окремим файлом поряд із тестовим завданням, якщо політика дозволяє AI і ви хочете зняти зайві запитання заздалегідь:

# AI_USAGE.md

## Що робив я
- визначив scope
- обрав архітектуру
- перевірив diff і тести

## Де допоміг Claude
- запропонував чернетку тестів
- допоміг оформити README
- підказав граничні випадки

Якщо такий файл справді йде роботодавцю, його копія лежить поряд із take-home repo, а в career/applications/[slug]/ корисно тримати копію або посилання. Тоді двозначності не лишається: ви не ховаєте AI за спиною і не роздуваєте його роль до «усе побудував Claude, а я морально підтримував процес».

Є ще одне жорстке правило, яке варто повторювати собі перед будь-якою відправкою: ніколи не надсилайте код, який не зможете пояснити без Claude поруч. Це не питання моралі, це питання виживання на наступному інтервʼю. Якщо вас просять пояснити, чому тут саме такий запит до бази, а ви внутрішньо сподіваєтеся, що хтось терміново відкриє потрібну вкладку з чатом, — значить, матеріал ще не ваш.

3. Проходимо тестове за дозволеного AI

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

Найкорисніший підхід — проганяти тестове завдання через знайомий вам із курсу цикл. Спершу перетворіть brief на коротку інженерну постановку: що потрібно, чого ні, що вважається готовим, як перевірите. Навіть із пів сторінки тексту має вирости структура з модулів 3–4 — мета, scope, constraints, критерії приймання, план перевірки — і лише потім підключайте Claude Code.

Наприклад, хороший початок роботи може виглядати так:

Прочитай brief тестового завдання.
Не пропонуй код одразу.
Спершу поверни:
1. мету завдання,
2. scope і non-goals,
3. ризики,
4. мінімальний план перевірки,
5. запитання, якщо brief двозначний.

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

Далі, коли brief уже розібрано, Claude приносить реальну користь у чотирьох місцях. Перше — звузити scope і запропонувати реалістичну першу версію. Друге — згенерувати чернетку тестового каркаса, коли часу мало. Третє — reviewer на першому проході: подивитися diff, запитати про пропущені граничні випадки, перевірити межі завдання. Четверте — оформити README, AI_USAGE.md, пояснення архітектури та список обмежень.

Ось, наприклад, короткий шаблон для такого випадку:

# План виконання

## Область змін
- один основний сценарій
- базова валідація
- README із запуском

## Перевірка
- smoke-перевірка
- 3 тести
- ручний walkthrough

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

Якщо в тестовому завданні просять «зробити за 4 години», сприймайте це буквально: не як виклик всесвіту, не як запрошення зібрати половину SaaS-платформи, а як обмеження за часом — таймбокс. Якщо через дві години вже є робочий основний сценарій, не починайте в пориві натхнення добудовувати ще три необовʼязкові фічі. Роботодавець оцінює не обсяг страждань, а якість пріоритетів: «ось це must-have, а це я свідомо залишив у limitations» виглядає професійніше за перевантажений проєкт із недоробленим основним сценарієм.

І ще одна корисна річ: той самий AI_USAGE.md поряд із кодом знімає напругу заздалегідь і робить роботу прозорою:

# AI_USAGE.md

## Claude допоміг
- розібрати brief
- запропонувати структуру тестів
- оформити README

## Я перевірив сам
- основний сценарій
- валідацію входу
- фінальний diff

Так ви перетворюєте потенційно ніякову тему на звичайну інженерну документацію — жодної містики, просто traceability з модулів 24 і 33, застосована до ринку праці.

4. Навчальне інтервʼю з Claude: тренажер, а не суфлер

Навчальне інтервʼю з Claude корисне рівно до того моменту, поки воно допомагає вам говорити власними словами. Щойно Claude перетворюється на суфлера, ви вже не тренуєтеся — ви репетируєте читання чужого тексту з виразом. На живому інтервʼю це ламається швидко і з неприємним хрускотом.

Правильний формат тут такий: Claude грає роль інтервʼюера, ставить по одному питанню, чекає вашу відповідь, потім дає короткий feedback. Не пише відповідь за вас і не підказує «ідеальне формулювання» до вашої власної. Особливо добре це працює для трьох типів запитань: про capstone, про AI usage і про технічні trade-offs у вашому проєкті.

Нижче — простий шаблон для такого режиму:

Ти — інтервʼюер на позицію Middle Backend.
Став по одному запитанню.
Після моєї відповіді дай короткий feedback:
- що зрозуміло,
- що звучить слабко,
- що варто уточнити.
Не пропонуй готову відповідь за мене.

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

Особливо корисно проганяти через такий тренажер ваш чотирикроковий відповідь із модуля 33: що робив я, де допоміг Claude, що я перевірив, що покращив би далі. Один і той самий каркас відповіді адаптується під різні вакансії, але перевіряти його краще в контексті конкретної ролі. Backend Engineer — про API, верифікацію та тести. AI-assisted Product Engineer — про швидкість ітерацій, обмеження MVP і product judgment. Роль ближча до DevOps — про CI/CD, reproducibility і межі automation.

І тут важливо не намагатися виправити все після однієї невдалої відповіді. Одна запинка на запитанні про міграції не означає, що час міняти цільову роль, видаляти пів резюме й їхати в гори. Вона означає лише одне — у вашому feedback loop зʼявився новий сигнал.

5. INTERVIEW_FEEDBACK_LOG.md: відповіді в дані

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

Саме тому після кожного інтервʼю або тестового завдання корисно оновлювати INTERVIEW_FEEDBACK_LOG.md. Не як щоденник страждань, а як інженерний журнал: дата, компанія, етап, запитання, де відповідь була сильною, де є прогалина, яка дія з цього випливає. Такий файл робить із ринку не хаос, а систему спостережень.

Невеликий приклад:

# INTERVIEW_FEEDBACK_LOG.md

## 2026-05-15 — Co1
- запитали про CI/CD
- упевнено розповів про capstone і tests
- запнувся на production-scale monitoring
- дія: додати mini-project з CI matrix

Важливий не обсяг запису, а повторюваність. Одне інтервʼю — приватний випадок, а після трьох-пʼяти починають проявлятися патерни. Якщо три різні роботодавці запитали одне й те саме про production monitoring, це вже не «не пощастило з інтервʼюером», а повторювана прогалина. А повторювана прогалина — це вже вхід у нормальну роботу: оновити narrative, додати evidence або посунути цільові ролі.

Зручно навіть завести маленьку таблицю «сигнал → дія».

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

6. Безперервний цикл зворотного звʼязку і фінал курсу

Зараз ми підходимо до найважливішої частини всієї останньої лекції. Фінал курсу — це не момент, коли ви «стали готові назавжди», а момент, коли у вас зʼявився процес, який продовжує вас покращувати. Саме тому остання тема — про continuous feedback loop, безперервний цикл зворотного звʼязку.

Виглядає він дуже просто:

flowchart TD
    A[Вакансія] --> B[Fit-аналіз]
    B --> C[Тейлоринг]
    C --> D[Заявка]
    D --> E[Інтервʼю або тестове]
    E --> F[INTERVIEW_FEEDBACK_LOG.md]
    F --> G[Оновлення JOB_TRACKER.md]
    G --> H[Резюме, narratives, evidence]
    H --> A

Це, по суті, карʼєрна версія всього курсу: аналізуєте вхідний запит, обмежуєте scope, готуєте артефакти, проходите перевірку, читаєте feedback, оновлюєте систему. Якщо звучить знайомо — це не випадковість: ми просто перенесли мислення issue-to-PR на ринок вакансій.

Щоб цей цикл не залишався красивою схемою, йому потрібен ритм — наприклад, щотижневий огляд. Наприкінці тижня відкрийте career/JOB_TRACKER.md, career/INTERVIEW_FEEDBACK_LOG.md, PROOF_OF_WORK.md і поставте собі три спокійні запитання. Що сталося цього тижня? Який feedback повторюється? Що оновити — цільові ролі, narrative, резюме чи evidence bank? Такий огляд набагато корисніший за емоційну реакцію на кожну окрему відповідь.

Можна навіть тримати маленький службовий блок прямо в career/JOB_TRACKER.md: оновити статуси та next action, записати feedback тижня, знайти повторювані сигнали, обрати один артефакт на оновлення. Цього вже досить, щоб цикл не розповзався.

Зверніть увагу: пункту «переробити всю карʼєру за вечір» тут немає — і це не жарт, а важлива дисципліна. Реальні покращення зазвичай маленькі й регулярні. Один новий мініпроєкт під часту прогалину. Одна сильніша архітектурна нотатка до capstone. Одна краще сформульована відповідь про AI usage. Одна чесна корекція цільових ролей, якщо ви системно цілили вище або ширше, ніж дозволяє evidence bank.

До цього фінального моменту курсу у вас уже має бути цілком відчутний набір артефактів:

Ці артефакти не живуть самі по собі — вони починають працювати лише тоді, коли повʼязані в процес. Capstone як головний якір, PROOF_OF_WORK.md як доказова база, INTERVIEW_NARRATIVES.md як коротка чесна розповідь, JOB_TRACKER.md як панель керування, INTERVIEW_FEEDBACK_LOG.md як журнал сигналів — і ваші реальні дії щодо покращення.

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

І наступного разу, коли вам поставлять незручне запитання про AI, capstone або тестове завдання, це вже не буде раптовим ударом. Просто ще один вхідний сигнал, який ви спокійно розберете, запишете, перевірите й перетворите на наступний крок.