Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture) На этих выходных мы с Гришей из клуба { между скобок} поговорили про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space. Основные моменты, что мы успели обсудить следующие - Книга по System Design быстро устаревает: паттерны и требования меняются, а живой сайт можно непрерывно допиливать под практику, а не под "вечную теорию" - Ожидания на интервью сдвигаются от "знаешь ли ты стандартный набор сервисов и buzzwords" к умению думать как архитектор: трезво выбирать компромиссы, задавать вопросы, формализовывать требования - Разобрали типовые ошибки кандидатов - - Сразу рисовать «кубики и стрелочки» без уточнения ограничений, - - Оптимизировать за пределами реальных bottleneck’ов - - Заучивать шаблоны задач вместо понимания инвариантов (consistency, durability, latency budgets и т.д.) - System Design интервью на самом деле проверяет не "знаешь ли ты Kafka", а: как ты принимаешь решения, как разговариваешь с продакт менеджером, как эволюционируешь систему от MVP до сложной архитектуры - Разница между "рисованием кубиков" и архитектурным мышлением: во втором случае ты всегда привязываешь решения к пользовательским сценариям, нагрузке, отказоустойчивости и стоимости владения, а не просто перечисляешь модные технологии - Для senior/staff обязательны темы: масштабирование хранения и вычислений, очереди и асинхрованная работа, кэширование, консистентность, observability, эволюция схемы данных и rollouts, а также работа с неопределённостью и неполными требованиями - Готовиться нужно не "по чек-листу задач", а системно: строить свой набор инвариантов и шаблонов мышления, прогонять реальные кейсы, а не просто зубрить решения. Если говорить про инсайты для руководителей, которыми можно поделиться, то - Интервью по SD стоит перестраивать с "угадай сервис" на разбор реального кейса: дать неполные требования, посмотреть, как кандидат уточняет, режет scope и развивает архитектуру итеративно Хорошее SD-интервью - это мини-совместное проектирование: вы вместе выходите хотя бы к первому адекватному приближению системы, а не к идеальной картинке из учебника. - Стоит явно формализовать, какие уровни архитектурного мышления вы ждёте от middle/senior/staff, и дать людям прозрачную лестницу роста (в идеале - с примерами на внутренних кейсах). - Вместо того чтобы ждать от команды "чтения книг по SD", проще дать живую базу практик, чек-листы и разборы постмортемов - то есть institutional knowledge, а не набор ссылок на классические книги. #SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering