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 перестаёт быть просто табличкой про вакансии — он становится продолжением инженерной дисциплины, которую вы строили весь курс: единый источник истины, маленькие проверяемые изменения, понятный следующий шаг, обязательная ручная проверка. Когда такая система заработала, поиск работы перестаёт быть бесконечной импровизацией и становится управляемым процессом.

1

Задача

Claude code, 34 уровень, 3 лекция

Недоступна

Документация по структуре career workspace

Документация по структуре career workspace

Открыть