Как подготовиться к сложному собеседованию по system design?
Бесплатное пошаговое руководство. Время чтения — 12 минут
ex-Team Lead в Яндекс
Владимир Балун
руководство для тех, кто:
- готовится к собеседованию по System Design и хочет улучшить свои навыки в проектировании систем;
- недавно провалил собеседование по проектированию большой системы;
- посмотрел видео по System Design на YouTube и ничего не понял;
- давно работает и кому тяжело демонстрировать свои знания и навыки в условиях ограниченного времени, которое выделяется на интервью.
Читай шаг за шагом или сразу переходи к интересующему разделу по якорной ссылке. Главное помни: это руководство не сделает тебя экспертом, но поможет подготовиться к сложному собеседованию по System Design и чувствовать себя увереннее
Автор — владимир балун, ex-team lead в яндекс
руководил разработкой системы трейсинга (11ГБ/с трафик)
Yandex
разрабатывал системы трейсинга и непрерывного профилирования
Ozon
разрабатывал движок по подбору таргетированной рекламы
Tinkoff
разрабатывал Kaspersky Endpoint Security
Kaspersky Lab
поддерживал ICQ и разрабатывал My Teams
Mail.ru
руководил курсом Golang Developer.Professional
OTUS
Saint HighLoad++, GolangConf, CodeFest, Стачка и E-CODE
Спикер конференций
Откроется после 6-ой главы
1) Зачем нужно собеседование по System Design
Проектирование систем — один из этапов в процессе найма backend-разработчиков. Оно предназначено для проверки hard skills:
Кроме того, собеседования по System Design (проектированию ИТ-систем) популярны у работодателей, потому что на них легко проверить твои навыки общения и оценить умение решать реальные задачи в условиях неопределенности.
Опытный разработчик может сказать:
- умеешь ли ты проектировать большие высоконагруженные системы;
- сталкивался ли ты с этим на практике;
- есть ли у тебя основополагающие знания в этой области;
- есть ли у тебя понимание и знание системных требований, ограничений и узких мест.
Кроме того, собеседования по System Design (проектированию ИТ-систем) популярны у работодателей, потому что на них легко проверить твои навыки общения и оценить умение решать реальные задачи в условиях неопределенности.
Опытный разработчик может сказать:
«В мире много платных и бесплатных решений, из которых я могу собрать систему, как из деталей конструктора. Если мне нужна база данных, я возьму PostgreSQL и буду хранить свои данные в нем, а сервис реализую на популярном фреймворке для написания HTTP сервисов моего любимого языка программирования»
И это будет отличным решением, если ты собрался писать сервис для небольшой аудитории, но сервисы большой компании сложнее устроены и намного сильнее нагружены.
Если рассматривать Google, Яндекс, VK, Тинькофф и других, то у них все используемые решения очень быстро перестают помещаться на один сервер, а учитывая требования высокой доступности, обязательно располагаются в нескольких локациях. И, как только система становится распределенной, сложность ее архитектуры и реализации на порядок увеличивается. System Design интервью проверяет твои навыки по проектированию и работе с подобными системами.
Многие боятся таких собеседований. Вопросы на них могут быть расплывчатыми и слишком общими.
Если рассматривать Google, Яндекс, VK, Тинькофф и других, то у них все используемые решения очень быстро перестают помещаться на один сервер, а учитывая требования высокой доступности, обязательно располагаются в нескольких локациях. И, как только система становится распределенной, сложность ее архитектуры и реализации на порядок увеличивается. System Design интервью проверяет твои навыки по проектированию и работе с подобными системами.
Многие боятся таких собеседований. Вопросы на них могут быть расплывчатыми и слишком общими.
Например: «Спроектируйте общеизвестный сервис X»
Отсутствие энтузиазма у кандидата вполне объяснимо. В конце концов, кому под силу в течение часа спроектировать популярный сервис, над которым работали сотни или тысячи инженеров?
Хорошая новость заключается в том, что от тебя этого никто не ждет, поскольку в проектировании ИТ-систем не существует единственно правильных решений, а реальные системы имеют чрезвычайно сложную архитектуру.
Например, поиск Яндекса только с виду выглядит просто. Количество технологий, стоящих за этой простотой, поистине потрясающее. Но если никто не ждет, что ты за час успеешь спроектировать настоящую систему, то какая от этого польза?
Собеседование по проектированию систем имитирует реальный процесс, в ходе которого пара коллег совместно работают над какой-то общей не совсем ясной задачей и находят подходящее решение. Задача носит общий характер, и идеального решения не существует. Важен сам процесс проектирования.
Это позволяет тебе продемонстрировать свои навыки инженера, обосновать выбор тех или иных архитектурных решений и конструктивно ответить на возникшие вопросы. Многие считают, что это интервью сводится к техническим навыкам проектирования кандидата, но это лишь малая его часть. Эффективное собеседование четко сигнализирует о способности кандидата работать совместно, выдерживать давление и конструктивно справляться с расплывчатыми задачами.
Представь себя на месте интервьюера и попробуй понять: что он пытается узнать во время собеседования по проектированию той или иной системы?
Интервьюер хочет увидеть, что ты:
Хороший интервьюер также ищет отрицательные признаки. Чрезмерно усложненные архитектурные решения — болезнь инженеров, которые восхищаются чистотой архитектуры и не желают идти на компромиссы. Они зачастую не догадываются о тех расходах, которые влекут за собой переусложненные системы, и многим компаниям это неведение дорого обходится. Эту склонность явно не стоит демонстрировать. Среди других нежелательных качеств можно выделить узкий кругозор и упрямство:)
Хорошая новость заключается в том, что от тебя этого никто не ждет, поскольку в проектировании ИТ-систем не существует единственно правильных решений, а реальные системы имеют чрезвычайно сложную архитектуру.
Например, поиск Яндекса только с виду выглядит просто. Количество технологий, стоящих за этой простотой, поистине потрясающее. Но если никто не ждет, что ты за час успеешь спроектировать настоящую систему, то какая от этого польза?
Собеседование по проектированию систем имитирует реальный процесс, в ходе которого пара коллег совместно работают над какой-то общей не совсем ясной задачей и находят подходящее решение. Задача носит общий характер, и идеального решения не существует. Важен сам процесс проектирования.
Это позволяет тебе продемонстрировать свои навыки инженера, обосновать выбор тех или иных архитектурных решений и конструктивно ответить на возникшие вопросы. Многие считают, что это интервью сводится к техническим навыкам проектирования кандидата, но это лишь малая его часть. Эффективное собеседование четко сигнализирует о способности кандидата работать совместно, выдерживать давление и конструктивно справляться с расплывчатыми задачами.
Представь себя на месте интервьюера и попробуй понять: что он пытается узнать во время собеседования по проектированию той или иной системы?
Интервьюер хочет увидеть, что ты:
- корректно и просто выражаешь свои мысли
- знаешь и понимаешь требования и ограничения
- можешь отстаивать свои технические решения (как во время разговоров с коллегами на работе)
- имеешь навыки и опыт проектирования больших высоконагруженных систем
Хороший интервьюер также ищет отрицательные признаки. Чрезмерно усложненные архитектурные решения — болезнь инженеров, которые восхищаются чистотой архитектуры и не желают идти на компромиссы. Они зачастую не догадываются о тех расходах, которые влекут за собой переусложненные системы, и многим компаниям это неведение дорого обходится. Эту склонность явно не стоит демонстрировать. Среди других нежелательных качеств можно выделить узкий кругозор и упрямство:)
2) кому предлагают пройти собеседование по System Design
Секция по System Design проводится только для backend-разработчиков
Для фронтендеров, мобильных разработчиков и ML-инженеров подобный формат слабо применим. У них есть свои интервью на проектирование, которые применимы к их предметной области, поэтому эти специальности затрагивать не буду.
Важно понимать, что от компании к компании может все сильно различаться. Например, в Тинькофф и Яндексе собеседование по System Design мидлам раньше не давали. Обычно его проводили тем, кто претендует на роль сеньора и выше
Важно понимать, что от компании к компании может все сильно различаться. Например, в Тинькофф и Яндексе собеседование по System Design мидлам раньше не давали. Обычно его проводили тем, кто претендует на роль сеньора и выше
В большинстве случаев, если тебе предлагают пройти собеседование, ты претендуешь на позицию, как минимум, старшего специалиста
3) как пройти интервью по проектированию ИТ-систем
Собеседование по System Design может быть абсолютно разным от компании к компании. Тебя могут ждать:
- Проектирование популярного сервиса с нуля
- Проектирование новой функциональности для существующего сервиса
- Рассказ об архитектуре твоего проекта (тебе придется рассказать архитектуру с прошлого месте работа и подумать, что было сделано плохо, что можно улучшить и как). Если архитектура с прошлого места под NDA, то тебя могут попросить изобразить архитектуру мечты твоего прошлого проекта, учитывая все боли и проблемы
Часто тема System Design интервью оказывается связана с твоей предметной областью или предметной областью компании, в которую ты устраиваешься.
Например, если ты проходишь собеседование в команду, которая занимается разработкой баз данных, скорее всего, тебя попросят спроектировать именно ее. Потребуется выбрать общую архитектуру, а потом пройтись по всем компонентам или, наоборот, сосредоточиться на каком-то одном аспекте.
Например, если ты проходишь собеседование в команду, которая занимается разработкой баз данных, скорее всего, тебя попросят спроектировать именно ее. Потребуется выбрать общую архитектуру, а потом пройтись по всем компонентам или, наоборот, сосредоточиться на каком-то одном аспекте.
Обычно собеседование по System Design длится 45-60 минут. Все зависит от того, сколько времени ты потратишь до и после собеседования на различные вопросы и приветствие. По итогам выходит матрица оценки, где получается взвешенная оценка по каждому из этапов.
Пройти такое собеседование непросто, поскольку в проектировании ИТ-систем нет единственно верного решения. Каждое интервью по проектированию архитектуры уникально и его можно пройти множеством различных способов.
Например, в собеседованиях по программированию (алгоритмам) какую-то задачу можно решить одним, двумя или максимум тремя способами, а спроектировать систему можно множеством различных.
Да, существуют типичные подходы к решению любой задачи по системному дизайну, а также приемы при проектировании определенных видов систем, но даже в них можно много чего делать по-разному. Часто у кандидатов получаются абсолютно разные архитектуры.
Тем не менее, у всех интервью по проектированию IT-систем есть общие черты. Рассмотрим основные этапы стандартного сценария, поскольку правильная стратегия и знания являются ключевыми факторами, чтобы успешно пройти все этапы собеседования:
Пройти такое собеседование непросто, поскольку в проектировании ИТ-систем нет единственно верного решения. Каждое интервью по проектированию архитектуры уникально и его можно пройти множеством различных способов.
Например, в собеседованиях по программированию (алгоритмам) какую-то задачу можно решить одним, двумя или максимум тремя способами, а спроектировать систему можно множеством различных.
Да, существуют типичные подходы к решению любой задачи по системному дизайну, а также приемы при проектировании определенных видов систем, но даже в них можно много чего делать по-разному. Часто у кандидатов получаются абсолютно разные архитектуры.
Тем не менее, у всех интервью по проектированию IT-систем есть общие черты. Рассмотрим основные этапы стандартного сценария, поскольку правильная стратегия и знания являются ключевыми факторами, чтобы успешно пройти все этапы собеседования:
- Сбор и формализация требований (5-10 минут)
- Приблизительная оценка нагрузки (5 минут)
- Проектирование API для будущей системы (5 минут)
- Проектирование высокоуровневой архитектуры и модели данных (20-30 минут)
- Обсуждение отказоустойчивости и масштабируемости архитектуры (5 минут)
- Расчет необходимых ресурсов (железа) для будущей системы (5-10 минут — требуется не везде)
Не думай как программист, думай как технический руководитель
Во время прохождения интервью ты будешь выступать в роли технического руководителя, а интервьюер — в роли младшего инженера, который будет внедрять твой проект. У младших специалистов будет много вопросов, и ты как технический руководитель должен поощрять и даже предугадывать эти вопросы, т. е. вести интервьюера за руку во время проектирования системы
Во время прохождения интервью ты будешь выступать в роли технического руководителя, а интервьюер — в роли младшего инженера, который будет внедрять твой проект. У младших специалистов будет много вопросов, и ты как технический руководитель должен поощрять и даже предугадывать эти вопросы, т. е. вести интервьюера за руку во время проектирования системы
1. Собери и формализуй требования
Вероятно, ты сталкивался на работе с непонятными ТЗ и требованиями, которые приходилось формализовывать. Здесь так же. Интервьюер не ждет, что ты сразу же начнешь проектировать систему, потому что нельзя сделать то, не знаю что. Это проверка в том числе soft skills и тебе нужно начать диалог, чтобы выяснить, что именно предстоит проектировать
Представь, что тебя попросили разработать «сервис обмена фотографиями» с некоторыми минимально определенными возможностями. Можно сразу начать проектировать что-то вроде Instagram, исходя из предположения, что все изображения будут относительно небольшими, не будут рассматриваться подробно, и что приемлемо значительное сжатие для экономии памяти и пропускной способности. Но интервьюер не сказал ни слова о проектировании Instagram, а кроме него существует множество различных типов сервисов обмена фотографиями. Например, Flickr или 500px — сервисы для фотографов, чтобы демонстрировать работы в высоком разрешении.
В жизни решения, связанные с проектированием, часто происходят в условиях нехватки данных. Конечно, важны метрики проекта для его правильного развития и, конечно, аналитики и менеджеры продукта постараются обеспечить тебя наиболее полной информацией. Но и этого может быть мало.
Представь, что тебя попросили разработать «сервис обмена фотографиями» с некоторыми минимально определенными возможностями. Можно сразу начать проектировать что-то вроде Instagram, исходя из предположения, что все изображения будут относительно небольшими, не будут рассматриваться подробно, и что приемлемо значительное сжатие для экономии памяти и пропускной способности. Но интервьюер не сказал ни слова о проектировании Instagram, а кроме него существует множество различных типов сервисов обмена фотографиями. Например, Flickr или 500px — сервисы для фотографов, чтобы демонстрировать работы в высоком разрешении.
В жизни решения, связанные с проектированием, часто происходят в условиях нехватки данных. Конечно, важны метрики проекта для его правильного развития и, конечно, аналитики и менеджеры продукта постараются обеспечить тебя наиболее полной информацией. Но и этого может быть мало.
Если вводных данных недостаточно, можно и нужно выдвигать обоснованные гипотезы на основе той информации, которая уже известна
Сначала тебе нужно определить функциональные требования, т.е. какие функции будут доступны пользователю. Например, будут ли в системе оповещения о пропущенных звонках или поиск товаров по названиям. Здесь очень важно задавать правильные вопросы и уточнять, что входит в задачу, чтобы не тратить время на неважные детали. В конце нужно сделать приоритизацию функциональных требований, чтобы на следующих этапах понимать, чему уделять больше внимания, а чему меньше.
Не трать много времени на сбор функциональных требований. Твоя задача — формализовать основную функциональность.
Не забудь, что для реального проекта сбор требований — один из важнейших этапов. Если интервью предполагает, что тебе нужно сделать это быстро, то на работе собирать функциональные требования нужно очень внимательно
Не забудь, что для реального проекта сбор требований — один из важнейших этапов. Если интервью предполагает, что тебе нужно сделать это быстро, то на работе собирать функциональные требования нужно очень внимательно
Вторым шагом нужно уточнить нефункциональные требования. Они определяют свойства системы или ограничения, которые не относятся к функциональности. Например, ее производительность и отказоустойчивость. В большинстве случаев хватает сбора следующих:
1) Количество пользователей
1) Количество пользователей
- Вопрос:Какое количество пользователей (DAU / MAU) ожидается в будущем приложении, а также, как оно будет расти?Ответ:50 000 DAU
2) Поведение пользователей
- Вопрос:Сколько в среднем один пользователь будет создавать запросов к будущему приложению в день?Ответ:Один пользователь в среднем будет делать 12 запросов в день к приложению
3) Регионы использования приложения
- Вопрос:На аудиторию каких регионов/стран будет запущено будущее приложение?Ответ:Только на СНГ
4) Сезонности в приложении
- Вопрос:Будут ли сезонности, когда приложением в определенный период будут пользоваться большое количество пользователей?Ответ:Да, сезоны осенних и предновогодних распродаж
5) Условия хранения данных
- Вопрос:Данные храним всегда или можно удалять/агрегировать какие-либо данные спустя какое-либо время?Ответ:Храним всегда
6) Лимиты и ограничения
- Вопрос:Если делаем подписки, то какое максимальное количество подписчиков может быть у пользователя?Ответ:1 000 000 подписчиков
7) Временные ограничения
- Вопрос:За сколько письмо должно успевать доходить до адресата?Ответ:Не более, чем за 5 секунд
8) Доступность приложения
- Вопрос:Сколько по времени приложение может быть недоступно за год?Ответ:Не более чем несколько часов простоя в год
В конце также определи сравнительную важность нефункциональных требований между собой. Так ты поймешь, чему уделять больше внимания, а чему меньше.
2. Приблизительно оцени нагрузку
После формализации требований выдели пару-тройку основных функций системы и посчитай для них примерную нагрузку. Здесь очень важно слово примерную — не нужно считать все до битиков и байтиков, смело все округляй.
Твоя задача — понять порядок и характер нагрузки, а потом рассказать об этом интервьюеру. В контексте нагрузки, чаще всего требуется:
Твоя задача — понять порядок и характер нагрузки, а потом рассказать об этом интервьюеру. В контексте нагрузки, чаще всего требуется:
Регистрация занимает <1 минуты
Зарегистрируйся на платформе, чтобы продолжить
Задачи, которые встречаются чаще всего + материалы для подготовки
Продолжение + 16 типичных ошибок и советы по подготовке
После регистрации откроются:
2 урока по System Design: теория партиционирования и шардирования
System Design-интервью — это формат собеседования, на котором оценивают способность проектировать масштабируемые и надежные системы.
Фокус на таком собеседовании — не на написании кода, а на архитектурном мышлении и аргументации своих решений.
Обычно такие собеседования проходят, где обсуждают системный дизайн, проходят в формате совместного проектирования решения. На таком собеседовании важно не столько итоговое решение, сколько ход рассуждений, способность уточнять требования и адаптировать архитектуру под изменяющиеся условия задачи.
Если ты готовишься к сложному техническому собеседованию по системному дизайну (System Design) в крупной IT-компании, важно не просто знать теорию - также важны подготовка к собеседованию и понимание, как системный дизайн работает на практике. Так интервьюер проверит твой уровень, насколько глубоко у тебя развито понимание архитектуры, как ты умеешь анализировать требования и предлагать решения - это покажет, насколько хорошо в целом ты знаешь системный дизайн.
На интервью по системному дизайну тебя могут попросить спроектировать приложение или сервис с высокой нагрузкой. Также на собеседовании интервьюер обращает внимание на то, как кандидат объясняет свои решения, какие инструменты предлагает использовать и насколько логично проходит весь процесс.
Для прохождения собеседования по системному дизайну (System Design) тебе потребуется понимание того, какие существуют архитектурных подходы и как обеспечивается эффективное взаимодействие связанных сервисов. Например, важно понимать, как компании решают задачи масштабирования и поддержки корпоративный инфраструктуры.
На интервью по системному дизайну (System Design) ты должен показать не только знания, но и практику. Работают реальные кейсы: например, создание микросервиса с высокой нагрузкой или проектирование баз для хранения информации. Важно уметь оценить требования, предложить несколько вариантов реализации и объяснить их плюсы и минусы.
Для успешного прохождения собеседования по системному дизайну (System Design) рекомендуется дополнительно изучить готовые решений и материалы. Это помогает разработчику лучше подготовиться к собеседованию, понять ожидания интервьюера и уверенно чувствовать себя на собеседовании.
Хорошая подготовка к интервью по System Design — это не только теория, но и регулярная практика. Чем больше ты тренируешься и лучше знаешь системный дизайн на практике, тем проще тебе будет пройти любое интервью и получить желаемую позицию.
Фокус на таком собеседовании — не на написании кода, а на архитектурном мышлении и аргументации своих решений.
Обычно такие собеседования проходят, где обсуждают системный дизайн, проходят в формате совместного проектирования решения. На таком собеседовании важно не столько итоговое решение, сколько ход рассуждений, способность уточнять требования и адаптировать архитектуру под изменяющиеся условия задачи.
Если ты готовишься к сложному техническому собеседованию по системному дизайну (System Design) в крупной IT-компании, важно не просто знать теорию - также важны подготовка к собеседованию и понимание, как системный дизайн работает на практике. Так интервьюер проверит твой уровень, насколько глубоко у тебя развито понимание архитектуры, как ты умеешь анализировать требования и предлагать решения - это покажет, насколько хорошо в целом ты знаешь системный дизайн.
На интервью по системному дизайну тебя могут попросить спроектировать приложение или сервис с высокой нагрузкой. Также на собеседовании интервьюер обращает внимание на то, как кандидат объясняет свои решения, какие инструменты предлагает использовать и насколько логично проходит весь процесс.
Для прохождения собеседования по системному дизайну (System Design) тебе потребуется понимание того, какие существуют архитектурных подходы и как обеспечивается эффективное взаимодействие связанных сервисов. Например, важно понимать, как компании решают задачи масштабирования и поддержки корпоративный инфраструктуры.
На интервью по системному дизайну (System Design) ты должен показать не только знания, но и практику. Работают реальные кейсы: например, создание микросервиса с высокой нагрузкой или проектирование баз для хранения информации. Важно уметь оценить требования, предложить несколько вариантов реализации и объяснить их плюсы и минусы.
Для успешного прохождения собеседования по системному дизайну (System Design) рекомендуется дополнительно изучить готовые решений и материалы. Это помогает разработчику лучше подготовиться к собеседованию, понять ожидания интервьюера и уверенно чувствовать себя на собеседовании.
Хорошая подготовка к интервью по System Design — это не только теория, но и регулярная практика. Чем больше ты тренируешься и лучше знаешь системный дизайн на практике, тем проще тебе будет пройти любое интервью и получить желаемую позицию.