Резюме, портфолио и рассказ о проектах

Зачем это нужно

У кандидата без опыта работы в ML нет строчки «три года ML-инженером в компании X», на которую может опереться рекрутер. Ваши доказательства — проекты. И их у вас больше, чем у многих: одиннадцать проектов с автотестами, своя LLM с техническим отчётом, домашние работы «как на работе», журнал обучения. Проблема в упаковке. Репозиторий без README никто не откроет, пункт «изучал трансформеры» никто не дочитает, а историю о баге без числа никто не запомнит.

Этот урок — про то, как превратить сделанное в курсе в материалы для всех этапов из урока 11.3.1: резюме для отклика и скрининга, портфолиопортфолиоEN portfolioНабор проектов, по которым работодатель может проверить ваши навыки: репозитории с README, числами, графиками и демо, технический отчёт, посты. Для кандидата без опыта работы — главный аргумент. и рассказ о проектах для технических секций, истории для поведенческого интервью, подход к тестовому заданию и к разговору об оффере.

flowchart LR
J["Журнал, LOG.md,<br/>mistakes.md"] --> R["README<br/>и отчёт проекта"]
M["metrics.json<br/>и графики"] --> R
R --> CV["Резюме:<br/>3–4 проекта,<br/>пункты с числами"]
J --> S["6–8 историй<br/>по STAR"]
CV --> I["Собеседование:<br/>рассказ о проекте,<br/>поведенческие вопросы"]
S --> I

Из чего собирается рассказ о себе: каждое число в резюме ведёт к README и metrics.json, а каждая история — к записи в журнале

Что у вас уже есть

Артефакт	Где лежит	Что доказывает
Проекты P1–P11 с автотестами (таблица на странице «О курсе»)	homework/, ваши решения	навыки по всему циклу LLM: от автограда до сервиса с расчётом мощностей
Выпускной проект P9 и технический отчёт	модуль 10.1	самостоятельный полный цикл: решения, абляции, неудачи, числа
ДЗ «как на работе»: s11-hw01 (грязные данные), s11-hw02 (чужой код, 10 тихих багов), s11-hw03 (инцидент)	модуль 11.1	работа с реальными проблемами, а не с учебными
DESIGN.md из s11-hw04-capacity	модуль 11.2	проектирование системы с числами
Журнал journal/, LOG.md выпускного, mistakes.md, lab.md	корень репозитория	даты, числа, баги и решения — сырьё для историй STAR

В резюме помещаются 3–4 проекта. Выбирайте их под роль, а не по порядку курса:

Целевая роль	Главный проект	Ещё 2–3 проекта
LLM/AI-инженер приложений	P9 — агент и сервер	P8 (RAG и агент), P7 (сервис инференса), P11 (расчёт мощностей)
ML-инженер	P9 — полный цикл	P3 (GPT с нуля), P5 (LoRA), s11-hw01 (грязные данные)
Research engineer	P9 — DDP на 4 GPU	P10 (гроккинг), P4 (MLA и MoE), P6 (GRPO)
Инференс и MLOps	P7 — квантование и бенчмарк	P11, P9 (квантование и сервер), s11-hw03 (инцидент)

Резюме на одну страницу

Структура

Резюме просматривают быстро, и решение «читать дальше» принимают по верхней трети страницы. Для junior всё важное помещается на одну страницу, а вторая обычно состоит из списка технологий, который никто не дочитает. Порядок разделов:

1. Шапка: имя, город и часовой пояс, телефон или Telegram, почта, ссылки на GitHub и LinkedIn или блог. Возраст и семейное положение для решения о найме не нужны. Фото — по желанию: в международных резюме его обычно не ставят.
2. Заголовок и 2–3 строки о себе: роль, что умеете, самый сильный результат.
3. Проекты — главный раздел для вас вместо «Опыта работы».
4. Навыки — сгруппированные и только те, что подтверждены проектами.
5. Опыт работы — прошлая профессия коротко, с упором на то, что пригодится в ML.
6. Образование — вуз, курс, английский.

Пункт = действие + способ + результат

Каждый пункт отвечает на три вопроса: что вы сделали, как и что из этого вышло. Формула: глагол-результат («построил», «нашёл», «сократил», а не «участвовал» или «изучал») + объект + метод или технологии + результат с числом и масштабом.

Числа нужны по двум причинам. Во-первых, их проверяют: «recall@5 с 0.62 до 0.81» можно воспроизвести, а «улучшил поиск» — нет. Во-вторых, каждое число — приглашение спросить «как вы это мерили?». Это лучший вопрос, который вы можете получить, потому что ответ на него вы знаете. Отсюда главное правило: в резюме — только те числа, которые вы можете воспроизвести командой и объяснить: на каких данных, против какого бейзлайна, с каким разбросом.

Числа в примерах ниже либо взяты из условий заданий курса, либо условны. Подставляйте свои из metrics.json.

Слабо	Сильно
Участвовал в проекте по RAG	Собрал поиск для RAG без внешних сервисов: чанкинг, BM25 и TF-IDF со слиянием RRF; recall@5 вырос с 0.62 до 0.81 на 60 вопросах
Изучал трансформеры, обучил GPT	Обучил с нуля LLM на ≈236M параметров (RMSNorm, RoPE, SwiGLU) на 4 млрд токенов на 4× RTX 4080 (DDP, bf16) за 14 ч
Отвечал за отладку кода	Нашёл и исправил 10 тихих багов в чужом PyTorch-проекте (утечка train/val, маска внимания, расписание lr); loss вернулся в коридор +0.06 нат/символ от энтропии корпуса; добавил регрессионные тесты
Знаком с квантованием	Реализовал INT8 и INT4 по группам, AWQ и GPTQ; INT8-версия своей модели в 3.9 раза меньше fp32 при потере точности 0.8 п.п.
Мы сделали агента	Написал агента с инструментами (JSON-схемы, ReAct-цикл, защита от инъекций): 64% задач против 31% у модели без калькулятора

Ключевые слова

Резюме сначала читает не человек, а поиск. Рекрутер фильтрует отклики по словам из вакансии, во многих компаниях для этого есть система учёта кандидатов (ATS). Отсюда три правила:

• используйте точные слова вакансии, если они правда про вас: PyTorch, LoRA, vLLM, RAG, DDP;
• пишите термины правильно — PyTorch, а не Pytorch. Об этом прямо предупреждают китайские шаблоны резюме: небрежность в названиях интервьюер замечает первой;
• каждое слово из раздела «Навыки» должно встречаться хотя бы в одном пункте проекта. Иначе это просто список, а на собеседовании спросят про каждое слово.

Без опыта работы: честно и сильно

• Называйте учебное учебным. «Выпускной проект курса ChinaAI» — нормальная строчка. Если выдать курсовой проект за коммерческий опыт, это вскроется на втором уточняющем вопросе, и после этого вам не поверят ни в чём.
• Подчёркивайте, что сделали сами: решения и их причины, масштаб (4 GPU, 236M параметров, 4 млрд токенов), числа, что пошло не так и как вы это нашли. Учебный проект с честным разделом о неудачах выглядит сильнее «коммерческого», о котором кандидат ничего не может рассказать.
• Прошлая профессия — актив. Логист знает, откуда берутся данные о доставках, бухгалтер — как устроены документы, учитель — как объяснять. В ML-командах предметная область ценится: это готовое понимание данных и метрик.
• Шкала навыков — честная: «уверенно», «есть опыт», «знаком». В «знаком» не пишите то, о чём не выдержите трёх вопросов подряд.

Шаблон резюме

Квадратные скобки — места для ваших данных. Сохраняйте резюме в PDF, файл называйте по имени и роли (Ivanov_ML_engineer.pdf), а не resume_final_v3.pdf.

# Имя Фамилия
ML-инженер (LLM) · [Город], UTC+3 · [готов к удалённой работе / переезду]
[телефон или t.me/username] · [почта] · github.com/[username] · [LinkedIn или блог]

[Прошлая роль, N лет]; последние [N] месяцев — ML и LLM. Обучил с нуля LLM на 4 GPU (претрейн → SFT → GRPO
→ квантование → сервер → агент) и описал её в техотчёте; собрал RAG и агента. Ищу позицию junior ML/LLM-инженера.

## Проекты
**Своя LLM от токенизатора до агента** · выпускной проект курса ChinaAI · github.com/[username]/[repo] · [год]
- Обучил модель на ≈236M параметров на 4 млрд токенов на 4× RTX 4080 (DDP, bf16) за [N] ч; val loss [X]
- Дообучил SFT и GRPO с проверяемой наградой: +[N] п.п. на [N] отложенных задачах (95% ДИ [a; b])
- Квантовал в INT8 с потерей [N] п.п.; поднял OpenAI-совместимый сервер; агент с калькулятором решает [N]% задач
- Написал техотчёт на [N] страниц: 2 абляции, проверка контаминации, раздел о неудачных попытках

**RAG по русским документам** · github.com/[username]/[repo]
- Собрал поиск без внешних сервисов: чанкинг, BM25, TF-IDF, слияние RRF; recall@5 [X] → [Y] на [N] вопросах
- Ответы с цитатами и проверкой, что цитата есть в источнике; [метрика качества ответа]

**Отладка чужого проекта** · кейс курса ChinaAI
- Нашёл и исправил 10 тихих багов в PyTorch-проекте языковой модели (утечка train/val, маска внимания,
  расписание lr, режим eval); loss вернулся в коридор +0.06 нат/символ от энтропии контрольного корпуса
- Описал каждый баг (симптом → как нашёл → исправление) и добавил регрессионные тесты

## Навыки
- Уверенно: Python, PyTorch, NumPy, pandas, Git, Linux
- Есть опыт: LoRA, GRPO, vLLM, квантование (INT8/INT4, AWQ, GPTQ), RAG, DDP/FSDP, FastAPI, Docker
- Знаком: Triton, SGLang
- Английский: [уровень]; читаю статьи и документацию

