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 минут (тайминг — наш, структура — из первоисточника):

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

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

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

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

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

Короткая карточка на каждый этап — что делаем и что говорим. Полные карточки (цель → что на доске → что проговорить → грабли) — ../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 §2). Грабли: считать молча; число без формулы не оценивается.

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

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

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

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

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

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

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

Зачем фиксировать «на что именно» девятки и что именно строго — эти уточнения потом становятся фокусом дизайна: «четыре девятки на чтение при 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 §3):

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

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

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

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

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

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

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

Обязательные фразы и действия, по которым видно, что раздел освоен. Полный чек-лист всех этапов — карточка ../methodology.md §7 (то, что печатаем на секцию), лексика остальных разделов — ../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 §6; эталонные разборы для сверки — ../classic-designs.md (раздел 11 брифа). Если каркас выдержан, а фразы из §9 прозвучали сами — раздел готов.

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

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