Как подготовиться к сложному собеседованию по system design?

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

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

Проектирование системы — один из этапов в процессе найма backend-разработчиков. Оно предназначено для проверки hard skills:

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

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

Опытный разработчик может сказать:

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

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

Многие боятся таких собеседований. Вопросы на них могут быть расплывчатыми и слишком общими.

Отсутствие энтузиазма у кандидата вполне объяснимо. В конце концов, кому под силу в течение часа спроектировать популярный сервис, над которым работали сотни или тысячи инженеров?

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

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

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

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

Представь себя на месте интервьюера и попробуй понять: что он пытается узнать во время собеседования по проектированию той или иной системы?

Интервьюер хочет увидеть, что ты:

• корректно и просто выражаешь свои мысли
• знаешь и понимаешь системные требования и ограничения
• можешь отстаивать свои технические решения (как во время разговоров с коллегами на работе)
• имеешь навыки и опыт проектирования больших высоконагруженных систем

Хороший интервьюер также ищет отрицательные признаки. Чрезмерно усложненные архитектурные решения — болезнь инженеров, которые восхищаются чистотой архитектуры и не желают идти на компромиссы. Они зачастую не догадываются о тех расходах, которые влекут за собой переусложненные системы, и многим компаниям это неведение дорого обходится. Эту склонность явно не стоит демонстрировать. Среди других нежелательных качеств можно выделить узкий кругозор и упрямство:)

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

Важно понимать, что от компании к компании может все сильно различаться. Например, в Тинькофф и Яндексе собеседование по System Design мидлам раньше не давали. Обычно его проводили тем, кто претендует на роль сеньора и выше

Обычно собеседование по System Design длится 45-60 минут. Все зависит от того, сколько времени ты потратишь до и после собеседования на различные вопросы и приветствие. По итогам выходит матрица оценки, где получается взвешенная оценка по каждому из этапов.

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

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

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

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

• Сбор и формализация требований (5-10 минут)
• Приблизительная оценка нагрузки (5 минут)
• Проектирование API для будущей системы (5 минут)
• Проектирование высокоуровневой архитектуры и модели данных (20-30 минут)
• Обсуждение отказоустойчивости и масштабируемости архитектуры (5 минут)
• Расчет необходимых ресурсов (железа) для будущей системы (5-10 минут — требуется не везде)

Вероятно, ты сталкивался на работе с непонятными ТЗ и требованиями, которые приходилось формализовывать. Здесь так же. Интервьюер не ждет, что ты сразу же начнешь проектировать систему, потому что нельзя сделать то, не знаю что. Это проверка в том числе soft skills и тебе нужно начать диалог, чтобы выяснить, что именно предстоит проектировать

Представь, что тебя попросили разработать «сервис обмена фотографиями» с некоторыми минимально определенными возможностями. Можно сразу начать проектировать что-то вроде Instagram, исходя из предположения, что все изображения будут относительно небольшими, не будут рассматриваться подробно, и что приемлемо значительное сжатие для экономии памяти и пропускной способности. Но интервьюер не сказал ни слова о проектировании Instagram, а кроме него существует множество различных типов сервисов обмена фотографиями. Например, Flickr или 500px — сервисы для фотографов, чтобы демонстрировать работы в высоком разрешении.

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

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

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

1) Количество пользователей

2) Поведение пользователей

3) Регионы использования приложения

4) Сезонности в приложении

5) Условия хранения данных

6) Лимиты и ограничения

7) Временные ограничения

8) Доступность приложения

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

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

Твоя задача — понять порядок и характер нагрузки, а потом рассказать об этом интервьюеру. В контексте нагрузки, чаще всего требуется: