Как эффективно провести 45-минутное собеседование по проектированию системы.

Интервью по проектированию систем (SDI) привлекли большое внимание в последние несколько лет. Теперь это стандартная часть каждого собеседования по разработке программного обеспечения. Эти собеседования оценивают способность кандидата работать со сложными системами. Показатели на этих собеседованиях определяют должность и зарплату, предлагаемую интервьюирующей компанией. Инженеры обычно борются с SDI отчасти из-за отсутствия у них опыта разработки крупномасштабных систем, а отчасти из-за неструктурированного характера SDI. Инженеры, имеющие опыт создания таких систем, до сих пор находят эти собеседования неудобными, главным образом потому, что проблемы проектирования открыты и не имеют стандартного ответа.

Как правило, инженеры-программисты испытывают трудности с собеседованиями по проектированию системы по трем основным причинам:

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

Как и в случае с собеседованиями по программированию, кандидаты, не предпринявшие преднамеренных усилий для подготовки к SDI, в основном работают плохо, особенно в ведущих компаниях, таких как Google, Facebook, Amazon, Microsoft и т. д. В этих компаниях кандидаты, не показавшие результатов выше среднего, имеют ограниченный возможность получить предложение. С другой стороны, хорошие результаты всегда приводят к лучшему предложению (более высокой должности и зарплате), поскольку это доказывает способность кандидата работать со сложной системой.

За свою профессиональную карьеру я прошел более 200 собеседований по проектированию систем. Моя цель в этом посте — предоставить пошаговое руководство о том, как подходить к вопросам проектирования системы во время собеседования; это поможет в преодолении проблем, отмеченных выше.

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

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

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

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

3. Определение системного интерфейса: определите, какие API ожидаются от системы. Это не только установит точный контракт, ожидаемый от системы, но и гарантирует, что вы не ошиблись в каких-либо требованиях.

4. Определение модели данных: раннее определение модели данных системы прояснит, как данные будут передаваться между различными компонентами системы, а позже также поможет разделять данные и управлять ими.

5. Проект высокого уровня: нарисуйте блок-схему с 5–6 блоками, представляющими основные компоненты вашей системы. Вы должны определить достаточное количество компонентов, необходимых для полного решения реальной проблемы.

6. Детальный дизайн: углубиться в 2–3 компонента; Отзывы интервьюера всегда должны указывать вам, какие части системы он хочет, чтобы вы объяснили подробнее. Вы должны быть в состоянии предоставить различные варианты, их плюсы и минусы, и почему вы выбираете их?

7. Выявление и устранение узких мест: постарайтесь обсудить как можно больше узких мест (и различных подходов к их устранению).

Давайте подробно обсудим каждый шаг на реальном кейсе:

Шаг 1. Уточнение требований

Всегда полезно задавать вопросы о точном масштабе проблемы, которую мы решаем. Вопросы дизайна в основном открытые, и на них нет ОДНОГО правильного ответа; Вот почему прояснение двусмысленности в начале интервью становится критическим. Кандидаты, которые тратят достаточно времени на определение конечных целей системы, всегда имеют больше шансов на успех на собеседовании. Кроме того, поскольку у нас есть только 35–40 минут на проектирование (предположительно) большой системы, нам следует уточнить, на каких частях системы мы сосредоточимся.

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

  • Смогут ли пользователи нашего сервиса публиковать твиты и подписываться на других людей?
  • Должны ли мы также создавать и отображать временную шкалу пользователя?
  • Будут ли твиты содержать фото и видео?
  • Мы концентрируемся только на бэкэнде, или мы разрабатываем и фронтенд?
  • Смогут ли пользователи искать твиты?
  • Нужно ли отображать популярные темы?
  • Будут ли пуш-уведомления о новых (или важных) твитах?

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

Шаг 2. Предварительная оценка

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

  • Какой масштаб ожидается от системы (например, количество новых твитов, количество просмотров твитов, количество поколений временной шкалы в секунду и т. д.)?
  • Сколько памяти нам понадобится? У нас будут другие требования к хранилищу, если пользователи смогут размещать фото и видео в своих твитах.
  • Какое использование пропускной способности сети мы ожидаем? Это будет иметь решающее значение при принятии решения о том, как мы будем управлять трафиком и балансировать нагрузку между серверами.

