---
title: Конспект источника 5 — Jackson Gabbard, «Intro to Architecture and Systems Design Interviews» (The Unqualified Engineer, Episode 06)
source: https://www.youtube.com/watch?v=ZgdS0EUmn70
author: Jackson Gabbard (экс-Facebook, интервьюер), 31.07.2016, ~49 мин
конспект: подготовлено 2026-09-17, TASK-45.9; расшифровка авто-субтитров EN (yt-dlp), прочитана целиком; правила поведения перенесены в methodology.md §3, пример capacity estimation — в §3 ниже и сверен с knowledge-base.md §2
статус: взгляд интервьюера из «A-list» компании; рассказчик — бывший сотрудник Facebook (интервьюер + участник candidate review); формулировки из видео, увязка с нашими материалами — наша
---

# Источник 5: Jackson Gabbard — Intro to Architecture and Systems Design Interviews

Третий взгляд на ту же секцию, но с другой стороны прилавка. Источник 1 (статья Яндекса) формализует **что** оценивают и как устроены этапы; источник 4 (habr 516604) даёт **план и фразы** проходца; этот источник объясняет **почему секция стоит так дорого** и какой стиль поведения ведёт к офферу, а какой — к отказу, даже если код и behavior прошли идеально. Читать после источников 1 и 4: сам фреймворк здесь не новый, новая — калибровка ожиданий и роль «водительского кресла».

Связь с подготовкой: `../methodology.md` §3 (правила поведения), §1 (тайминг и роль кандидата), §5 (пункт 7 порядка чтения, 40 мин), `../knowledge-base.md` §1.2–1.3 (числа), §2 (back-of-envelope).

---

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

Gabbard начинает с различия двух типов интервью:

| | Coding-секция | Архитектурная секция |
|---|---|---|
| Шкала оценки | Практически pass/fail: «дошёл до планки или не дошёл», редки вердикты «код хороший, но не дотянул» | Широкий спектр: спецнавык, широта, глубина, способность вести |
| Ответ | Есть правильный | **Правильного ответа нет** — есть несколько хороших и набор ужасных; между хорошими выбирают трейдоффами |
| Что решает | Пускают ли за порог | **Какой уровень оффера** дадут: stronger/weaker contributor, лидер одной команды или многих; напрямую → цифра зарплаты и объём equity |

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

Формально: в наборе бывают кодинг, behavior/background и архитектура; у специалистов (Android/iOS) — архитектура по своей платформе; у очень senior — отдельное leadership-интервью. Обычному кандидату на разработчика встречаются первые три, и для нас архитектура — рычаг на уровень оффера.

## 2. Устройство вопроса: «большие детали» вместо условий

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

> У вас успешное приложение: Android, iOS, mobile web — 500 миллионов active users в месяц. Спроектируйте logging infrastructure, которая позволит разработчикам логировать произвольные данные с устройства на сервер (старт/стоп приложения, переключение фич, отправленные и полученные сообщения — что нужно), чтобы дебажить и мерить производительность в проде, и масштабируется на всех пользователей и все устройства.

Это «давящая» и «размытая» задача намеренно: **интервьюер не выдаст всю информацию — её нужно вытащить**. Единственное «условие» — детали, которые надо **допросить**, а не посчитать по умолчанию.

**Играть от своих сильных сторон.** Интервьюер ждёт, что ты разнесёшь ту часть задачи, где твой бэкграунд даёт преимущество: mobile-разработчик должен заговорить про потребление батареи и сотового трафика, про on-device ограничения (сколько места занимаем, не блокируем ли UI-thread, какой API даём разработчикам); человек из distributed file systems — про запись на 500M масштабе, сходимость распределённых логов в один лог-стор. И наоборот: **неизвестное не прятать** — коротко пройтись по тому, что знаешь хорошо, и честно назвать края: «а вот эта часть мне знакома хуже». Это ровно тот сигнал о широте и глубине, который секция и добывает; молчание или «это не моя специальность» — сигнал об отсутствии лидерства.

## 3. Пример capacity estimation из видео (полная цепочка)

Ядро этапа ресурсов — превратить «страшное» число в трактабельное. Цепочка Gabbard (наш разбор — по шагам; формулы и классы чисел — `../knowledge-base.md` §1.2–1.3, §2):

**Шаг 0. Осознать, что MAU — не число для железа.** «500 миллионов monthly actives — это funny money». Отвечать на «покупку серверов» в MAU нельзя.

**Шаг 1. Не путать среднее с пиком.** Наивный путь: `500 млн / 30 дней / 86 400 с` — **неверно**: люди не распределены по земле равномерно и не приходят случайно, они приходят «домой после работы» — город, штат, страна заходят примерно в одно время. У любого масштабного сервиса есть пики и провалы, считать нужно **пиковую** нагрузку.

**Шаг 2. Уточнить контекст у интервьюера (это и есть leadership в действии):**
- география: весь мир или только США и Западная Европа? каждая локация даёт свой профиль трафика;
- какое суточное проникновение? берём допущение 70 % от MAU приходит ежедневно.

