---
title: Статья 01 — Фреймворк прохождения интервью и работа с требованиями
source: подготовлено 2026-09-18, TASK-45.41; каркас — brief.md §01; развёртка methodology.md §1–4, §7; источники — статья Яндекса (TASK-45.5), Alex Xu гл. 3 (TASK-45.38), видео Gabbard (TASK-45.9)
---

# Статья 01: фреймворк прохождения интервью и работа с требованиями

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

Почему это отдельный — и первый — раздел. Все остальные разделы брифа (числа, хранилища, кэш, отказы…) отвечают на вопрос «**что** я знаю», а этот — на вопрос «**как** я это показываю». Секция не проверяет знания списком: она смотрит на связный рассказ, который кандидат ведёт сам. Источники сходятся в трёх взглядах: Яндекс описывает формат («кандидат — основной участник беседы»), Alex Xu — каркас из 4 шагов («важен не столько результат, сколько процесс проектирования»), Gabbard — цену вопроса («архитектурная секция решает, какой уровень оффера дадут»). Формула одна: **руль у кандидата**.

Контекст нашей секции (Yandex Codenv, этап 2): ~60 минут, крупноблочная схема сервиса уровня «инстаграм/твиттер», отказоустойчивость — заявленный фокус.

## 1. Почему секция устроена как диалог, а не как викторина

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

1. **Молчать — проигрыш.** Интервьюер играет вторую скрипку и перехватывает инициативу только в крайних случаях. Если вопросы «и что дальше?» тянем от него — это минус независимо от качества схемы (кейс Gabbard: панель голосовала «берём», директор зарубил — «8 лет опыта и mindset "I don't know what's next"»). Полезная перенастройка из его же видео: относиться к секции как к **tech talk**, где мы объясняем коллеге, как будет устроена система.
2. **Спрашивать — норма.** Задача сформулирована свободно намеренно: детали нужно **вытащить** вопросами, а не домысливать молча. «Один из самых важных навыков инженера — умение задавать правильные вопросы» (Сюй). Быстрый ответ без обдумывания — плохой знак: «не будьте как Джимми».
3. **Нехватка данных — норма.** «Выдвигать обоснованные гипотезы можно и нужно» (Яндекс). Числа на секции выдуманы — и это нормально: проверяется не психометрия, а метод. Ошибка в 2 раза — не провал (мало серверов — докупим, много — пригодится на росте), ошибка в порядок величины — уже да.

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

## 2. Каркас: 6 этапов с таймингом

Статья Яндекса задаёт план секции пятью блоками (+доп. вопросы); наш фреймворк — те же этапы с бюджетом на 60 минут (тайминг — наш, структура — из первоисточника):

| # | Этап | Что происходит | Тайминг |
|---|------|----------------|---------|
| 1 | Требования | Функциональные и нефункциональные требования, числа-гипотезы, минус-объём; фиксируем на доске | 8 мин |
| 2 | Потоки и API | Сущности, 3–5 сигнатур, control plane vs data plane | 7 мин |
| 3 | Крупноблочная схема | Каркас из 5–8 блоков, путь горячего запроса | 5 мин |
| 4 | Детали + БД | Устройство 1–2 главных блоков, схема данных, ключевой алгоритм | 18 мин |
| 5 | Ресурсы и узкие места | Back-of-envelope: QPS, storage, bandwidth, ноды; где горлышко | 7 мин |
| 6 | Эксплуатация | Отказы по каждому узлу, мониторинг, релизы, возврат к требованиям | 10 мин |

Три свойства каркаса, которые делают его каркасом, а не таблицей для зубрёжки:

**Кольцо секции.** Секция начинается листом требований и заканчивается возвратом к нему: «проверим требования: SLO по латентности обеспечен запасом, доступность чтения — N+1 по всем ярусам, лимиты — rate limiter; вот чем каждое требование контролируем метрикой». Этот финальный ход статья Яндекса называет прямо, и «почти никто не делает» — а он же и есть сильнейший финал шага 4 у Сюя («узкие места, мониторинг, что обсудили бы при наличии времени»).

**Правило дефицита времени.** Не успеваем — режем детали и ресурсы (свёртываем до 2–3 оценок), но **эксплуатацию не режем никогда**: отказоустойчивость — заявленный фокус нашей секции, и именно этот этап отличает senior-ответ. Антипаттерн: 40 минут в деталях, отказы — «на бегу» в последние три минуты.

**Внутренний компас.** Интервьюер может водить по своему порядку — этапы не сценарий для спора. Выбило из колеи — мысленно возвращаемся к цепочке «требования → API → схема → детали → числа → эксплуатация» и встраиваем туда текущий вопрос. Сюй предупреждает то же: не уделять сразу слишком много времени одному компоненту — сначала общая архитектура, потом погружение.

## 3. Этап за этапом: что должно прозвучать

Короткая карточка на каждый этап — что делаем и что говорим. Полные карточки (цель → что на доске → что проговорить → грабли) — [`../methodology.md`](../methodology.md) §2, одностраничная шпаргалка на саму секцию — там же §7.

**Этап 1. Требования (8 мин).** Сузить задачу и получить числа, от которых считается весь дизайн. Проговариваем: функциональные требования (что делает система), нефункциональные (масштаб, латентность, доступность, консистентность, retention, лимиты), что мы **не** строим. Пишем в угол доски. Грабли: рисовать коробки на 20-й секунде — потом переделывать.

**Этап 2. Потоки и API (7 мин).** Зафиксировать контракт: сущности (Post, Account, Link…), 3–5 сигнатур, разделение control plane (управление, единицы RPS) и data plane (горячий путь). Проговариваем: протокол и почему, идемпотентность записей, коды ошибок. Грабли: писать «код» вместо скелета — сигнатуры нужны как каркас, две минуты и дальше.

**Этап 3. Крупноблочная схема (5 мин).** Каркас из 5–8 блоков: клиенты → балансировка → сервисы → кэш → хранилища → очереди. Проговариваем путь горячего запроса целиком — чтение и запись отдельно. Грабли: уйти в детали раньше времени — здесь только блоки и их роли; детали добираем на этапе 4.

**Этап 4. Детали + БД (18 мин, главная часть).** Инженерная глубина на 1–2 самых нагруженных компонентах (выбираем по числам из требований). Хранилище — по гарантиям и критериям, а не по названию («нужен in-memory KV с репликацией и ~100k RPS на ноду — подойдут Redis/Aerospike-класс»). Синхронизация хранилищ — с проговоренным частичным отказом. Всё не нужное для ответа пользователю — асинхронно. Кэш и шардирование — только если числа показывают, что надо. Грабли: проектировать «всё» и «сложно» — детализируем горячий путь, стандартное решение берём как есть.

**Этап 5. Ресурсы и узкие места (7 мин).** Показать, что дизайн сходится арифметически, и назвать горлышко раньше интервьюера. 3–4 расчёта по формуле «допущение → формула → число → вывод» (как считать — раздел 02, [`../knowledge-base.md`](../knowledge-base.md) §2). Грабли: считать молча; число без формулы не оценивается.

**Этап 6. Эксплуатация (10 мин).** Production-зрелость: топология 2–4 ДЦ, по каждому узлу схемы — «упал → что происходит → что в метриках», перегрузка в разы (rate limiting, load shedding, graceful degradation), мониторинг, релизы. Финал — возврат к листу требований (кольцо секции). Грабли: отдать этот этап «если останется время» — останется ли, зависит только от нас.

## 4. Работа с требованиями: ядро этапа 1

Это самая насыщенная часть раздела — то, ради чего каркас вообще существует. Подробные карточки вопросов и примеры — [`../methodology.md`](../methodology.md) §2 (этап 1) и разбор URL shortener в [`../classic-designs.md`](../classic-designs.md) §1; здесь — метод.

### 4.1 Функциональные требования: что строим и что НЕ строим

Функциональные требования — какие возможности реализуем: сценарии пользователей, read- и write-пути, приоритеты. Приём, экономящий полсекции, — **минус-объём**: зафиксировать, что мы *не* строим. «Аналитику и админку отмечаем, но не детализируем» — легальный способ сузить задачу, который интервьюер почти всегда принимает. Сюй про то же: у стартапа и у компании с миллионами пользователей разные архитектуры — «убедитесь, что вы понимаете требования», а не угадывайте масштаб.

