Как успешно пройти System Design Interview? [Часть 1]
В странах типа моей System Design Interview - это, скорее, не стандартная практика. Обычно спрашивают Java, если нанимают Java-разработчика, и тому подобное. Но если ты решишь пособеседоваться в Т-Банк (он же Тинькофф) или Яндекс, то дизайн систем - нормальная практика.
Также европейские страны и США часто проводят этот этап собеседования, причём чем выше уровень, тем более глубокую экспертизу будут ожидать.
Если не знать, как этот этап устроен, то завалить его проще простого, ведь вопрос, который будет задан, будет звучать максимально абстрактно.
Например ☝️:
• "design Uber"
• "design YouTube"
• "design ChatGPT".
Самое важное, что нужно понимать - это то, что тебе необходимо лидить интервью. Ты являешься тем человеком в комнате, кто задаёт вопросы и решает неопределённость.
Окей, с этим разобрались, но что именно нужно делать, чтобы построить условный Uber?
Во-первых, от тебя не ждут ни строки кода. Всё, что нужно, - это собрать требования, построить систему, нарисовав диаграмму, и решить всю неопределённость.
Во-вторых, от тебя не ждут готового дизайна всего Uber, YouTube и т.д. От тебя ждут, чтобы ты узнал(а) требования и сузил скоуп до того, чего ждёт интервьюер. Очень похоже на жизнь, когда тебе дают проект и тебе нужно разобраться, что именно от тебя хотят, так как требования очень расплывчаты.
Теперь давай разберёмся со step-by-step планом:
1️⃣ Собираем функциональные требования
Этот пункт отвечает на вопрос: что именно мы должны построить?
Например, тебе говорят: «Design Uber». Твоя задача здесь не сразу рисовать блоки 20ти сервисов, а начать задавать вопросы. Какую часть Uber мы проектируем и т.д.?
Например, что мы должны задизайнить:
• поиск машины рядом;
• matching водителя и клиента;
• отображение машины на карте в real time;
• создание поездки;
• платежи;
• история поездок?
За 45-60 минут построить весь Uber невозможно. Поэтому нужно вместе с интервьюером выбрать несколько основных use cases и дальше работать именно с ними.
2️⃣ Собираем нефункциональные требования
Теперь нужно понять не что делает система, а как хорошо она должна это делать.
Например:
• сколько у нас пользователей?
• сколько запросов в секунду / в день / в месяц / в год?
• важнее consistency или availability?
• какая допустимая latency?
• глобально ли расположены наши пользовальтели?
И здесь уже начинают появляться ограничения, которые потом будут напрямую влиять на твой дизайн.
Помни, что одно дело - спроектировать сервис для тысячи пользователей, другое - для сотен миллионов.
Также, люди готовящиеся к интрвью часто пытаются запомнить на что именно нужно обратить внимание и придумывают фразочки, чтобы легче это сделать.
Например:
• Cats Eat Sweet Lemons, Drinking Sugar-Free Coffee 👇
🔠 - CAP Theorem
🔠 - Environment
🔠 - Scalability
🔠 - Latency
🔠 - Durability
🔠 - Security
🔠 - Fault Tolerance
🔠 - Compliance
Можно придумать что-то своё, чтобы можно было пробежаться в уме на интервью и выбрать то, что нужно на твоем собеседовании.
3️⃣ Делаем back-of-envelope estimations
Или, говоря проще, грубые подсчёты.
Если мы будем знать, сколько пользователей в секунду пользуются сервисом, будет легче аргументировать предложенные идеи. Например, если у тебя получилось 500 RPS, возможно, тебе вообще не нужен тот распределённый монстр, который ты уже начал(а) рисовать.
А если получилось 500 000 RPS, то разговор совсем другой.
Или, если мы знаем, сколько данных нам нужно хранить, будет легче понять, нужна ли репликация и т. д.
Другой пример: если мы знаем пропускную способность одного сервиса и сколько нужно обработать данных в секунду, мы будем знать, сколько нод / серверов нам будет нужно в единицу времени.
Главное, помни, что не нужно высчитывать всё с точностью до последнего байта. Цель - подсчитать грубо, как будто ты подсчитываешь на обратной стороне конверта, как на черновике. Точные цифры не помогут, но потратят твоё ограниченное время.
В странах типа моей System Design Interview - это, скорее, не стандартная практика. Обычно спрашивают Java, если нанимают Java-разработчика, и тому подобное. Но если ты решишь пособеседоваться в Т-Банк (он же Тинькофф) или Яндекс, то дизайн систем - нормальная практика.
Также европейские страны и США часто проводят этот этап собеседования, причём чем выше уровень, тем более глубокую экспертизу будут ожидать.
Если не знать, как этот этап устроен, то завалить его проще простого, ведь вопрос, который будет задан, будет звучать максимально абстрактно.
Например ☝️:
• "design Uber"
• "design YouTube"
• "design ChatGPT".
Самое важное, что нужно понимать - это то, что тебе необходимо лидить интервью. Ты являешься тем человеком в комнате, кто задаёт вопросы и решает неопределённость.
Окей, с этим разобрались, но что именно нужно делать, чтобы построить условный Uber?
Во-первых, от тебя не ждут ни строки кода. Всё, что нужно, - это собрать требования, построить систему, нарисовав диаграмму, и решить всю неопределённость.
Во-вторых, от тебя не ждут готового дизайна всего Uber, YouTube и т.д. От тебя ждут, чтобы ты узнал(а) требования и сузил скоуп до того, чего ждёт интервьюер. Очень похоже на жизнь, когда тебе дают проект и тебе нужно разобраться, что именно от тебя хотят, так как требования очень расплывчаты.
Теперь давай разберёмся со step-by-step планом:
1️⃣ Собираем функциональные требования
Этот пункт отвечает на вопрос: что именно мы должны построить?
Например, тебе говорят: «Design Uber». Твоя задача здесь не сразу рисовать блоки 20ти сервисов, а начать задавать вопросы. Какую часть Uber мы проектируем и т.д.?
Например, что мы должны задизайнить:
• поиск машины рядом;
• matching водителя и клиента;
• отображение машины на карте в real time;
• создание поездки;
• платежи;
• история поездок?
За 45-60 минут построить весь Uber невозможно. Поэтому нужно вместе с интервьюером выбрать несколько основных use cases и дальше работать именно с ними.
2️⃣ Собираем нефункциональные требования
Теперь нужно понять не что делает система, а как хорошо она должна это делать.
Например:
• сколько у нас пользователей?
• сколько запросов в секунду / в день / в месяц / в год?
• важнее consistency или availability?
• какая допустимая latency?
• глобально ли расположены наши пользовальтели?
И здесь уже начинают появляться ограничения, которые потом будут напрямую влиять на твой дизайн.
Помни, что одно дело - спроектировать сервис для тысячи пользователей, другое - для сотен миллионов.
Также, люди готовящиеся к интрвью часто пытаются запомнить на что именно нужно обратить внимание и придумывают фразочки, чтобы легче это сделать.
Например:
• Cats Eat Sweet Lemons, Drinking Sugar-Free Coffee 👇
🔠 - CAP Theorem
🔠 - Environment
🔠 - Scalability
🔠 - Latency
🔠 - Durability
🔠 - Security
🔠 - Fault Tolerance
🔠 - Compliance
Можно придумать что-то своё, чтобы можно было пробежаться в уме на интервью и выбрать то, что нужно на твоем собеседовании.
3️⃣ Делаем back-of-envelope estimations
Или, говоря проще, грубые подсчёты.
Если мы будем знать, сколько пользователей в секунду пользуются сервисом, будет легче аргументировать предложенные идеи. Например, если у тебя получилось 500 RPS, возможно, тебе вообще не нужен тот распределённый монстр, который ты уже начал(а) рисовать.
А если получилось 500 000 RPS, то разговор совсем другой.
Или, если мы знаем, сколько данных нам нужно хранить, будет легче понять, нужна ли репликация и т. д.
Другой пример: если мы знаем пропускную способность одного сервиса и сколько нужно обработать данных в секунду, мы будем знать, сколько нод / серверов нам будет нужно в единицу времени.
Главное, помни, что не нужно высчитывать всё с точностью до последнего байта. Цель - подсчитать грубо, как будто ты подсчитываешь на обратной стороне конверта, как на черновике. Точные цифры не помогут, но потратят твоё ограниченное время.