System Design Interview. Шаблон прохождения собеседования этого этапа
Недавно я собеседовался в Амазон и Майкрософт в офисы в Испании (так как я тут живу). Пока готовился много что понял, сейчас поделюсь.
Собеседование на проектирование систем.
Проходят по определенному шаблону, если прийти не подготовленным, не зная этого шаблона, можно просто впасть в ступор, а по шаблону вы можете расписать проблему даже с которой не знакомы, это позволит сделать меньше ошибок.
Каждый этап, чтобы все успеть, желательно ограничить временем
Структура и тайминг предлагаемого шаблона такой:
0. Формальное представление друг другу ~5 min
1. Сбор требований (Requirements) ~5 min
2. Ключевые сущности (Core entities) ~2 min
3. Методы / контракт (API or Interface) ~5 min
4. Как передаются данные (Data flow) ~5 min
5. Само проектирование, рисование (High Level Design) ~10-15 min
6. Углубление в проблему (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
На этом этапе просто определите, и напишите, сущности без детальной модели/таблицы, она может измениться после дизайна, главное выделить основное
User
Tweet
Follow
3. Методы / контракт (API or Interface) ~5 min
Не нужно мудрить, постарайтесь выделить основное
POST /v1/tweet
body: {
"text": string
}
GET /v1/tweet/:tweetId -> Tweet
POST /v1/follow/:userId
GET /v1/feed -> Tweet[]Вы можете заметить тут не передается пользователь, нужно упомянуть что обычно он берется из auth token заголовка, sensitive информация типа userid, не должна быть в body и get запросах.
4. Как передаются данные (Data flow) ~5 min
Рассказать как примерно будут течь данные по системе, типа:
Когда публикуем твит, это передается по апи в сервис, сервис отправляет в базу, при запросе ленты, они собираются из базы (или из кеша) и передаются как массив
5. Само проектирование, рисование (High Level Design) ~10-15 min
На этом этапе надо нарисовать что-то простое, типа вот client обращение на backend/сервис, через api gateway, вот база куда записываются данные/читаются. На этом этапе уже можно расписаться какие поля в сущности User, Tweet, Follow. И объясняя параллельно как данные будут течь по системе.
Надо быть заранее знакомым с блоками (как лего) из которых может строиться система: базы данных, кэш, сервисы, апи гейтвеи, очереди и тд.
Здесь надо чтобы система соответствовала Функциональным требованиям.
6. Углубление в проблему (Deep Dives) ~10 min
Тут чтобы система соответствовала Не-Функциональным требованиям.
Для этого уже надо будет добавлять loadbalancer, очереди+воркеры(если надо), кэш, cdn, больше по баз данным (репликация/шардинг и тд).
Во время всего собеседования надо держать связь с интервьюверов, и периодически уточнять:
Все норм? Продолжаю? Куда углубиться?
И не переборщить с вопросами, нужно одновременно показать что вы понимаете что делаете и “вести”.
На данный момент я работаю в международной компании из «travel» индустрии в роли Engineering Manager, но очень хочу работать в айти гиганте типа Амазон/Майкрософт, поэтому много изучаю и стремлюсь туда.
Если вы уже проходили туда и можете поделиться советами — буду рад
Недавно проходил interview loop (это когда 4-5 собесов в один день) в Амазон, жду пока результат, обязательно расскажу здесь и у себя в тг канале. А в прошлом году я проходил в Майкрасофт, но был плохо подготовлен и не прошел.
Автор: aposnov