**Шаг 3. Цепочка цифр (допущения озвучиваем вслух):**

| Шаг | Допущение | Считаем | Результат |
|-----|-----------|---------|-----------|
| MAU → DAU | 70 % заходят каждый день | 500 млн × 0.7 | **350 млн DAU** |
| DAU → час пика | 70 % DAU активны в пиковый час | 350 млн × 0.7 | **245 млн в час пика** |
| час пика → одновременные | 3 600 с в часе | 245 млн / 3 600 | **≈ 68 000 одновременных пользователей** |
| concurrent → ноды | «плохо оптимизированный Node-сервер» держит 1 000 одновременных | 68 000 / 1 000 | **≈ 68 серверов** |

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

**Шаг 4. Мета-правило: числа выдуманы — и это нормально.** «Yes, I just made up a bunch of numbers». Секция проверяет не психометрию и не точное предсказание трафика компании, а способность **делать устойчивый прогресс через неопределённость**. Если ошибёшься в два раза:
- в меньшую сторону — «докупим серверы позже»;
- в большую — «компания на ракете, ёмкость всё равно понадобится».
Ошибиться в 10+ раз (например, «около миллиона серверов») — это путь к разорению компании; порядок величины уже не безразличен.

**Сверка с нашими материалами:** это тот же принцип «допущение → формула → число → вывод», что в `../knowledge-base.md` §2.1, но с другим якорем: у нас в примерах RPS от DAU, здесь — конверсия MAU → DAU → пик → concurrent → ноды. Обе цепочки стоит уметь проговаривать подряд.

## 4. Реалистичные границы вместо выдумки «с потолка»

После числа пользователей нужен throughput. Gabbard разбирает три уровня ответа:

1. **Rookie:** «ну, наверное, полмегабайта — sounds about right».
2. **Лучше:** оценивать объём лога (сколько интов, строк, произвольных данных) × 100 действий/мин.
3. **Лучший (лидерский):** **утвердить разумное ограничение от эмпатии к пользователю.** «Just because you can log more data doesn't mean you should».

Ход рассуждения:
- верхняя граница от мира: не бывает, чтобы 70 тыс. пользователей стримили по 5 МБ/с на сервер «в фоне» — за это приложение возненавидят, никто не будет платить за такой трафик;
- верхняя граница от человека: сколько действий в минуту возможно физически — ~30–40 сообщений при яростной печати, несколько десятков полученных фото;
- от бюджета пользователя: 0.5 МБ/мин × 60 мин = **30 МБ в час** — для плохого соединения в Индии или Африке это огромные деньги и время; такой бюджет недопустим;
- вывод-утверждение: **берём верхнюю границу 10–20 КБ/мин** (в разы меньше реального трафика пользователя) и проектируем систему вокруг неё.

Смысл для секции: решение, принятое из «как это выглядит для человека и продукта», а не только из технической возможности, читается интервьюером как **взгляд на картину целиком**, а не как «в дебрях технических деталей». Это прямое пересечение с metrics first и продуктовым финалом из `../methodology.md` §1 и §3.

## 5. Карта «о чём ещё поговорить» (breadth-чеклист)

После 10–15 минут capacity estimation начинается собственно система. Gabbard перечисляет, что осталось: клиентская реализация по платформам (iOS/Android/web/TV), серверная сторона (компоненты, технологии, обновления), сетевой трафик логов (сжатие, шифрование, протокол), доставка только по Wi-Fi vs по мобильной сети, долгосрочное хранение и retention (например: 3 дня полного доступа → 7 дней → 30 дней с падающим разрешением, «recent matters»), стоимость и сроки разработки, headcount, эксплуатационная стоимость, доступ к логам для разработчика (Hadoop/Hive vs распределённый SQL), приватность (логируем ли персональные данные; что делаем по «delete my data»).

Это готовый **breadth-чеклист для этапа 6 нашей секции и для доп. вопросов**: если время осталось, а мы не знаем, что сказать — идём по этому списку (эмпатия → приватность → retention → стоимость эксплуатации). В `../methodology.md` §1 эти темы разложены по этапам 4 и 6.

## 6. Правила поведения на секции (перенесено в методичку §3)

Формулировки Gabbard (дословные опоры):

1. **Водительское кресло.** «You are in the driver's seat… treat it like a tech talk where you're explaining to the other person how the system is going to work». «И что дальше?» должен говорить интервьюер, а не кандидат. Симптом плохой секции — когда интервьюер подталкивает: «окей… и что?».
2. **Keep going.** «Если ты идёшь через ад — иди» (Черчилль в пересказе). Мысль «я не знаю, что дальше» — не стоп, а диагноз: либо недостаточно вовлечён, либо не знаешь проблему; лечится тем, что вслух оглядываешься («давай зафиксирую, где мы») и идёшь дальше.
3. **Хинт лучше ступора.** Если реально застрял — попросить подсказку. Это слегка ослабит оценку, но «пять минут молчания у доски» ослабит её сильнее; сильный финиш после подсказки весит больше, чем провал. См. `../methodology.md` §4, ошибка №2 (молчать и рисовать про себя).
4. **Незнакомое называть вслух.** Не убегать от того, чего не знаешь: «вот это я знаю хорошо, а эта часть мне менее знакома — вот как я бы её раскапывал». Это сигнал лидерства, а не минус.
5. **Числа озвучивать как допущения и не бояться ошибки ×2** (см. §3 выше).

## 7. История провала: как «ок»-секция становится отказом

Кейс из Facebook (личный опыт рассказчика): кандидат отлично прошёл две кодинг-секции и behavior, всем понравился. Архитектурная — «слабая»: не по незнанию, а по **вовлечённости** — интервьюеру приходилось тянуть его вперёд, кандидат ждал подсказок. Панель проголосовала «берём», но на candidate review директор зарубил:

> «8 лет индустриального опыта — и архитектурный образ мысли у него “I don't know what's next”. Нам такой не нужен».

Мораль, которую Gabbard выводит (и под которую в A-list компаниях есть формальная планка: не дотянул за ~3–4 года — расстаёмся):
- **комплейшенси в своей роли убивает шансы на компанию лучше** — «get busy living or get busy dying»;
- судят не только «правильность», а **готовность вести и разбираться**; пассивность = отрицательный сигнал независимо от кода.

## 8. Калибровка ожиданий

- Эти интервью **спроектированы, чтобы найти твои края**: если интервьюер делает работу правильно, выйдешь с ощущением «пришлось копать глубоко» — это корректное состояние, значит секция прошла хорошо.
- **Задачу нельзя решить полностью** и не имеется в виду, что её решат за 45 минут: смысл — показать, как далеко ты пройдёшь, насколько широко и глубоко рассуждаешь в реальном времени на новой задаче.
- Если вышел, «успев всё» — скорее всего, задача была слишком лёгкой.
- Провал архитектурной секции — **не конец**: senior-интервью архитектуры не дают джунам именно потому, что этот контекст не берётся в школе; «не блеснул дизайном, но код сильный и видно страсть — зовём» — рабочая формулировка фидбека. Обратная история — «код порвал, но в архитектуру не вступал вообще, значит при нерешаемой задаче сдаётся» — гораздо хуже.
- **Pedigree не решает.** Пример самого рассказчика: Google отклонил, позже нанял Facebook, а через три года Google сам писал ему в личку; отказ — это «дверь, у которой ты уже стоял», а не приговор.

## 9. Как набирать контекст вне бигтеха

Если не работал на высоком масштабе — это не блокер: внутри компаний подавляющее большинство **тоже не решает архитектурные проблемы ежедневно**; те, кто решает, выдают «большую поставку» раз в полгода-год, и **об этом рассказывают** — tech talks, внутренние рассылки, презентации. Инженерные блоги, YouTube-доклады с конференций, white papers — та же самая коммуникация, только публичная; читать их перед интервью — не «читерство», а **ранняя подготовка к работе**: те же знания понадобятся после найма. Друг рассказчика, автор white paper по Haystack, устраивал обеды-читальни white papers — это и есть «среда», которую можно воссоздать снаружи.

**Как это ложится на нас:** наши материалы 1–4 и 6 — ровно такая же публичная коммуникация (статья Яндекса, Primer, опыт проходца, DDIA); к ним — инженерные блоги компаний из наших откликов (GitLab, Pennylane, Cleo, Runware) на фоновое чтение после первой секции. В `../methodology.md` §6 это уже зашито как протокол тренировок и mock-сессий.

## 10. Что уносим в подготовку (сводка)

| Тезис Gabbard | Куда лёг |
|---------------|----------|
| Архитектурная секция определяет уровень оффера → это второе по важности интервью | `../methodology.md` §1 (роль кандидата), калибровка |
| Нет правильного ответа, есть выбор с трейдоффами | `../methodology.md` §3 (шаблоны трейдоффов) |
| MAU — funny money; переводить в пик → concurrent → ноды; ошибка ×2 допустима | `../knowledge-base.md` §2.1, §3 этого файла |
| Утверждать разумные границы из эмпатии к пользователю и продукту | `../methodology.md` §1 (metrics first), §3 |
| Водительское кресло, keep going, хинт лучше ступора, незнакомое — вслух | `../methodology.md` §3, блок «Правила поведения» |
| Breadth-чеклист «о чём ещё поговорить» (приватность, retention, стоимость, доступ) | `../methodology.md` этапы 4 и 6 |
| Пассивность = отказ независимо от кода (кейс candidate review) | `../methodology.md` §4, ошибка №2 |
| Контекст набирается публично (блоги, доклады, white papers) | `../methodology.md` §6 (протокол), §5 (порядок чтения) |