Application tracker і career workspace

1. Пошук без workspace швидко перетворюється на хаос

Якщо подивитися на пошук роботи без системи, він дуже схожий на неохайну розробку без Git, без task spec і без нормального review. Вкладку з вакансією загублено, резюме валяється в завантаженнях, нотатки зі дзвінка — у месенджері, а через три дні ви вже не пам’ятаєте, що кому пообіцяли. Річ не в дисципліні. У процесу просто немає робочого контейнера.

До цього моменту у вас уже є щонайменше одна вакансія, що пройшла фільтр ролей і меж пошуку: для неї зібрано VACANCY_ANALYSIS.md і FIT_ANALYSIS.md, інколи вже й tailored package. Без єдиного контейнера все це знову роз’їдеться по вкладках.

Тут і з’являється career workspace — найпростіше думати про нього як про маленький проєкт усередині проєкту. Замість вихідних кодів там артефакти пошуку роботи: цільові ролі, аналіз вакансій, адаптовані документи, нотатки після інтерв’ю та центральний JOB_TRACKER.md.

У курсі ви звикли до формули, і в кар’єрі вона та сама:

Claude Code готує чернетки, структурує файли та пропонує оновлення.
Ви перевіряєте факти, читаєте зміни й лише потім затверджуєте відправлення або зміну статусу.

Це й є сенс слова human-approved. Щойно ви дозволяєте системі самій надсилати листи, самій змінювати історію спілкування та самій «покращувати» факти, ви отримуєте не workspace, а маленьку фабрику незручних ситуацій.

2. Склад career/ і його зручність

Хороший workspace не зобов’язаний бути складним — навпаки, чим він простіший, тим довше живе. Усе зберігаємо в текстових артефактах. Markdown виглядає скромно, майже старомодно — зате його чудово читає Claude Code, ви бачите diff і тримаєте зміни в Git.

Нижче — мінімальна структура, якої достатньо майже для будь-якого сценарію пошуку роботи:

career/
  target-roles.md
  search-boundaries.md
  RESUME_VARIANTS.md
  JOB_TRACKER.md
  jobs/
    co1-backend.md
  applications/
    co1-backend/
      VACANCY_ANALYSIS.md
      FIT_ANALYSIS.md
      TAILORED_RESUME.md
      COVER_LETTER.md
      INTERVIEW_NOTES.md
  templates/
    VACANCY_ANALYSIS.template.md
    FIT_ANALYSIS.template.md
    JOB_TRACKER.template.md
  INTERVIEW_FEEDBACK_LOG.md

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

Корисно також тримати зрозумілі імена папок. co1-backend/ краще, ніж Нової папки (7) або вакансії тієї самої: Claude Code менше плутається, а ви не займаєтеся археологією у файловій системі.

Нижче — компактна таблиця, яка показує роль ключових файлів:

target-roles.md

search-boundaries.md

JOB_TRACKER.md

jobs/

applications/[slug]/

templates/

INTERVIEW_FEEDBACK_LOG.md

Такий workspace краще тримати в private repo або локальному каталозі. Це не портфоліо, а робоча зона: допомагає ухвалювати рішення, а не справляти враження.

3. JOB_TRACKER.md як єдине джерело істини

Коли у вас з’являється кілька вакансій одночасно, пам’ять починає шкодити: здається, що в Co1 вже був screening, а в Co2 ви обіцяли приклади з тестування — хоча це третя компанія. JOB_TRACKER.md виконує ту саму роль, що й issue board у розробці: показує, що активне, що чекає на дію, а що закрите. Зручно ділити його на розділи:

# JOB_TRACKER.md

## Активні заявки

| Company | Role | Applied | Fit | Status | Next action | Evidence |
|---|---|---|---|---|---|---|
| Co1 | Backend Eng | 2026-05-10 | 80% | screening | підготувати приклади з pytest до 2026-05-15 | capstone, TEST_STRATEGY.md |
| Co2 | AI Product Eng | 2026-05-12 | 65% | applied | перевірити відповідь 2026-05-19 | MVP demo, README |

## Пайплайн

| Company | Role | Stage | Source |
|---|---|---|---|
| Co3 | Senior Eng | analyzed | LinkedIn |

## Відхилені / відкликані

