Все что нужно знать о system design interview

Как появились эти собеседования

Что за задачи ожидать

Большинство компаний предлагают задачи по типу сделать клон какой-то существующей системы, например твиттера, инсты, поиска гугла, гугл документов. Есть компании исключения, предлагают спроектировать решение под свою конкретную задачу, я даже один раз ходил на такое в одной оранжевой компании, примерно знал чего ожидать, а на практике необходимо было спроектировать модуль хранения и вычисления огромной рекомендательной системы, создание и перемножение бесконечных матриц и тд. Обычно интервью длится около 1 часа и проходит на одной из онлайн платформ

• draw.io
• excallidraw
• miro
• figma

Часто кандидат может использовать тот инструмент, который ему удобен, но я заранее готовлю доску там где это удобно мне, чтобы если что прислать ссылку кандидату туда.

Что проверяют

С первого взгляда кажется, что проверяют на сколько кандидат просто знает какие “пазлы” есть и как из них составить решение, попутно душат вопросами о глубоких технических деталях.

На самом деле проверяют как кандидат может решить поставленную проблему. Больше скажу. Не обязательно строить супер крутую систему из кучи компонентов. Достаточно, чтобы решение соответствовало требованиям, но требования выясняются лишь по ходу.

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

Паттерн разделяй и властвуй во всей красе. А пазлы лишь то как решить конкретную узкую проблему, например какую базу использовать для поиска, какую для горячих данных, как передать из одной системы в другую (без очередей никуда).

Этапы в рамках интервью

На самом деле этапы уже все известны и интервью состоит из:

• Знакомство с задачей
• Анализ требований
• Проработка решения большими мазками, какие компоненты нужны, как приходят запросы, как их обработать, мелкие контракты
• Углубление в детали отдельных кусочков, например хранилищ, контракты предоставляемых апишек и тд
• Проверка сценариев из требований
• Вопросы по схеме
• Завершение

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

Моя цель как интервьюера - помочь человеку решить проблему в рамках предложенных ограничений, стараюсь активно участвовать в рассуждениях и всячески работать с кандидатом. Увы большинство интервьюеров просто садится камнем и сухо отвечает на вопросы, тут будет тяжелее.

Какие концепции необходимо знать

Или хотя бы быть знакомым, перечислю тезисно, а в деталях каждый должен углубляться сам.

• DNS, или как клиент узнает куда прислать запрос
• Раздача статического контента (CDN), зачем это нужно и почему отдельно.
• Балансировщики, Gateway и их уровни, зачем нужны, какие алгоритмы бывают.
• Транзакционные хранилища (OLTP), для меняющихся данных. SQL и NOSQL типы, как хранить больше данных (шардирование, архивирование, партиционирование), устойчивость к отказу узлов.
• Аналитические хранилища (OLAP), для архивов и неизменных данных.
• Файловые базы для хранения бинарных данных, картинок, как работают и особенности.
• Кэшироване, стратегии и особенности, как посчитать прирост скорости, инвалидация данных.
• Синхронизация и оркестрация данных между системами, очереди, гарантии доставки, in-out|box.
• Особенности распределенных систем, блокировки, общие состояния.
• Общение с клинтом в реальном времени, какие способы есть и как сделать, в идеале попробовать самому.
• Хранение состояния, без баз, прилипание сессий и тд.
• Поисковые системы (elastic, solr и тд), как сделать поиск в конкретной системе.
• Мониторинг, золотые технические метрики.
• Алертинг, как сделать и понять, что все стало плохо.
• Трейсинг, для поиска узких мест.
• Конкретные реализации всех пунктов выше и их особенности, если не работали, то хотя бы как работает внутри.

Банальные вещи опускаю, по типу как сделать параллельно, асинхронно, быстро, надежно и тд на технологии abc.

Какие типичные ошибки совершают кандидаты

Как интервьюер с опытом более 120 собесов, я накопил опыт и уже вижу типичные ошибки и ловушки, хотелось бы ими поделиться и помочь с прохождением секции.

• Собирать требования и их не использовать

Часто кандидаты смотрят 2-3 видео на ютубе и начинают их повторять. Задают вопросы по нагрузке, данным, etc, но собрав цифры оставляют их в стороне. Я очень люблю спрашивать вопросы вида, а зачем тебе это знать, что пытаешься получить и тогда получаются полезные погружения в детали. Например, что разница читающей и пишущей нагрузки в 100 раз и нужны совершенно разные механизмы и гарантии для точек входа. В этот пункт также входит полное игнорирование требований по ходу погружения в детали, например мы сразу знаем, что можем допустить задержку или данные имеют срок жизни, а система к этому не готова.

• Пытаться сделать все и сразу

Очень типично для в целом понятных задач и проблем и кандидатов до уровня middle+. Кандидаты начинают бегать в своих мыслях говорят много лишних слов, прыгают по темам и не могут структурно приступить к задаче, приходится направлять кандидатов подсказывать с чего начинать и останавливать их на полуслове, чтобы успеть.

• Расширение границ системы

Иногда кандидату кажется, что он уже все понял о задаче и знает как сделать еще лучше, каких фичей добавить и сразу их закладывает и начинает их проектировать, хотя только зафиксировать почему принято конкретное решение достаточно. Если так поступать со всем, то времени не хватит, хорошие идеи стоит записывать, чтобы вернуться к ним позже, если останется время.

