Portfolio defense под вопросом «вы или 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 без сочинительства на ходу.