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. Оно оценивает не «знание систем», а техническую лидерскую способность: взять большой размытый кусок и разложить его на связные подзадачи — или вообще понять, что именно от тебя хотят.

Формально: в наборе бывают кодинг, 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. Цепочка цифр (допущения озвучиваем вслух):

Вывод вслух: «Из 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. Что уносим в подготовку (сводка)