# Кейс: Wildberries (Вайлдберриз) · Team Lead

| Поле | Значение |
|------|----------|
| Компания | Wildberries (Вайлдберриз) |
| Вакансия | Тимлид (Team Lead) |
| Платформа | уточнить (hh / реферал / прямой контакт) |
| Дата отклика | уточнить (пользователь откликался ранее) |
| Статус | 🟡 HR-скрининг ✅ → кодинг ⏭ (пропущен по рекомендации) → системный дизайн (сегодня) |
| След. шаг | 12.10.2026 — секция системного дизайна |

Трек задачи: **TASK-53**.

## Контекст и воронка

Отклик отправлен ранее (точную дату и канал пользователь не помнит — нужно уточнить).
Пользователь проходит процесс **по рекомендации** — поэтому этап кодинга пропускается.

| # | Этап | Статус |
|---|------|--------|
| 1 | Отклик | ✅ (ранее, детали уточнить) |
| 2 | HR / рекрутер-скрининг | ✅ пройден успешно |
| 3 | Интервью (содержательное) | ✅ пройдено успешно |
| 4 | Кодинг / алгоритмы | ⏭ **пропущен по рекомендации** |
| 5 | Системный дизайн | 📝 назначен на 12.10.2026 |
| 6 | Следующие этапы (финал / оффер) | ⏳ ожидаются |

## Открытые вопросы (уточнить у пользователя)

- Точное название вакансии и её текст (для `vacancy.md` и разбора match/gap).
- Канал отклика: hh / реферал / прямой контакт; кто рекомендатель.
- Что уже рассказали о команде, продукте и стеке на скрининге/интервью.
- Формат следующих этапов (финал с руководителем? оффер?) и сроки.
- Формат работы (офис/удалёнка/гибрид), вилка.

## Анонс секции от HR (получен от рекрутера)

Приглашение на секцию проектирования (длительность — **до 1,5 ч**), текст рекрутера:

> Сергей привет! Спасибо тебе за интервью!
> Приглашаю тебя на секцию проектирования, по длительности до 1,5 ч.
>
> На данном этапе вам потребуются ваши навыки проектирования.
> Мы дадим вам задачу верхнеуровнево спроектировать какую-либо систему или часть системы. У вас будут бизнес-требования к этой системе. Ваша задача — понять что нужно построить, продумать, как вы можете это сделать, предложить инструменты, подходы и нарисовать схему. Как правило, первую половину времени мы тратим на верхнеуровневую схему, а вторую — уже погружаемся в детали и специфику некоторых компонентов и мест, которые вы изобразите на диаграмме.
>
> Как подготовиться к архитектурной секции:
> - Посмотрите ролики в интернете (их очень много), как обычно проходят подобные секции, почитайте статьи.
> - Самое главное, что вам нужно понять — это то, что же вы строите. Поэтому во время беседы не спешите сразу начинать рисовать, продумайте и проговорите вслух, что вы планируете делать, какой у вас план.
> - Подумайте, какие вопросы помогут вам понять особенности той схемы, которую вас попросят построить.
> - Уточните, в каком виде должна быть нарисована итоговая схема, что на неё должно попасть, а на что не стоит тратить время.
> - Изучите, какие подходы есть к отображению подобных схем.
>
> Ресурсы для подготовки к архитектуре:
> - Книги, наподобие "Cracking the IT Architect Interview".
> - Познакомиться с C4 моделью и подходами https://c4model.com/.
> - Посмотреть видео наподобие Twitter system design, проектируем <twitter, facebook, amazon>.
> - На сайтах типа leetcode, hackerrank, interviewbit — пройти разделы про System Design.

### Что это меняет относительно подготовки

- **Формат:** до 90 минут (шире нашего 60-минутного каркаса), деление «первая половина — верхнеуровневая схема, вторая — детали по компонентам с диаграммы» — совпадает с нашими этапами 1–3 (схема) → 4–5 (детали), оставляет больше времени на эксплуатацию.
- **Отдельно просят проговорить вслух план до рисования** — это наш принцип «руль у кандидата» + чекпоинты; делаем план явным первым ходом.
- **Уточнить формат диаграммы:** что должно попасть на схему, а что — нет. Наш ответ: C4-уровни 1–2 (контекст + контейнеры) крупно, компоненты — по узкому месту.
- **C4-модель** — новый пункт подготовки (context / container / component / code); уровни 1–2 — рабочая валюта секции.
- **Книга «Cracking the IT Architect Interview»** — источник к архитектурному треку.

## Подготовка к системному дизайну

Готовая база знаний и методичка по секции системного дизайна — в
[`../yandex-codenv/system-design/`](../yandex-codenv/system-design/README.md):
фреймворк 6 этапов с таймингом (`methodology.md`), числа и back-of-envelope
(`knowledge-base.md`), эталонные разборы (`classic-designs.md`), карточка-памятка
на секцию (`methodology.md` §7), топ-10 ошибок (`methodology.md` §4).

Формат у Wildberries может отличаться от яндексовского (другая длительность,
другой набор критериев), но каркас ответа переносится: требования → API →
крупноблочная схема → детали + БД → ресурсы и узкие места → эксплуатация.

### Что помнить на секции (шпаргалка)

- **Вести секцию самому** — «и что дальше?» должно звучать от интервьюера, а не от нас.
- **Сначала требования** (5–8 мин), записать в угол доски и не стирать — в конце свериться.
- **Числа с формулой вслух** (≥3): DAU → QPS avg/peak, storage с retention, bandwidth, ноды.
- **Трейдоффы вслух** (≥3): «два варианта: A проще, B строже; беру A, платим Y, компенсирую Z».
- **Гарантии вместо брендов**: «нужен in-memory KV с репликацией, ~100k RPS на ноду».
- **Не усложнять без необходимости** (KISS) и асинхронизировать всё, что не нужно для ответа клиенту.
- **Эксплуатацию не резать**: отказы по каждому узлу, graceful degradation, мониторинг, релизы.
- **Финал — возврат к требованиям**: каждое закрыто метрикой (маркер senior-ответа).

Топ-ошибки: прыгнуть в схему без требований; молчать и рисовать про себя; не записать
требования; усложнять; названия вместо свойств; решения без альтернатив; нет арифметики;
синхронный критический путь; увязнуть в деталях и не успеть эксплуатацию; не разобрать
частичные отказы хранилищ.