Как устроено System Design Interview в FAANG?

System Design Interview (SDI) встречается на все позиции программистов, кроме интернов. Для интернов есть только собеседования по алгоритмам. Для всех других позиций у вас будет хотя бы одно SDI.
Оно встречается только на full loop. На скрине будет только собеседование по алгоритмам и иногда будет еще поведенческая часть. На full loop у вас будет поведенческая часть, несколько собесов по алгоритмам и хотя бы одно по System Design.
Для примера, так выглядят собесы в Amazon и Facebook:

Amazon:
Screen - online assessment (онлайн тест на две алгоритмические задачи). Если все ок - full loop, если все плохо - reject, если что-то между могут назначить собеседование с человеком на такие же алгосы.
Full Loop: 3 coding + LP собеседования (три собеседования по 45 минут. На каждом одна задача на алгосы и поведенческая часть на Amazon Leadership Principles). И одно на System Design + LP.

Facebook:
Screen - 45-минутное собеседование по алгосам с человеком на 2 задачи.
Full Loop: 2 собеседования по алгосам, такие же как и Screen, 1 поведенческое, 1 по System Design.

Для уровня Staff Software Engineer будет 2 собеседования по System Design.

Для Junior уровня SDI немного отличается. Оно проще. Вас могут попросить сделать ООП дизайн классов для какой-то задачи.
Для уровней начиная с Middle вас попросят задизайнить какую-нибудь широко известную систему вроде месенджера, новостную ленту, систему бронирования билетов и т.д.
На содержательную часть собеседования у вас будет минут 40.
Т.к. вопрос очень общий, то на него нет одного правильного ответа. А в силу ограниченного времени, вам надо четко установить scope задачи.

Поэтому само собеседования я бы разделил на 6 основных этапов:
1) Получение задачи. Если вас попросили задизайнить какую-то систему, а вы вообще не в курсе, что это такое, то это нужно уточнить сразу. Но обычно, вы будете знакомы с тем, что вас попросят сделать. Вроде задизайнить youtube и т.д. Но если вы не уверены, что это такое, то лучше выяснить сразу.
2) Уточняем и формулируем функциональные требования. Обычно, у системы, которую вас просят задизайнить огромное число функций. Но из-за ограниченного времени, вам скорее всего нужно задизайнить 1-3 ключевые функции. Какие именно, нужно уточнить у интервьюера, если это не было понятно на этапе получения задачи. Даже если вы это поняли, то стоит сформулировать эти требования явным образом, что нам надо поддержать ту или иную функциональность.
3) Уточняем, делаем асампшены по поводу нефункциональных требований. Делаем оценку требуемых ресурсов. Сделайте предположение и согласуйте это с интервьюером по числу пользователей, дневной активности и т.д. На основе этих данных сделайте оценку требуемых ресурсов: число серверов, дискового пространства, требования к пропускной способности сети и т.д. Это нужно сделать, чтобы понимать масштаб компонент. Т.к. соц сеть на 100 пользователей и 3 миллиарда - это два разных приложения.
4) Делаем high-level design. Рисуем диаграмму в виде квадратов, соединенных стрелочками с основными компонентами. Поясняем зачем и почему нам нужна та или иная компонента. Проходим по дизайну и проверяем, что он покрывает все требования.
5) Обсуждаем trade-offs. У каждого подхода есть свои плюсы и минусы. Если вам в голову приходят разные варианты дизайна, реализации тех или иных компонент или использования тех или иных технологий (SQL vs. NoSQL, RPC vs REST vs GraphQL vs Websocket, In-Memory Cache vs NoSQL) то обсудите эти варианты и какие плюсы и минусы у этих подходов и почему вы в итоге выбрали то, что выбрали.
6) Делаем детальный дизайн. В рамках обсуждения с интервьюером, вас могут попросить раскрыть более детально ту или иную часть дизайна. Как вы будете партиционировать данные, какие у вас будут таблицы в базе, как у вас будет распределятся нагрузка, как будет работать система при отказе той или иной компоненты. Проверьте, что ваш дизайн удовлетворяет нефункциональным требованиям (обеспечивает масштабирование, fault tolerance, resilience и т.д.).