## Опыт работы
**[Должность]**, [Компания] · [годы]
- [1–2 пункта с результатом: данные, автоматизация, аналитика — то, что пригодится в ML]

## Образование
- ChinaAI — курс по AI и LLM с нуля, [N] часов, 11 проектов с автотестами · [годы]
- [Вуз, специальность, год]

Частые ошибки

Ошибка	Почему плохо	Как исправить
Список технологий без проектов	не видно, что вы с ними делали	каждая технология — в пункте проекта
«Изучал», «знаком», «участвовал» в пунктах	это процесс, а не результат	глагол-результат и число
«Мы сделали…»	непонятен ваш вклад	«построил», «нашёл»; про команду — в рассказе
Две-три страницы для junior	важное тонет	одна страница, 3–4 проекта
Ссылка на пустой или неряшливый GitHub	хуже, чем без ссылки	README по шаблону ниже или не давать ссылку
Числа, которые не можете объяснить	первый же вопрос их обесценит	только воспроизводимые числа из metrics.json

GitHub и README проекта

Профиль

• Закрепите 4–6 репозиториев, первым — выпускной проект. Профильный README — на 3–5 строк: кто вы, что ищете, ссылки на лучшие проекты.
• Качество важнее «зелёных квадратиков» активности. Интервьюер откроет один-два репозитория, а не график коммитов.
• Что публиковать. Репозиторий курса приватный, и в нём лежит ваш журнал. Для портфолио заведите отдельные публичные репозитории. Решения ДЗ как есть не выкладывайте: это спойлер для других учеников, а заготовку писали не вы. Сильнее выглядит развитие: выпускной проект, RAG по своей теме на основе P8, гроккинг с новым экспериментом на основе P10. Код курса распространяется по лицензии MIT, поэтому сохраняйте упоминание источника. Так же указывайте MiniMind, nanoGPT и другие проекты, на которые опирались.
• Секреты. Перед публикацией проверьте всю историю git, а не только последний коммит: git log -p | grep -inE "api[_-]?key|token|secret|password" | head. Ключ, однажды попавший в публичный репозиторий, считайте утёкшим: отзовите его и выпустите новый.

README, который читают за 5 минут

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

# mini-llm-ru — своя LLM на 236M параметров: от токенизатора до агента

Модель обучена с нуля на русских текстах на 4× RTX 4080, дообучена SFT и GRPO, квантована в INT8
и отвечает через OpenAI-совместимый API. Агент с калькулятором решает [N]% задач.

![демо](docs/demo.gif)

## Результаты
| Этап | Метрика | Значение (95% ДИ) |
|---|---|---|
| Претрейн | val loss, нат/токен | [X] |
| GRPO | точность на [N] отложенных задачах | [X]% ([a]–[b]) |
| INT8 | потеря точности | [X] п.п. |
| Агент | доля решённых задач, pass^3 | [X] |

![кривая обучения](report/fig/loss.png)

## Быстрый старт
```bash
git clone https://github.com/[username]/mini-llm-ru && cd mini-llm-ru
pip install -r requirements.lock.txt
bash run_all.sh configs/xs.yaml      # весь конвейер на крошечной модели за [N] минут
```

## Как устроено
BPE-токенизатор → претрейн → SFT → GRPO → квантование → сервер → агент.
Код этапов — в `src/`, конфиги — в `configs/`, метрики запусков — в `runs/<этап>/metrics.json`.

## Эксперименты
Технический отчёт: report/README.md — абляции (награда за формат: есть/нет; группа 4 или 8),
неудачные попытки, проверка контаминации train/eval.

## Ограничения
- Модель маленькая: [чего не умеет]; на задачах длиннее [N] токенов точность падает до [X]%.
- Eval-набор — [N] задач одного типа; на других доменах модель не проверялась.

## Воспроизводимость
4× RTX 4080 32 ГБ (PCIe, без NVLink); полный прогон configs/xl.yaml — [N] ч; seed 42; версии — requirements.lock.txt.

## Благодарности и лицензия
Основано на курсе ChinaAI (код — MIT), идеях MiniMind (Apache-2.0) и nanoGPT (MIT). Лицензия проекта — MIT.

Почему именно так:

• Результаты наверху. Это то, ради чего открыли README. Таблица с интервалами показывает, что вы понимаете шум измерений (урок 1.3.4).
• Быстрый старт на крошечном конфиге. Интервьюер не будет ждать 14 часов, а вот запуск за пять минут на ноутбуке может и сделать. ВоспроизводимостьвоспроизводимостьEN reproducibilityВозможность получить тот же результат, повторно запустив тот же код на тех же данных. держится на трёх вещах: зафиксированные версии (pip freeze > requirements.lock.txt, урок 4.6.5), seed и запуск всего конвейера одной командой.
• Демо. GIF или короткое видео терминала: вопрос → ответ модели → вызов инструмента. Живой пример убеждает быстрее таблицы.
• Ограничения. Раздел в духе карточки моделикарточка модели (model card)EN model cardДокумент к модели: назначение, где применять нельзя, данные, метрики (в том числе по группам), ограничения (Mitchell и др., 2019).: где модель работает, где нет и что не проверено. Честные ограничения — плюс, а не минус: они показывают, что вы понимаете свой результат.

Отчёт и технический блог

Технический отчёттехнический отчёт (техотчёт)EN technical reportТак лаборатории описывают свои модели. Это не рецензируемая статья, хотя часть отчётов позже публикуют в журналах (DeepSeek-R1 — в Nature). выпускного проекта (урок 10.1.2) — самый сильный ваш аргумент. Он показывает не только что получилось, но и как вы думали: почему такой масштаб, что дали абляцииабляционный эксперимент, абляцияEN ablation studyУбрать или заменить один компонент и сравнить с полной моделью, чтобы измерить вклад этого компонента., какие попытки провалились и почему. Положите его в репозиторий как report/README.md и дайте ссылку из резюме.

Блог — следующий шаг. Три-пять постов лучше, чем ни одного. Темы есть прямо в курсе: «Как я нашёл 10 тихих багов в чужом проекте», «Гроккинг на четырёх RTX 4080: что совпало со статьёй, а что нет», «Сколько GPU нужно LLM-сервису: расчёт на салфетке». Публикуйте там, где читают инженеры: на Хабре, на своём сайте на GitHub Pages. Структура поста как у мини-отчёта: задача, числа, график, что не получилось, ссылка на код. Блог работает на вас трижды: текст проверяет ваше понимание (урок 11.4.4), интервьюеры читают его до встречи, а посты находят через поиск.

Рассказ о себе и о проекте

О себе за 2 минуты

Вопрос «Расскажите о себе» звучит на каждом скрининге. Ответ — не биография, а три части: откуда вы пришли (одна фраза), что умеете сейчас (курс и два лучших проекта с числами), что ищете и почему именно эта компания. Пример:

Десять лет я работал в логистике аналитиком и автоматизировал отчёты на Python. Полтора года назад ушёл в ML: прошёл курс от основ до своей LLM. Главный проект — модель на 236 миллионов параметров, которую я обучил с нуля на четырёх видеокартах, дообучил с подкреплением и вывел в API с агентом. Всё описано в техотчёте. Ещё я собрал RAG по русским документам. Ищу позицию junior LLM-инженера. Вашу команду выбрал потому, что вы делаете поиск по документам доставки, а эти данные я знаю изнутри.

Цель — 1.5–2 минуты. Запишите себя и расшифруйте запись, как в тренажёре из урока 11.3.1.

О проекте: пять частей

На технических секциях почти всегда просят «расскажите о проекте, которым гордитесь». Структура из пяти частей годится и на 2 минуты, и на 10:

1. Задача и зачем: что строили и почему это трудно.
2. Ваш вклад: что именно сделали вы.
3. Ключевое решение и альтернативы: что выбрали, что отвергли и почему.
4. Результат с числом: против какого бейзлайна и как мерили.
5. Что не получилось и что сделали бы иначе.

На 10 минутах добавьте схему конвейера, два-три эксперимента и числа. Затем интервьюер начнёт копать. Заранее ответьте себе на типовые вопросы: «Почему такой размер модели?», «Какой был бейзлайн?», «Как проверили, что нет утечки или контаминации?», «Что будет при 10-кратном росте данных или пользователей?», «Что бы вы сделали иначе?». На каждый вопрос нужен ответ с числом или ссылкой на эксперимент.

Поведенческое интервью: метод STAR

На поведенческом интервьюповеденческое интервьюEN behavioral interviewСекция собеседования, где спрашивают о прошлом опыте: «расскажите о случае, когда…». Проверяют, как вы работаете — с ошибками, конфликтами, неопределённостью, сроками. Отвечают историями по методу STAR. спрашивают о прошлом опыте: «Расскажите о случае, когда…». Логика простая: то, как вы действовали раньше, лучше всего предсказывает, как будете действовать дальше. Ответ — история, а не мнение. «Я всегда тщательно тестирую код» ничего не доказывает. История о конкретном баге с числами доказывает.

Метод STARметод STAREN STAR methodСхема рассказа о своём опыте: Situation (ситуация) → Task (ваша задача) → Action (что сделали лично вы) → Result (результат, лучше с числом). Часто добавляют вывод: чему научились и что сделали бы иначе. — каркас такой истории:

Часть	Что сказать	Доля времени
Situation — ситуация	где и когда, что было не так; одна-две фразы	~10%
Task — задача	за что отвечали лично вы, какое было ограничение	~10%
Action — действия	что сделали вы, по шагам и с причинами решений	~60%
Result — результат	что изменилось, лучше с числом	~10%
Вывод	чему научились, что делаете теперь иначе	~10%

Вся история занимает 2–3 минуты. Главные ошибки — долгая ситуация («сначала расскажу про курс…»), «мы» вместо «я» и результат без числа. Интервьюер оценивает вас, а не команду. Про команду скажите одной фразой, а действия опишите свои.

6–8 историй заранее

Поведенческие вопросы повторяются от компании к компании, поэтому истории готовят заранее и по темам. Одна хорошая история часто закрывает два-три вопроса. Сырьё — ваш журнал: LOG.md выпускного, mistakes.md, записи lab.md.

№	Тема	Как спросят	Заготовка из курса
1	Сложный баг	«Самый трудный баг, который вы чинили?»	s11-hw02: loss ниже энтропии корпуса → утечка и маска внимания
2	Провал эксперимента	«Расскажите о неудаче»	GRPO в выпускном: награда растёт, точность стоит — модель «взломала» награду за формат
3	Своя ошибка	«Когда вы ошиблись и как исправили?»	eval-набор не заморозил вовремя → проверка нашла пересечение с train, пересчёт всех чисел
4	Неопределённость	«Задача без чёткой постановки»	выбор масштаба выпускного по бюджету FLOPs (10.1.1)
5	Компромисс	«Трудное техническое решение»	этап квантования выпускного (P9, механика — из P7): INT4 или INT8 — память против точности, порог потери ≤ 3 п.п. из критериев 10.1.1
6	Быстро освоить новое	«Как вы учитесь?»	MLA по техотчёту DeepSeek и китайским разборам → своя реализация в P4
7	Несогласие	«Вы не согласились с коллегой…»	ревью в учебной группе, PR в open source (11.4.2), прошлая работа
8	Давление и сбой	«Когда всё сломалось»	постмортем из s11-hw03 (11.1.4) или сорванный срок на прошлой работе

Истории о конфликтах и работе в команде у самоучки беднее, чем у тех, кто работал в ML. Берите их из прошлой работы, даже если она не про IT: поведенческое интервью проверяет поведение, а не технологии. Учебные группы и open source тоже дают такой опыт.

Пример 1: сложный баг

S. В курсе мне достался чужой проект — посимвольная языковая модель на PyTorch. Она обучалась без единой ошибки, но в README был заявлен val loss 0.51 за 600 шагов, а у меня он стоял около 3.4, и генерация выдавала набор букв. T. Найти причину без готовых тестов, исправить точечно и описать каждое исправление для ревьюера. A. Сначала я записал симптомы, не открывая код. Потом проверял инварианты: loss на старте должен быть около $\ln V$, а вход и цель первого батча — сдвинуты на один символ. На этом нашёлся первый баг: цели не были следующими символами. После нескольких исправлений loss упал до 0.06, но корпус составлен из случайных слов, и ниже ~0.4 нат/символ честная модель опуститься не может. Значит, модель где-то видела ответ. Я менял последний символ входа и смотрел, какие логиты меняются, — так нашёл ошибку в причинной маске. Пересечение train и val поймал на «тексте» torch.arange(1000), где у каждой позиции свой id. R. Нашёл все 10 багов: loss на контрольном корпусе вернулся в коридор от −0.03 до +0.06 нат/символ от энтропии, два запуска с одним seed совпадают побитово. Каждый баг описал по шаблону «симптом → как нашёл → исправление» и добавил регрессионный тест, который падает на исходном коде. Вывод. Баги маскируют друг друга: исправленный первый может сделать картину «слишком хорошей». Теперь любую отладку я начинаю с инвариантов — loss на старте и нижней границы loss.

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

Пример 2: провал эксперимента

S. В выпускном проекте я дообучал свою модель через GRPO на задачах с проверяемым ответом. T. Цель — поднять точность на отложенных задачах хотя бы на 10 п.п. A. Средняя награда за 300 шагов выросла почти вдвое, но точность на отложенном наборе не сдвинулась. Я перестал смотреть на кривую и прочитал 50 ответов модели. Почти все были в идеальном формате, но с неверным числом: награда за формат перевешивала награду за правильность, и модель научилась получать её даром. Я уменьшил вес формата, добавил проверку, что ответ — число, и поставил абляцию «награда за формат есть или нет» с тремя seed. R. Без отдельной награды за формат точность выросла на [N] п.п. против исходной модели, и я описал этот случай в разделе отчёта «Неудачные попытки». Вывод. Награда — это прокси. Теперь в каждом RL-эксперименте я раз в N шагов читаю сэмплы, а не только графики.

Эта история — заготовка: все числа и детали замените своими из LOG.md. Если с вами такого не случалось, не выдумывайте: у вас наверняка был свой провал, и он сработает лучше.

Вопросы работодателю

В конце почти каждого собеседования спрашивают: «Есть ли у вас вопросы?». «Нет» — упущенная возможность: вопросы показывают, что вы думаете о работе, и дают вам данные для решения. Как оценивать ответы — в уроке 11.3.1. Заготовьте 3–4 вопроса из этого списка под конкретного собеседника:

• О задачах: чем я буду заниматься первые три месяца? Как вы поймёте через полгода, что я справился?
• О ML-зрелости: как модель попадает в продакшен? Как вы меряете качество и что делаете, когда оно падает?
• О команде: сколько в команде ML-инженеров и кто будет моим наставником? Как устроено код-ревью?
• О данных и железе: откуда данные и кто их размечает? Есть ли свои GPU или бюджет на API?
• О росте: как обычно растут junior в вашей команде? Есть ли бюджет на обучение и конференции?
• Показать, что готовились: «Я читал ваш пост о переходе на гибридный поиск. Почему вы выбрали реранкер, а не дообучение эмбеддингов?»

Тестовое задание

Как делать

1. Уточните условия до начала: сколько времени ожидают, по каким критериям оценят, можно ли пользоваться ИИ-помощниками и внешними моделями, в каком виде сдавать.
2. Ограничьте время и скажите об этом. «Потратил 6 часов; вот что сделал бы, будь у меня ещё день» — сильный ход, а не признание слабости. Инженер, который умеет остановиться, ценится выше того, кто полирует бесконечно.
3. Сначала бейзлайн и честная валидация (урок 2.4.4), потом улучшения. Тестовое без бейзлайна — первое, к чему придерутся.
4. README по шаблону выше: запуск одной командой, решения и их причины, результаты с числами, ограничения, что дальше.
5. Код как на работе: понятная структура, тесты на ключевые функции, фиксированный seed, без закомментированного мусора.
6. Сдайте в срок. Если ответа нет неделю, вежливо спросите о результате.

Где граница бесплатной работы

Тестовое — нормальная часть найма, но иногда за ним прячется бесплатная работа. Признаки:

Нормально	Настораживает
объём до одного рабочего дня (наш ориентир — 4–8 часов)	неделя и больше
учебная задача или обезличенные данные	реальная задача компании, решение которой можно сразу использовать
ждут прототип и рассуждения	ждут продакшен-качество, деплой, документацию для команды
обещают разбор результата	«мы свяжемся», без критериев оценки

Что делать, если задание настораживает: спросите, сколько времени на него рассчитывают; предложите ограничить объём; предложите вместо него разобрать ваш готовый проект — портфолио нужно ровно для этого; спросите, оплачивается ли задание. Отказаться — нормально. Как компания реагирует на такие вопросы, само по себе многое о ней говорит.

Переговоры об оффере: принципы

Конкретных цифр здесь нет и не будет: они зависят от рынка, города, грейда и устаревают за месяцы. Принципы же стабильны.

1. Готовьте вилку заранее по 2–3 свежим обзорам (где их искать — в уроке 11.3.1): желаемая сумма и минимум, ниже которого не пойдёте.
2. Обсуждайте пакет целиком: задачи, наставник, грейд, формат работы, испытательный срок, оборудование и доступ к GPU, бюджет на обучение, деньги. Для первой работы наставник и задачи весят не меньше зарплаты: они определяют, где вы будете через два года.
3. Оффероффер (предложение о работе)EN job offerОфициальное предложение о работе после собеседований: должность, грейд, зарплата и другие условия, дата выхода. Условия оффера обсуждают до подписания — это и есть переговоры об оффере. — письменно, со всеми условиями. Устные обещания при выходе на работу часто «вспоминают иначе».
4. Несколько дней на решение — нормальная просьба. Давление «ответьте сегодня» — тревожный знак.
5. Не блефуйте. О других офферах можно сказать, если они правда есть. Придуманный оффер легко проверить встречным вопросом.
6. Аргументируйте рынком и своей ценностью — проектами, числами, близостью опыта к задачам команды, — а не личными обстоятельствами.
7. Отказывайте вежливо. Мир ML тесен, и через год вы можете захотеть вернуться в эту команду.

Практика

Задание в браузере: линтер резюме и историй

Проверьте свои пункты и истории так же, как ruff проверяет код. Правила — из урока: глагол-результат, без «я» и «мы», с числом, не длиннее 30 слов; в истории STAR есть все части, а Action — самая длинная.

Линтер пунктов резюме и историй STAR6 тестов

import re

# Линтер резюме: как ruff для кода, только для пунктов резюме и историй STAR.
# Правила — из урока: пункт начинается с глагола-результата, без «я» и «мы», с числом и не длиннее 30 слов.

# Первые слова, с которых начинаются пункты-«обязанности» вместо пунктов-результатов.
WEAK_STARTS = {
    "участвовал", "участвовала", "помогал", "помогала", "изучал", "изучала", "занимался", "занималась",
    "работал", "работала", "отвечал", "отвечала", "знаком", "знакома", "ознакомился", "ознакомилась",
}
# Местоимения: в пунктах резюме их опускают («Построил…», а не «Я построил…»), а «мы» прячет ваш вклад.
PRONOUNS = {"я", "мы", "мой", "моя", "мои", "наш", "наша", "наши"}


def lint_bullet(bullet, max_words=30):
    """Список кодов замечаний к одному пункту резюме — строго в таком порядке (только сработавшие):

    "weak-verb" — первое слово (без знаков препинания .,;:!?—-«»() по краям, в нижнем регистре) есть в WEAK_STARTS;
    "pronoun"   — среди слов пункта (re.findall(r"[a-zа-яё]+", bullet.lower())) есть слово из PRONOUNS;
    "no-number" — в пункте нет ни одной цифры;
    "too-long"  — слов (bullet.split()) больше max_words.
    Пример: lint_bullet("Участвовал в проекте по RAG") → ["weak-verb", "no-number"].
    """
    # TODO: ваш код
    ...


def lint_resume(text, max_words=30, page_words=600):
    """Проверяет всё резюме. Пункт — строка вида «- текст», «• текст» или «* текст» (пробелы в начале допустимы).

    Возвращает словарь:
      "bullets"  — число пунктов;
      "clean"    — число пунктов без замечаний;
      "issues"   — список (номер строки с 1, коды lint_bullet) для пунктов с замечаниями, по порядку строк;
      "words"    — число слов во всём тексте (text.split());
      "one_page" — True, если слов не больше page_words (в задании считаем, что столько помещается на страницу).
    """
    # TODO: ваш код
    ...


def star_check(story):
    """Замечания к истории STAR: story — словарь с ключами "situation", "task", "action", "result".

    По порядку:
      "missing:<часть>" — для каждой из четырёх частей (в этом порядке), если её нет или она пустая после strip();
      "result-no-number" — результат есть, но в нём нет ни одной цифры;
      "action-short" — action есть, но какая-то другая непустая часть длиннее его по числу слов (split());
      "action-we" — в action есть слово «мы», но нет слова «я» (слова — как в lint_bullet).
    """
    # TODO: ваш код
    ...


SAMPLE = """Проекты
- Участвовал в проекте по RAG
- Построил RAG по 1200 статьям: гибридный поиск с реранкером поднял recall@5 с 0.61 до 0.83
- Мы обучили модель
Навыки: Python, PyTorch"""
print(lint_bullet("Участвовал в проекте по RAG"))       # ['weak-verb', 'no-number']
print(lint_resume(SAMPLE))
print(star_check({"situation": "Курс, ДЗ s11-hw02", "task": "Найти тихие баги",
                  "action": "Мы долго искали ошибки в коде", "result": "Всё заработало"}))

ЗапуститьПроверитьПодсказкаСбросить

Локально: собираем материалы

1. Резюме. Заполните шаблон, вставьте текст в lint_resume и исправьте всё, что нашёл линтер. Помните, что линтер — помощник, а не судья: «Сделал RAG на Python 3.11» он пропустит, хотя цифра здесь — версия, а не результат.

2. README выпускного проекта — по шаблону, затем проверка в чистом окружении (блок ниже).

3. Истории. Заведите journal/stories.md и запишите 6–8 историй по STAR: темы — из таблицы урока, факты — из журнала. Прогоните каждую через star_check, а две запишите голосом и послушайте.

4. Пробное поведенческое интервью с ИИ. Промпт:

   Ты — нанимающий менеджер на поведенческом интервью на позицию junior LLM-инженера.
   Задай мне по очереди 4 вопроса вида «Расскажите о случае, когда…» на темы: сложный баг, неудача,
   несогласие с коллегой, задача без чёткой постановки. После каждого ответа задай один уточняющий вопрос.
   В конце оцени каждый ответ по STAR: есть ли ситуация, задача, мои личные действия, результат с числом,
   вывод; где я говорил «мы» вместо «я»; что звучало неубедительно. Не хвали без причины.

5. ИИ-ревью резюме. Отдайте резюме и текст вакансии с промптом: «Ты — технический рекрутер в ML. Вот вакансия и моё резюме. Найди: пункты без результата; ключевые слова вакансии, которых нет в резюме, хотя мои проекты их покрывают; числа, которые вызовут вопросы; всё, что можно убрать. Не переписывай резюме за меня — задай 3 вопроса, ответы на которые помогут усилить пункты». Как проверять замечания ИИ — в уроке 11.4.4.

🖥 На вашей машине (4×GPU)

Проверьте README так, как это сделает интервьюер — в чистом окружении, на XS-конфиге и одной карте:

git clone https://github.com/[username]/mini-llm-ru /tmp/readme-check && cd /tmp/readme-check
python -m venv .venv && source .venv/bin/activate      # пустое окружение: всплывут забытые зависимости
pip install -r requirements.lock.txt
CUDA_VISIBLE_DEVICES=0 bash run_all.sh configs/xs.yaml  # минуты, а не часы; остальные три карты свободны

Упало — значит, у интервьюера тоже упадёт. Чаще всего забыт пакет в requirements, путь к данным или файл, который лежал только у вас.

Демо. Запись терминала делает утилита asciinema (asciinema rec demo.cast), а GIF из неё — agg demo.cast docs/demo.gif. Для живого показа на собеседовании заранее поднимите сервер выпускного проекта на одной карте, за 10 минут до встречи проверьте его запросом curl к /v1/models и держите запись на случай сбоя сети или драйвера. Подробнее о машине — на странице «Ваша лаборатория».

Китайский угол: резюме, «опыт проектов» и правило STAR

Китайские открытые руководства по резюме («цзяньли») во многом совпадают с этим уроком, но есть и различия.