### 4.2 Нефункциональные требования: договорённости о масштабе

Чек-лист, который прогоняем вопросами (или гипотезами, если интервьюер молчит):

| Тема | Что выясняем | Пример формулировки |
|------|--------------|---------------------|
| Масштаб | DAU/MAU, паттерны использования, read/write ratio | «10 млн DAU, чтение доминирует — 100:1?» |
| Нагрузка | RPS чтение/запись, среднее и пик (пик ×2–3 к среднему) | «500 тыс. RPS в пике — это среднее или пик?» |
| Латентность | latency-SLO, p95/p99, на какие операции | «150 мс для 95 % чтений?» |
| Доступность | сколько девяток и **на что именно** | «четыре девятки на чтение, три на запись?» |
| Консистентность | что строго, что eventual, допустимый лаг | «новые объекты — строго; правки — лаг в секунды?» |
| Retention | сколько храним, что удаляем | «ссылки без TTL удаляем через год?» |
| Лимиты/абьюз | квоты, ограничения бесплатного tier | «1000 запросов/мин на бесплатный аккаунт?» |

Зачем фиксировать «на что именно» девятки и что именно строго — эти уточнения потом становятся **фокусом дизайна**: «четыре девятки на чтение при eventual-ленте» означает N+1 по read-пути и никак не означает консенсус на каждый пост.

### 4.3 Числа-гипотезы: от «страшного» числа к рабочему

Массовые круглые числа из вводной («500 млн MAU») Gabbard зовёт **funny money** — на них нельзя покупать серверы. Проговариваем конверсию вслух, каждое звено — допущение: 500 млн MAU × 70 % → 350 млн DAU → × 70 % в час пика → 245 млн/час → ÷ 3 600 → ~68 тыс. одновременных → ÷ ёмкость ноды (1 000) → ~68 серверов. Из «невообразимых миллионов» получилось трактабельное число, от которого проектируется нода. Это и есть «работа техлида», за которую платят. Правило гигиены: каждое число сопровождаем словом «допущение» — «поправьте, если есть реальные цифры».

### 4.4 Диалог вместо допроса

Требования — не анкета, а разговор двух инженеров. Рабочий ритм: вопрос → ответ интервьюера → короткий вывод на доску → следующий. Примеры живых диалогов — таблица этапа 1 эталона URL shortener (объём переходов? — 500 тыс. RPS в пике; скорость? — 150 мс для 95 % чтений; согласованность? — новые ссылки строго, модификации — лаг в секунды) и диалог про ленту у Сюя (мобильное или веб? — оба; сортировка? — обратная хронологическая; сколько друзей? — 5 000; трафик? — 10 млн DAU). Важно: услышанное **сразу превращать в конструктив** — «значит, read/write 100:1 → дизайн про чтение».

### 4.5 Лист требований

Требования записываются в угол доски **и не стираются до конца**. Три причины: (1) от них считается весь дизайн — потеряли числа, считаем заново; (2) интервьюер подменяет вводную («а если ссылок не 1 млрд, а 100?») — сверяемся с листом и правим точечно; (3) финальный возврат к листу — обязательный ход этапа 6. Сюй советует то же: предположения записывать на доске или бумаге — «позже они вам пригодятся».

## 5. Управление секцией: держим руль

Каркас — половина раздела; вторая половина — как оставаться его хозяином 60 минут подряд.

**Чекпоинты вслух.** Переход между этапами проговариваем: «требования зафиксировали — перехожу к потокам», «схема рабочая — теперь детали по самому нагруженному блоку», «по ресурсам сходится — перехожу к отказам и мониторингу». Чекпоинт делает три вещи сразу: держит тайминг, показывает интервьюеру структуру и **легально отдаёт ему руль на секунду** — «детализировать глубже X или идём к ресурсам?». Вопрос с развилкой — единственный правильный способ «спросить, что делать» на секции.

**Хинт лучше ступора.** Застряли — вслух фиксируем, где мы («давай зафиксирую, где мы»), и если не сдвинулись — просим подсказку. Хинт слегка ослабляет оценку, но 5 минут молчания у доски ослабляют сильнее; сильный финиш после подсказки весит больше.

**Незнакомое — называем вслух.** Не убегать от незнакомых частей: коротко пройти то, что знаем, и честно пометить край — «эта часть мне знакома хуже, вот как бы её раскапывал». Секция и добывает сигнал о краях знаний; «это не моя специальность» = сигнал об отсутствии лидерства.

**Калибровка ожиданий.** Задачу не решают полностью — она на это не рассчитана: «пришлось копать глубоко» — признак хорошо идущей секции, а не провала (если успели «всё» — задача была слишком лёгкой). Спокойный кандидат и ведёт лучше.

## 6. Трейдоффы вслух

Форма любого ключевого решения на секции — не «делаем так», а сравнение с ценой. Шаблон фразы: **«два варианта: A — быстрее и проще, B — строже и дороже. Наши требования — X, поэтому беру A; платим Y, компенсируем Z»**. Трейдофф проговаривается даже когда выбор очевиден: интервьюер оценивает не угаданный ответ, а взвешенное решение. Минимум на секцию — три.

Заготовки пар «добавили → даёт → платим» (полная таблица — [`../methodology.md`](../methodology.md) §3):

| Что добавили | Даёт | Платим |
|--------------|------|--------|
| Новый компонент / узлы | нагрузку, скорость ответа | поддержкой и деплоем |
| Репликация | нагрузку на чтение, надёжность | лагом чтения: доступность vs консистентность |
| Кэш | нагрузку | протухшими значениями, cache coherency |
| Шардирование | нагрузку и объём | перешардированием в будущем |
| Готовое решение | оно уже есть | в нём надо разбираться |

К этой же семье относятся два сквозных правила речи: **гарантии вместо брендов** («нужен KV с репликацией и лагом < 1 с, а не "возьмём Redis"» — «нам важнее свойства и предоставляемые системой гарантии, чем конкретное название») и **KISS** («не усложняю без необходимости: здесь стандартный балансировщик, самописное — только то, чего нет в готовом»).

## 7. Свёртка с фреймворком Alex Xu

Книга задаёт каркас из 4 шагов; наши 6 этапов — его детализация под формат Яндекса. Полезно знать соответствие — вдруг интервьюер опирается на книгу:

| Alex Xu, 4 шага | Наши этапы | Заметки |
|---|---|---|
| 1. Понять задачу и масштаб | Этап 1 | то же; у нас + явные числа-гипотезы и минус-объём |
| 2. Общее решение и согласие | Этапы 2–3 | API и high-level до деталей; у нас + control/data plane |
| 3. Глубокое проектирование | Этапы 4–5 | приоритеты интервьюера; у нас + обязательная арифметика |
| 4. Подведение итогов | Этап 6 | у нас шире: отказы + мониторинг + возврат к листу |

Do из книги: уточнять, думать вслух, предлагать разные подходы, быть скромным. Don't: молчать, нырять в детали до согласования каркаса, считать интервью законченным после изложения решения.

## 8. Ошибки этого раздела

Подмножество топ-10 ошибок ([`../methodology.md`](../methodology.md) §4), относящееся именно к разделу 01 — фреймворку и требованиям:

| Ошибка | Как выглядит | Противоядие |
|--------|--------------|-------------|
| Схема без требований | Коробки на 20-й секунде, потом переделываем | 8 минут требований — часть ответа, не вежливость |
| Молчание | Долгие паузы, интервьюер тянет разговор | Думать вслух; пауза > 15 с — проговорить, что сейчас делаем |
| Требования не записаны | В конце «потерялись», сверять нечего | Угол доски, не стирать, вернуться в финале |
| Решения без альтернатив | «Делаем так» — и всё | Трейдофф-фраза на каждое ключевое решение, ≥ 3 за секцию |
| Ступор без данных | «Не знаю, сколько у них пользователей…» | Гипотеза вслух с допущением и приглашением поправить |
| Застрять в деталях | 40 минут на один компонент, отказы «на бегу» | Чекпоинты, тайминг, эксплуатацию не режем |
| «Закончил» после схемы | Схема нарисована — кандидат ждёт | Руль у нас: «теперь проверим требования и отказы» |