• Космолёт для 2 RPS нагрузки или еще один гугл

Часто в решениях ожидают увидеть эволюцию, если мы что-то делаем, то не обязательно станем гуглом, а лишь попытаемся, соответственно бизнес не может себе позволить миллион сервисов и кластеров в разных регионах, а делает модульный монолит, возможно с частью готовых компонентов. А лишь далее развивает решение, вводит новые части и отделяет старые.

• Уверенно говорить о том чего не понимаешь или дословное цитирование книжек

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

Наиболее ожидаемый ответ такого рода - кое как рассказывают зачем это нужно, выбор сервера по остатку и начинается несвязный набор слов про кольцо консистентного хэширования. Сразу появляются вопросы по типу а зачем так делать, какая разница между подходами, плюсы и минусы. И мои самые любимые вопросы, а вот пришел запрос как на уровне приложения выбрать сервер. Тут сразу становится понятно. Или надо добавить новый сервер и подключить к нему приложение как это раскатить. Или как выбрать сервер в который сохранить id ведь нет, для чтения понятно, а на запись - нет.

• Потеря данных между системами

Передача данных прямыми вызовами или прикручивание очередей сбоку. Хорошо бы подумать как потом не искать пропавшую связку между сущностями.

• Долгосрочная поддержка хранилищ

Через 2,3,5,10 лет система будет хранить кучу архивных данных, с ними надо что-то делать, придумать процесс архивации и отдельное хранилище, сюда же входит шардирование.

• Использование базы не по назначению

Часто сводится к банальному использованию одной базы для всего, например постгрес для картинок, полнотекстового поиска с большой нагрузкой и тд.

• Слишком абстрактное решение в плане организации и запуска кода

Очень часто компоненты и части системы взяты просто с потолка и при развязке на физические сервера и приложения ничего не понятно. Хорошо бы сразу решить как будет работать приложение в облаке, на своих серверах, если в облаке какой провайдер, какая стратегия работы с ним, если свои сервера, то как будем размещать приложение. Я как интервьюер открыт к любым решениям, главное их аргументировать.

• Только технический мониторинг

Вообще это большая отдельная тема, но на самом деле важны не технические метрики, а продуктовые. Гораздо важнее искать проблему широко и спускаться к отдельным частям системы, нежели искать проблему в конкретном блоке. И очень важно, что в сложных системах фон ошибок - это норма, главное чтобы это не переставало быть фоном.

• Решение проблем самым простым способом в лоб, без анализа альтернатив

Умение рассуждать и сравнить варианты один из ключевых навыков, который тоже оценивается и для уровня middle+ скорее ожидается. Главное соблюдать тонкий баланс между построением костылей и решением в лоб, тут поможет только опыт и практика проектирования.

Советы

• Инвертируем ошибки из пункта выше 🙂.

• Начинайте сверху и погружайтесь в детали постепенно.

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

• Делитесь мыслями, это поможет интервьюеру полноценно оценить вас, но и если что подключиться, если будет необходимо.

• Делитесь своим реальным опытом, если знаете какие-то особенности эксплуатации и доработки систем, обязательно о них расскажите.

• Не стесняйтесь рассуждать как что-то сделать, даже если вы не знаете готовых решений, паттернов, алгоритмов etc, крутых кандидатов видно издалека, гораздо важнее понимание как прийти к результату, чем сам результат, только надо обязательно говорить, что не делал, но если бы мне пришлось такое придумать, то делал бы так. У меня был один из сильнейших кандидатов, который не знал всех новомодных названий и паттернов, но просто по ходу интервью все сам смог придумать и пояснить зачем так делать.

• Не говорите без остановки и не подумав, к словам любят цепляться, особенно интервьюеры камни.

• Попробуйте сразу на старте придумать контракты для компонентов системы и расширять их по ходу.

• Записывайте все свои идеи, чтобы если что вернуться к ним позже, лучше на платформе интервью.

• Попробуйте спроектировать какую-то систему по формату интервью Это поможет почувствовать интервью и получить хотя бы какую-то практику до реальной сессии. Я проводил серию стримов именно с этой целью.

• Прочитайте парочку источников по тому как пройти интервью, советую Alex Xu.

• Посмотрите видео на ютубе с реальными записями с интервью.

Дополнительные источники для изучения:

• Высоконагруженные приложения. Программирование, масштабирование, поддержка, Мартин Клеппман. Кабанчик, да банально, но желательно прочтение на 2 раза с интервалом в полгода, узнаете много всего нового
• System Design Interview – An insider’s guide, Alex Xu. Книжка только по верхам.
• Авторский блог Alexander Polomodov, случайно наткнулся, но много хороших статей с разбором - советуую

P.S.

Регулярная разминка в таких задачках позволяет развить свой внутренний технологический радар и насмотренность на проблемы в обычной работе, например ревью PR, принятие решений о новых частях системы и доработке старых.

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

P.P.S

Скоро буду проводить mock интервью для желающих, чтобы помочь вам подготовиться, а себе заработать, пишите на почту

Контакты тут