Что такое System Design интервью и как его пройти 🤔

Иногда на собеседовании СА попадает на System Design интервью - когда кандидат проектирует систему по заданному кейсу весь собес, а собеседующий спрашивает что-то по ходу 😎

Я был на трех таких - в Т-Банк, в Wildberries, третий не помню где. Везде прошел. Вот какие кейсы были:

🤍Агрегатор кинотеатров с возможностью брони и покупки билетов 🤍Система по бронированию и покупке билетов на рейсовые автобусы 🤍Система по доставке товаров

Как пройти такой собес? 📌

Есть хорошая книга на эту тему - System Design Алекса Сюй, о которой уже писал. Там есть общий план и примеры интервью на основе реальных систем (Google Диск, YouTube и так далее) - рекомендую почитать хотя бы пару глав.

План прохождения System Design интервью:

🤍 Сбор требований Представьте, вам дали кейс из списка выше. Ничего же непонятно ❓ - какие кинотеатры, что должен увидеть пользователь, как осуществляется доставка, что написано в билете на автобус

Поэтому первый этап - классический сбор требований. Собираем функциональные и (ВАЖНО) нефункциональные - все это пригодится. Здесь СА должен чувствовать себя как рыба в воде

🤍 Расчеты На основе нефункциональных требований можно посчитать нагрузку и трафик, что поможет при проектировании архитектуры:

Нагрузка: (Количество пользователей в день (DAU) * количество операций записи/чтения) / секунды в сутках. Например, 10 000 000 * 15 (количество запросов в сутки) / 86400 сек ~ 1500 запросов в сек (RPS) Трафик: Нагрузка * количество байт * количество объектов в запись. Например, 1500 RPS * 200 Bytes * 1 = 300 KB/s

Чтобы узнать количество операций записи, спросите, сколько билетов продается в день. Чтобы посчитать передаваемые байты, прикиньте сущность и атрибуты (но почитайте, сколько байт занимают int или string)

🤍 Предварительное проектирование

В вольной нотации или в C4. Открываем редактор (например, Draw.io) и накидываем клиентские приложения, сервисы, шлюзы, внешние интеграции 🥵

Помочь определить тип архитектуры (монолит, микросервисы) помогут как раз расчеты выше. Они же подскажут, на чем акцент в системе - на запись или чтение

🤍 Углубленное проектирование

Тут подключается собеседующий и предлагает углубиться в какой-нибудь сервис или часть системы: понять логику работы, нюансы, различные кейсы

Например, рассказать логику работы сервиса бронирований

Cправиться с этой частью поможет технический кругозор: опыт на работе, видео с YouTube, книги, курсы. Важно, чтобы вы не только понимали бизнес-логику, но и могли бы обосновать выбор типа БД или интеграции

🤍 Итог

Чаще всего в конце спрашивают про будущее системы: а что если мы захотим что-то изменить, или количество пользователей вырастет с 10 до 10000 🫥. Какие есть узкие места в системе, что с ними делать

Опять же, возвращаемся к техническому кругозору

————— ВАЖНО: в таких собесах не нужно проявлять перфекционизм - цифры можно посчитать примерные, да и система не должна быть идеальной. Тут не требуют правильного ответа 🌾

Собеседующий смотрит на то, какие есть знания, как рассуждает кандидат, какие технологии знает, как предлагает и защищает решения. Это эффективнее, чем классические вопрос-ответ

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

➡️ Ставьте 🔥 и забирайте себе - пригодится на интервью по System Design

В этом посте были ссылки, но мы их удалили по правилам Сетки