## 9. Что назвать на секции (чек-лист раздела)

Обязательные фразы и действия, по которым видно, что раздел освоен. Полный чек-лист всех этапов — карточка [`../methodology.md`](../methodology.md) §7 (то, что печатаем на секцию), лексика остальных разделов — [`../knowledge-base.md`](../knowledge-base.md) §11.

**В начале (этап 1):**
- «Запишу требования в угол доски, к ним вернёмся в конце» — и записать.
- Вопросы по чек-листу §4.2: масштаб, RPS avg/peak, latency-SLO p95, девятки и на что, что строго / что eventual, retention, лимиты.
- Минус-объём: «аналитику и админку отмечаем, но не детализируем».
- Гипотеза при нехватке данных: «вводных нет — выдвигаю гипотезу: DAU 100 млн, пик ×3 к среднему; поправьте, если есть реальные цифры».

**По ходу (этапы 2–5):**
- Чекпоинты на каждом переходе: «требования зафиксировали — перехожу к потокам».
- Выбор с развилкой: «детализировать глубже X или идём к ресурсам?».
- Трейдофф-фраза: «два варианта: A проще, B строже; требования — X → беру A, платим Y, компенсирую Z» (≥ 3 за секцию).
- Гарантии вместо брендов: «нужен класс систем с такими-то свойствами, представитель — такой-то».
- KISS: «не усложняю: здесь готовое решение, самописное — только то, чего нет».
- Числа с формулой: «допущение → формула → число → вывод» (≥ 3 за секцию, ≥ 2 гипотезы).
- Критический путь: «это не нужно для ответа пользователю → убираю из горячего пути, асинхронно батчами».

**В финале (этап 6):**
- Возврат к листу требований: «сверимся: SLO обеспечен запасом …, доступность — N+1 по ярусам, лимиты — rate limiter; каждое требование контролируется метрикой».

## 10. Самопроверка «умею, если»

Критерий раздела из брифа: **могу перечислить 6 этапов с таймингом и знаю, что говорить на каждом**. Проверяется не чтением, а прогоном: закрыть материалы, взять любой сервис (хоть «сокращатель ссылок», хоть «доставка кофе») и вслух провести каркас: 8 минут требований с записанным листом → API → схема → детали горячего пути → 3 расчёта → эксплуатация с возвратом к листу. Протокол такой тренировки, рубрика 0–3 и порог готовности — [`../methodology.md`](../methodology.md) §6; эталонные разборы для сверки — [`../classic-designs.md`](../classic-designs.md) (раздел 11 брифа). Если каркас выдержан, а фразы из §9 прозвучали сами — раздел готов.

## Связанные документы

- [`00-overview.md`](00-overview.md) — обзорная статья по всем 12 разделам брифа (TASK-45.40)
- [`../brief.md`](../brief.md) — бриф: 12 разделов с критериями «умею, если»
- [`../methodology.md`](../methodology.md) — куда углубляться: §2 карточки всех 6 этапов (цель → доска → речь → грабли), §3 речевые паттерны и правила поведения, §4 топ-10 ошибок, §6 протокол тренировок, §7 одностраничная карточка на секцию
- [`../materials/yandex-564132.md`](../materials/yandex-564132.md) · [`../materials/alex-xu-vol1/ch-03-framework.md`](../materials/alex-xu-vol1/ch-03-framework.md) · [`../materials/jackson-gabbard-ep06.md`](../materials/jackson-gabbard-ep06.md) · [`../materials/habr-516604.md`](../materials/habr-516604.md) — три взгляда на секцию (формат · 4 шага · цена вопроса) + взгляд проходца
- [`../knowledge-base.md`](../knowledge-base.md) — числа и паттерны (§2 back-of-envelope, §11 шпаргалка «что назвать»)
- [`../classic-designs.md`](../classic-designs.md) — эталонные разборы: сборка каркаса на реальных сервисах
- Соседние статьи: `02-estimations.md` (числа для этапа 5) · `11-reference-designs.md` (каркас в целых решениях) · `12-operations-observability.md` (этап 6)