Питання співбесіди System Design у Meta

Можливо, ви готувалися, заучуючи факти про розподілені системи, але цей раунд це не винагородить. Цей розділ описує реальні форми запитань, які ближчі до product engineering, ніж до інфраструктури. Повторюваний патерн — це функція споживчого масштабу, якою ви вже користуєтесь, віддана вам як відкрита задача.

• Спроєктуйте стрічку новин. Ранжування, fanout on write проти fanout on read та що відбувається з акаунтами з мільйонами підписників.
• Спроєктуйте систему обміну повідомленнями або чат. Гарантії доставки, порядок, presence та offline-синхронізація між пристроями.
• Спроєктуйте систему сповіщень. Deduplication, batching, ліміти швидкості на користувача та доставка через push, email та in-app.
• Спроєктуйте друзів поруч або функцію локації. Геопросторова індексація, частота оновлень та модель приватності.
• Спроєктуйте компонент пошуку або трендів. Свіжість індексу порівняно з затримкою запитів.

Деякі процеси співбесід поділяють це на варіант product architecture, який залишається близьким до поведінки, орієнтованої на користувача. Запитайте у свого рекрутера, який варіант дістанеться саме вам, бо підготовка відрізняється.

Типова помилка — малювати прямокутники вже на другій хвилині. Робочий розподіл: уточніть вимоги та scope, накидайте API та модель даних, намалюйте архітектуру високого рівня, а потім заглиблюйтесь там, куди вкаже інтерв'юер.

• Спочатку вимоги. Які користувачі, які платформи, read-heavy чи write-heavy, і що ви явно не будуєте.
• Потім цифри. Приблизна кількість daily active, частота запитів та розміри payload, щоб подальші компроміси мали на що спиратися.
• Модель даних перед діаграмами. Те, як виглядає entity та як вона запитується, зазвичай визначає архітектуру.
• Одне глибоке занурення. Очікуйте, що вас скерують до одного компонента і запитають, як він виходить з ладу.

Озвучуйте свої припущення вголос. Інтерв'юер, який не погоджується з припущенням, виправить його, а це безкоштовна інформація; невисловлене припущення виглядає просто як прогалина.

Середні відповіді описують правильну архітектуру. Сильні відповіді називають компроміс, який вони прийняли, та збій, який готові допустити. Сказати "я обираю fanout on write, бо тут домінують читання, і я приймаю повільні записи для акаунтів знаменитостей, з чим я впорався б окремим pull path" дає більше, ніж ідеальна діаграма.

Уявіть backend-інженерку на співбесіді на позицію senior. Її просять спроєктувати систему сповіщень, і вона витрачає перші шість хвилин лише на вимоги: чи може користувач отримати два сповіщення за одну подію, чи важливий порядок, яке вікно retention. Інтерв'юер пізніше каже, що обговорення deduplication було вирішальною частиною раунду, а вона так і не пішла далі діаграми на одну сторінку.

Репетирувати цю розповідь наодинці за столом — найважча частина. Ви можете відпрацьовувати дизайнерські питання проти AI-інтерв'юера на сторінці /mock-interview і звикнути говорити, поки думаєте.

На усному відеораунді SubcueAI транскрибує питання інтерв'юера та показує на вашому боці запропоновану структуру — у desktop-оверлеї на macOS і Windows або в бічній панелі розширення браузера Chromium. Жоден meeting bot не приєднується до дзвінка, і нічого не вставляється на сторінку зустрічі. Для дизайнерського раунду реалістична цінність — це чек-лист, який ви постійно забуваєте під тиском, наприклад оцінка ємності чи режим збою, а не відповідь, яку ви читаєте вголос.

Межі тут чіткі. Дизайнерські раунди зазвичай проходять у спільному whiteboard-інструменті з демонстрацією вашого екрана, і все на вашому екрані видно панелі. Читання згенерованої відповіді теж миттєво провалюється, бо наступне питання інтерв'юера — "чому не інший підхід?". Пов'язані раунди для інших роботодавців розміщені в company interviews topic.