| Company | Role | Stage | Reason |
|---|---|---|---|
| Co0 | Backend Eng | screening | salary mismatch |

## Індекс нотаток інтерв’ю
- Co1 → applications/co1-backend/INTERVIEW_NOTES.md

## Щотижневий огляд
- review_day: Sunday
- stale_rows: 1
- recurring_gap: production-scale CI/CD
- immediate_action:
  - написати follow-up у Co1

Якщо потрібен коментар на кшталт gap in team leadership, тримайте його в FIT_ANALYSIS.md або INTERVIEW_NOTES.md, а не в полі Stage.

Тут важливо не намагатися зробити tracker «розумнішим за життя»: він не повинен зберігати повний лист рекрутера, повний розбір вакансії та весь feedback одночасно. Для цього є окремі файли в applications/[slug]/. Рядок у ньому має відповідати на три питання: що це за заявка, на якому вона етапі й що робити далі.

Особливо важливі поля Status, Next action і Evidence. Status має бути коротким і зрозумілим. Не потрібно писати туди цілу історію на кшталт «з ними зідзвонилися, сказали, що цікаво, але треба подумати». Для цього є нотатки. Статус — це один етап: applied, screening, take-home, interview, rejected, withdrawn. Дату та формат дзвінка краще переносити в Next action або notes.

Поле Next action — це, по суті, один найближчий осмислений крок. Якщо там написано щось зробити пізніше, tracker мертвий. Якщо там написано підготувати історію про тести до 2026-05-15 — tracker живий. А Evidence корисно тримати як коротке посилання на артефакти з вашого банку доказів: capstone, TEST_STRATEGY.md, MIGRATION_PLAN.md, README, demo.

Зручна життєва траєкторія статусів виглядає так:

flowchart TD
    A[identified] --> B[analyzed]
    B --> C[tailored]
    C --> D[applied]
    D --> E[screening]
    E --> F[interview]
    F --> G[offer]
    F --> H[rejected]
    D --> I[withdrawn]

Слова не обов’язково саме такі. Важливо, щоб ви використовували один і той самий набір етапів. Інакше через два тижні в tracker одночасно з’являться call, screening, hr chat, first talk, conversation — і все це, сюрприз, виявиться одним і тим самим етапом.

4. Claude Code допомагає, але не діє за вас

На цьому етапі дуже легко перегнути палицю й вирішити: раз Claude добре працює з текстом, нехай сам оновлює tracker, сам пише follow-up і сам усе розкладає. Ідея звучить привабливо рівно до першого випадку, коли він упевнено переплутає дату інтерв’ю, змінить не той рядок або «покращить» ваш досвід до стану, в якому ви самі себе не впізнаєте.

Тому тут корисно жорстко розділити зони відповідальності:

Це той самий принцип, що й з кодом: Claude швидко готує робочу чернетку, а ви виконуєте human review. І, що особливо важливо, усі вихідні дії залишаються ручними. Claude може підготувати лист, але не надсилає його. Може оновити tracker, але спочатку показує diff. Може запропонувати, що спитати в рекрутера, але не вирішує за вас, чи варто взагалі писати.

Ось хороший приклад робочого запиту до Claude Code:

Відкрий /career/JOB_TRACKER.md і /career/applications/co1-backend/INTERVIEW_NOTES.md.
Підготуй лише draft-оновлення статусу, наступного кроку та follow-up date.
Нічого не надсилай назовні й не змінюй базовий resume.
Спочатку покажи diff.

А ось ще один корисний варіант, коли ви тільки додаєте нову вакансію:

Відкрий /career/jobs/co1-backend.md.
Створи папку /career/applications/co1-backend/.
Скопіюй туди шаблони VACANCY_ANALYSIS.md і FIT_ANALYSIS.md.
Нічого не вигадуй понад текст вакансії.
Після цього покажи список створених файлів.

Зверніть увагу, як ці запити обмежують scope. Це знову курс усередині курсу: task spec, межі та обов’язковий review працюють і в пошуку роботи.

5. Одна заявка від вакансії до статусу в tracker

Щоб усе це не залишалося абстракцією, давайте подивимося на один нормальний наскрізний сценарій. Вакансію Backend Engineer у Co1 ви зберігаєте в jobs/co1-backend.md, просите Claude підготувати VACANCY_ANALYSIS.md і FIT_ANALYSIS.md, бачите 80% fit — варто адаптувати резюме. У applications/co1-backend/ з’являється TAILORED_RESUME.md.

Далі, після ручної перевірки, ви надсилаєте заявку і лише потім оновлюєте JOB_TRACKER.md. Саме в такому порядку, а не навпаки: tracker відображає реальність, а не мрії про прекрасне майбутнє.

Дуже корисно бачити оновлення рядка як diff. До відповіді рекрутера:

- | Co1 | Backend Eng | 2026-05-10 | 80% | applied | чекати 7 днів | capstone, TEST_STRATEGY.md |

Після того як вам призначили screening, вона перетворюється на таку:

+ | Co1 | Backend Eng | 2026-05-10 | 80% | screening | підготувати історію про pytest та AI disclosure до 2026-05-15 | capstone, TEST_STRATEGY.md |

Видно дві важливі речі: статус і Next action стали конкретними та перевірюваними. Чим менше туманних формулювань у tracker, тим менше туману в голові.

Ця сама логіка працює і після інтерв’ю: «не забути, що їх збентежив слабкий CI/CD» кладеться в INTERVIEW_NOTES.md, а в tracker відображається найближча дія. Tracker залишається легким, докладна історія живе поруч.

Нижче — корисна схема потоку по одній вакансії:

flowchart TD
    A[Вакансія в jobs/] --> B[VACANCY_ANALYSIS.md]
    B --> C[FIT_ANALYSIS.md]
    C --> D[TAILORED_RESUME.md]
    D --> E[Відправлення заявки]
    E --> F[Оновлення JOB_TRACKER.md]
    F --> G[INTERVIEW_NOTES.md]

Зверніть увагу, що tracker тут не початок процесу, а його оперативне дзеркало. Так підготовка не плутається з реальними кроками.

6. Приватність, санітизація та місце workspace

Кар’єрний workspace майже завжди містить чутливі дані — не «секрети від спецслужб», звісно, але цілком особисте: листи рекрутерів, телефони, посилання на take-home, ваші нотатки після інтерв’ю, іноді внутрішні документи компанії. Тому важливо від самого початку ставитися до нього як до закритої робочої зони, а не як до репозиторію, який «потім, може, викладу на GitHub».

Зручно тримати просте правило у вигляді таблиці:

Якщо ви не впевнені щодо повного тексту вакансії — тримайте посилання й вичавку з must-have та responsibilities. А якщо зберетеся показати комусь фрагмент процесу — санітизація має бути автоматичною звичкою. Не Ірина Петрова, i.petrova@... сказала, що їм потрібна людина сильніша в CI/CD, а recruiter noted stronger CI/CD expectations.

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

7. Щотижневий огляд робить tracker живим

Будь-який tracker марний, якщо в нього не дивитися. Люди акуратно створюють JOB_TRACKER.md, два тижні чесно оновлюють — потім файл перетворюється на меморіал «тут колись велася активна робота». Рятує простий ритуал: один короткий щотижневий огляд.

Блок weekly-review зручніше тримати прямо в JOB_TRACKER.md, кількох рядків достатньо. Сенс не в тому, щоб роздувати бюрократію: раз на тиждень поставте tracker-у кілька нудних, але корисних запитань — які рядки застаріли, де прострочено next action, які заявки активні, чи не повторюється один і той самий пробіл у розмовах.

Claude Code чудово допомагає й тут, якщо й надалі тримати human-approved рамку:

Відкрий /career/JOB_TRACKER.md.
Знайди рядки, де next action прострочено або status не змінювався понад 7 днів.
Підготуй коротку weekly-review нотатку в markdown.
Нічого не надсилай і не змінюй статуси без мого підтвердження.

І в цьому місці відбувається, мабуть, найважливіше. JOB_TRACKER.md перестає бути просто табличкою про вакансії — він стає продовженням інженерної дисципліни, яку ви будували весь курс: єдине джерело істини, маленькі перевірювані зміни, зрозумілий наступний крок, обов’язкова ручна перевірка. Коли така система запрацювала, пошук роботи перестає бути безкінечною імпровізацією й стає керованим процесом.