Шаг 3: Определение системного интерфейса

Определите, какие API ожидаются от системы. Это не только установит точный контракт, ожидаемый от системы, но также гарантирует, что мы не ошиблись в каких-либо требованиях. Ниже приведены некоторые примеры API для нашего сервиса, похожего на Twitter:

postTweet(user_id, tweet_data, tweet_location, timestamp, …)
generateTimeline(user_id, current_time, user_location, …)
markTweetFavorite(user_id, tweet_id, timestamp, …)

Шаг 4: Определение модели данных

Определение модели данных в начале интервью позволит выяснить, как данные будут передаваться между различными компонентами системы. Позже он поможет вам разделить данные и управлять ими. Кандидат должен уметь идентифицировать различные объекты системы, то, как они будут взаимодействовать друг с другом, и различные аспекты управления данными, такие как хранение, транспортировка, шифрование и т. д. Вот некоторые объекты для нашего сервиса, похожего на Twitter:

Пользователь: UserID, имя, адрес электронной почты, DoB, CreationData, LastLogin и т. д.
Твит: TweetID, Content, TweetLocation, NumberOfLikes, TimeStamp и т. д.
UserFollowo: UserdID1, UserID2
Избранные твиты: UserID, TweetID, TimeStamp

Какую систему баз данных мы должны использовать? Будет ли NoSQL, подобный Cassandra, лучше всего соответствовать нашим потребностям, или нам следует использовать решение, подобное MySQL? Какое блочное хранилище мы должны использовать для хранения фотографий и видео?

Шаг 5: Высокоуровневый дизайн

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

Для Twitter на высоком уровне нам потребуется несколько серверов приложений для обслуживания всех запросов на чтение/запись с балансировщиками нагрузки перед ними для распределения трафика. Если мы предполагаем, что у нас будет намного больше трафика чтения (по сравнению с записью), мы можем решить иметь отдельные серверы для обработки этих сценариев. На бэкенде нам нужна эффективная база данных, которая может хранить все твиты и поддерживать огромное количество чтений. Также нам понадобится распределенная файловая система хранения для хранения фото и видео.

Шаг 6: Детальный дизайн

Копните глубже в два или три основных компонента; обратная связь интервьюера всегда должна подсказывать нам, какие части системы требуют дальнейшего обсуждения. Мы должны быть в состоянии представить различные подходы, их плюсы и минусы и объяснить, почему мы предпочтем один подход другому. Помните, что нет единого ответа; единственно важным является рассмотрение компромиссов между различными вариантами, не забывая при этом о системных ограничениях.

  • Поскольку мы будем хранить огромное количество данных, как мы должны разделить наши данные, чтобы распределить их по нескольким базам данных? Должны ли мы пытаться хранить все данные пользователя в одной базе данных? Какую проблему это может вызвать?
  • Как мы будем справляться с горячими пользователями, которые много твитят или подписаны на многих людей?
  • Поскольку хронология пользователей будет содержать самые последние (и актуальные) твиты, должны ли мы пытаться хранить наши данные таким образом, чтобы они были оптимизированы для сканирования последних твитов?
  • Сколько и на каком уровне мы должны ввести кеш, чтобы ускорить работу?
  • Какие компоненты нуждаются в лучшей балансировке нагрузки?

Шаг 7. Выявление и устранение узких мест

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

  • Есть ли в нашей системе единая точка отказа? Что мы делаем, чтобы смягчить его?
  • Достаточно ли у нас реплик данных, чтобы, если мы потеряем несколько серверов, мы все еще могли обслуживать наших пользователей?
  • Точно так же достаточно ли у нас копий различных запущенных служб, чтобы несколько сбоев не привели к полному отключению системы?
  • Как мы следим за работой нашего сервиса? Получаем ли мы оповещения в случае сбоя критических компонентов или снижения их производительности?

Краткое содержание

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

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

Узнайте больше об интервью по системному проектированию:



Полное руководство по прохождению собеседования по системному проектированию
Процесс из 7 шагов для ответа на любой вопрос собеседования по системному проектированию. Вопросы на собеседовании по проектированию систем задаются на…designgurus.org



Спасибо за прочтение