Вопросы на собеседовании по системному дизайну в Meta

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

• Спроектируйте ленту новостей. Ранжирование, fanout при записи против fanout при чтении, и что происходит с аккаунтами с миллионами подписчиков.
• Спроектируйте систему сообщений или чата. Гарантии доставки, порядок, статус присутствия и офлайн-синхронизация между устройствами.
• Спроектируйте систему уведомлений. Дедупликация, пакетная обработка, лимиты частоты на пользователя и доставка через push, email и внутри приложения.
• Спроектируйте функцию друзей поблизости или геолокацию. Геопространственная индексация, частота обновлений и модель приватности.
• Спроектируйте компонент поиска или трендов. Свежесть индекса против задержки запроса.

Некоторые процессы разделяют это на вариант продуктовой архитектуры, который ближе к поведению, видимому пользователю. Спросите рекрутера, какой вариант вам достанется, потому что подготовка отличается.

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

• Сначала требования. Какие пользователи, какие платформы, преобладает чтение или запись, и что вы явно не строите.
• Затем цифры. Примерное число ежедневных активных пользователей, частота запросов и размеры payload, чтобы у последующих компромиссов была опора.
• Модель данных раньше диаграмм. То, как выглядит сущность и как она запрашивается, обычно определяет архитектуру.
• Одно глубокое погружение. Ожидайте, что вас направят в один компонент и спросят, как он ломается.

Проговаривайте свои допущения вслух. Интервьюер, не согласный с допущением, поправит его, а это бесплатная информация; непроговорённое допущение выглядит просто как пробел.

Средние ответы описывают корректную архитектуру. Сильные ответы называют принятый компромисс и отказ, который они готовы терпеть. Фраза «я выбираю fanout при записи, потому что здесь преобладает чтение, и я принимаю медленную запись для аккаунтов знаменитостей, с которой справился бы через отдельный pull-путь» весит больше, чем идеальная диаграмма.

Представьте бэкенд-инженера, проходящего собеседование на senior-роль. Её просят спроектировать систему уведомлений, и первые шесть минут она тратит только на требования: может ли пользователь получить два уведомления по одному событию, важен ли порядок, каково окно хранения. Позже интервьюер говорит, что обсуждение дедупликации стало решающей частью секции, и она так и не продвинулась дальше диаграммы на одной странице.

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

На устном видеособеседовании SubcueAI транскрибирует вопрос интервьюера и показывает предложенную структуру на вашей стороне — в оверлее на рабочем столе на macOS и Windows или в боковой панели расширения браузера Chromium. Ни один бот не подключается к звонку, и в страницу встречи ничего не внедряется. Для секции дизайна реальная польза — это чек-лист вещей, которые вы постоянно забываете под давлением, вроде оценки ёмкости или режима отказа, а не ответ, который вы читаете вслух.

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