Подготовка к интервью по системному дизайну (System Design Interview)

Часть 1.

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

Большинство инженеров боятся интервью по системному дизайну (SDI) частично из-за отсутствия опыта в разработке больших масштабируемых систем и частично из-за неструктурированной природы SDIs. Даже инженеры, кто имеет опыт в построении таких систем, не очень комфортно себя ощущают на этих интервью. Основная причина этого — то что интервью по системному дизайну не имеет стандартных ответов и носит открытый характер.

Эти статьи помогут стать лучше в SDI.

Шаг 1. Классификация требований.

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

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

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

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

1) Смогут ли пользователи нашего сервиса постить твиты и подписываться на других пользователей?

2) Должны ли мы создать и отображать ленту новостей?

3) Будут ли твиты содержать фото и видео?

4) Мы с фокусируемся только на бэкэнденде или будем разрабатывать фронтенд тоже?

5) Смогут ли пользователи иметь “твиты”?

6) Должны ли мы отображать самую “горячую”/популярную тему/твит?

7) Будут ли какие-либо push уведомления на новые (или важные) твиты?

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

Шаг 2. Определение системных интерфейсов.

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

postTweet(user_id, tweet_data, tweet_location, user_location, timestamp, …)

generateTimeline(user_id, current_time, user_location, …)

markTweetFavorite(user_id, tweet_id, timestamp, …)

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