• AI-Job-Resume — шаблоны резюме на AI-позиции с разделом «На что обратить внимание в резюме». Одна страница. Навыки — по шкале «владею», «хорошо знаю», «знаком», и прямое предупреждение: не пишите то, чего не знаете, — интервьюер спросит. В проектах и на стажировках — 2–3 пункта с техническими деталями и метриками (автор приводит mAP и FPS из компьютерного зрения). Термины — с правильным регистром: Faster R-CNN, YOLO, PyTorch, а не Pytorch. Есть и местная специфика: автор советует фото на документы и рейтинг или средний балл в вузе. Для китайского набора выпускников («сяочжао») это обычная практика.
• JavaGuide — популярное руководство для разработчиков (лицензия Apache-2.0). Шаблон «опыт проектов» («сянму цзинли»): описание, стек, личный вклад, результат. Эффект советуют измерять: «время ответа с 2 с до 0.2 с». Там же описаны правило STAR и правило FAB (Feature — Advantage — Benefit: в чём ваша сильная сторона, чем вы лучше других, что получит работодатель). FAB удобен для блока «о себе» в шапке резюме. По объёму автор мягче: для набора выпускников — до двух страниц, для найма с опытом — до трёх. И одно место, с которым мы не согласны: автор допускает брать в резюме модули, которые делали не вы, если вы в них разобрались, «слегка приукрасив». Для проектов курса это прямой путь провалиться на уточняющих вопросах. Пишите только своё.
• «Цзыво цзешао» (рассказ о себе) в сборнике Deep-Learning-Interview-Book рассчитан на 3 минуты: вуз и направление исследований, стажировка (что делали и какой результат), соревнования с местом, статьи с экспериментальными результатами. Структура та же, что у нашего двухминутного рассказа, только с упором на студенческий опыт.

Домашняя работа

s11-hw05-ml-coding — «Тренажёр ML coding: 10 функций с нуля» — домашняя работа модуля 11.3. Условие, уровни и как решать её «как на собеседовании» — в уроке 11.3.4 и в homework/s11-hw05-ml-coding/README.md. Строка «ML coding на Strong» есть и в чек-листе готовности к первой работе из урока 11.4.5.

python homework/check.py s11-hw05-ml-coding

Проверь себя

Проверь себя6 вопросов·

1 Какой пункт резюме сильнее всего?

Изучал RAG и векторный поискУчаствовал в разработке RAG-системыСобрал поиск для RAG: BM25 и TF-IDF со слиянием RRF; recall@5 с 0.62 до 0.81 на 60 вопросахОтличное знание RAG, LangChain, векторных баз, эмбеддингов, реранкеров

2 Что должно быть в README, чтобы интервьюер оценил проект за 5 минут?Можно выбрать несколько ответов

Результаты с числами и графиком в началеБыстрый старт на крошечном конфиге в 2–3 командыЧестный раздел «Ограничения»Полная история всех экспериментов по дням

3 Какой части истории по STAR отдают больше всего времени?

SituationTaskActionResult

4 Вам предложили тестовое: «рекомендательная система для нашего каталога на наших данных, с деплоем, срок 7 дней». Что разумнее всего?

Молча сделать всё в срок, чтобы произвести впечатлениеСпросить ожидаемое время и критерии, предложить ограничить объём или разобрать готовый проект, уточнить, оплачивается ли заданиеСделать за ночь половину и сдать без READMEОтправить решение из интернета

5 Сколько кодов замечаний вернёт lint_bullet из задания для пункта «Мы участвовали в разработке модели»?

6 Какие действия соответствуют базовым принципам переговоров об оффере?Можно выбрать несколько ответов

Попросить оффер письменно со всеми условиямиОбсуждать пакет целиком: задачи, наставника, формат, обучение, деньгиУпомянуть несуществующий оффер, чтобы поднять ставкуПопросить несколько дней на решение

Проверить ответы

Итоги

• Без опыта работы ваши доказательства — проекты курса. В резюме 3–4 проекта под целевую роль, и каждый пункт построен по формуле «действие + способ + результат с числом». Числа — только те, что вы можете воспроизвести и объяснить.
• README читают за 5 минут: результаты наверху, быстрый старт на крошечном конфиге, честные ограничения, воспроизводимость. Техотчёт выпускного и посты в блоге показывают, как вы думаете.
• На поведенческом интервью отвечают историями по STAR, и основное время уходит на ваши действия. 6–8 историй готовят заранее из журнала, а вопросы работодателю — под конкретного собеседника.
• Тестовое делают в ограниченное время, с бейзлайном и README. Неделя бесплатной работы над реальной задачей компании — повод для вопросов, а не для подвига. Оффер обсуждают целиком, письменно и без блефа.

Хороший проект для портфолио — сервис, собранный через спецификации вместе с ИИ-агентом, с честным отчётом, где агент ошибся и как вы это поймали: такой отчёт показывает инженерное мышление лучше любого списка технологий. Шаблон — в выпускном проекте программы SDD.

Дальше: урок 11.4.1 — воспроизводим статьи: как дорасти от «понимаю» до «умею» и получить ещё один сильный проект для портфолио.