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 в контролируемом режиме — разбить задачу на шаги, draft-документация, проверка краевых случаев, черновик тестов. Ответственность, понимание архитектуры, выбор trade-offs и объяснение решения — за вами.

Практически это удобно оформлять отдельным файлом рядом с тестовым, если политика разрешает AI и вы хотите снять лишние вопросы заранее:

# AI_USAGE.md

## Что делал я
- определил scope
- выбрал архитектуру
- проверил diff и тесты

## Где помог Claude
- предложил черновик тестов
- помог оформить README
- подсказал edge cases

Если такой файл реально уходит работодателю, его копия лежит рядом с 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, спросить про пропущенные edge cases, проверить рамки задания. Четвёртое — оформить README, AI_USAGE.md, объяснение архитектуры и список ограничений.

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

# План выполнения

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

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

Обратите внимание, что здесь нет ничего магического: это просто маленький инженерный план, который спасает от хаоса. Чем короче дедлайн, тем нужнее такая опора.

Если в тестовом просят «сделать за 4 часа», воспринимайте это буквально: не как вызов вселенной, не как приглашение собрать половину SaaS-платформы, а как ограничение по времени — таймбокс. Если через два часа уже есть рабочий core flow, не начинайте в порыве вдохновения достраивать ещё три необязательные фичи. Работодатель оценивает не объём страданий, а качество приоритетов: «вот это 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, это уже не «не повезло с интервьюером», а повторяющийся gap. А повторяющийся gap — это уже вход в нормальную работу: обновить narrative, добавить evidence или подвинуть target roles.

Удобно даже завести маленькую таблицу «сигнал → действие».

Здесь есть одна тонкая, но важная мысль: стратегию меняет паттерн, а не единичное событие. Один отказ бывает про внутреннего кандидата, бюджет, тайминг, погоду на Марсе и ещё десяток причин не про вас. Но одно и то же замечание трижды подряд — это уже материал для реального улучшения.

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 повторяется? Что обновить — target roles, narrative, резюме или evidence bank? Такой обзор гораздо полезнее эмоциональной реакции на каждый отдельный отклик.

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

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

К этому финальному моменту курса у вас уже должен быть вполне осязаемый набор артефактов:

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

Именно поэтому правильное ощущение после последней лекции — не «ну всё, теперь я идеален», а скорее «теперь у меня есть нормальная система, с которой можно идти дальше». Рынок меняется, вакансии меняются, требования меняются, а хороший workflow остаётся с вами.

И в следующий раз, когда вам зададут неудобный вопрос про AI, capstone или тестовое, это уже не будет внезапным ударом. Просто ещё один входящий сигнал, который вы спокойно разберёте, запишете, проверите и превратите в следующий шаг.