Иногда на собеседовании СА попадает на 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