Систем Дизайн интервью. Шаблон прохождения собеседования этого этапа

Систем Дизайн интервью. Шаблон прохождения собеседования этого этапаСобеседование на проектирование систем.Они проходят по определенному шаблону, если прийти не подготовленным, не зная этого шаблона, можно просто впасть в ступор, а по шаблону вы можете расписать проблему даже с которой не знакомы, это позволит сделать меньше ошибок.Каждый этап, чтобы все успеть, желательно ограничить временемСтруктура и тайминг такие: 0. Формальное представление друг другу ~5 min1. Сбор требований (Requirements) ~5 min2. Ключевые сущности (Core entities) ~2 min3. Методы / контракт (API or Interface) ~5 min4. Как передаются данные (Data flow) ~5 min5. Само проектирование, рисование (High Level Design) ~10-15 min6. Углубление в проблему (Deep Dives) ~10 minИтого: ~40-45 мин0. Формальное представление друг другу На этом этапе вам скажут что-то типа: Привет, Я Джон, работаю в Имя_Компании столько-то лет, моя роль такая то, сегодня будем с тобой делать примерно вот такое, расскажешь о себе?Ответ должен быть емкий типа:Привет, Я Андрей, engineering manager, у меня 10 лет+ опыта в разработке ПО, сейчас работаю такой_то компании, делаем вот такое, до этого был вот там менеджером, делали вот это. Мой бекграунд фуллстек фронтенд, бекенд, мобайл с такими то технологиями. Приятно познакомиться1. Сбор требований (Requirements) ~5 minЦель этапа собрать требования чтобы иметь четкое понимание что сейчас надо будет проектировать. Можно сравнить это с фрилансом/клиентом когда вы узнаете что надо конкретно сделать. Например: ТвиттерДелиться этап на 2 под этапа:1.1 Функциональные требования (Users/Clients should be able…)- Постить твиты- Подписаться на других- Видеть твиты тех на кого подписан1.2 Не-функциональные требования (The system should be able to…)- 100M пользователей в день (DAU)- Быстро отображать ленту (до 200ms)- Высокая доступность (99.9%)Секрет тут такой что если вас попросили спроектировать Твиттер, не надо расписывать все функции, иначе их и будут ожидать от вас спроектированными, ваша задача выбрать стратегически фичи, выбрать например 3 основные, и сфокусироваться на них, а остальное упомянуть только как out of scope (вне проекта).2. Ключевые сущности (Core entities) ~2 minНа этом этапе просто сущности без детальной модели/таблицы, она может измениться после дизайна, выделить основноеUserTweetFollow3. Методы / контракт (API or Interface) ~5 minНе нужно мудрить, самое простое выделитьPOST /v1/tweetbody: { "text": string}GET /v1/tweet/:tweetId -> TweetPOST /v1/follow/:userIdGET /v1/feed -> Tweet[]Вы можете заметить тут не передается пользователь, так как нужно упомянуть что обычно он берется из auth token заголовка, sensitive информация типа userid, не должна быть в body и запросах.4. Как передаются данные (Data flow) ~5 minРассказать как примерно будут течь данные по системе, типа:Когда публикуем твит, это передается по апи в сервис, сервис отправляет в базу, при запросе ленты, они собираются из базы (или из кеша) и передаются как массив5. Само проектирование, рисование (High Level Design) ~10-15 minНа этом этапе надо нарисовать что-то простое, типа вот client обращение на backend/cthdbc, через api gateway, вот база куда записываются данные/читаются. На этом этапе уже можно расписаться какие поля в сущности User, Tweet, Follow. И объясняя параллельно как данные будут течь по системе.Надо быть заранее знакомым с блоками (как лего) из которых может строиться система: базы данных, кэш, сервисы, апи гейтвеи, очереди и тд.Простое описание здесь надо чтобы система соответствовала Функциональным требованиям.6. Углубление в проблему (Deep Dives) ~10 minНа этом этапе уже чтобы система соответствовала Не-Функциональным требованиям. Для этого уже надо будет добавлять loadbalancer, очереди, больше баз данных (репликация/шардинг и тд).Во время всего собеседования надо держать связь с интервьюверов, и периодически уточнять: Все норм? Продолжаю? Куда углубиться? Но в тоже время не переборщить с вопросами, нужно одновременно показать что вы понимаете что делаете и “вести”.