System Design. Общие принцип прохождения интервью по проектированию ИТ-систем / Хабр
Привет, Хаброжители! Мы весьма рады, что вы решили изучить особенности интервью по проектированию ИТ-систем вместе с нами. Из всех технических интервью именно на этом задают самые сложные вопросы. Претенденту предлагается спроектировать архитектуру программной системы: новостной ленты, поиска Google, системы мгновенных сообщений и т. д. Задачи такого рода наводят ужас, ведь у них нет единственно верных решений. Они обычно отличаются масштабностью и расплывчатостью. Допускаются свободные и неясные формулировки без стандартного или правильного ответа.
Интервью по проектированию ИТ-систем широко практикуются в компаниях, так как навыки общения и решения задач, которые можно проверить на этом этапе, необходимы в повседневной работе программиста. Ответы претендента оцениваются с учетом того, как он анализирует расплывчатую задачу и какие шаги он предпринимает для ее решения.
При этом во внимание принимается то, как он объясняет свои идеи, обсуждает их с другими, оценивает и оптимизирует систему.
Общие принцип прохождения интервью по проектированию ИТ-систем
Вас только что пригласили на такое желанное интервью в компании вашей мечты. Координатор по найму прислал вам расписание на намеченный день. На первый взгляд все довольно неплохо, но тут вам на глаза попадается пункт об интервью по проектированию ИТ-систем.
Многие боятся такого рода интервью. Вопросы на них могут быть расплывчатыми и слишком уж общими, например: «Спроектируйте общеизвестный продукт X». Отсутствие энтузиазма у претендента вполне объяснимо. В конце концов, кому под силу в течение часа спроектировать популярный продукт, над которым работали сотни, если не тысячи инженеров?
Хорошая новость в том, что от вас этого никто не ожидает. Реальные системы имеют чрезвычайно сложную архитектуру. Например, поиск Google только с виду выглядит просто; количество технологий, стоящих за этой простотой, поистине потрясающее.
Интервью по проектированию ИТ-систем имитирует реальный процесс, в ходе которого пара коллег совместно работают над какой-то общей не совсем ясной задачей и находят подходящее решение. Задача носит общий характер, и идеального решения не существует. Важна не столько архитектура, которую вы предложите, сколько сам процесс проектирования. Это позволяет вам продемонстрировать свои навыки инженера, обосновать выбор тех или иных архитектурных решений и конструктивно ответить на возникшие вопросы.
Давайте представим себя на месте интервьюера — человека, который задает вопросы, и попробуем понять, о чем он думает, когда заходит в конференц-зал и встречает вас. Его основная задача — правильно оценить ваши способности. Худшим исходом для него будет плохо проведенное интервью или недостаток сведений, которые не позволят дать вам окончательную оценку. Что пытается узнать интервьюер во время собеседования по проектированию ИТ-систем?
Многие считают, что этот вид интервью сводится к техническим навыкам проектирования претендента.
Но это лишь малая его часть. Эффективное интервью четко сигнализирует о способности претендента работать совместно, выдерживать давление и конструктивно справляться с расплывчатыми задачами. Еще одним ключевым навыком, на который особенно обращают внимание многие интервьюеры, является способность задавать подходящие вопросы.
Хороший интервьюер также ищет отрицательные признаки. Чрезмерно усложненные архитектурные решения являются настоящей болезнью многих инженеров, которые восхищаются чистотой результата и не желают идти на компромиссы. Они зачастую не догадываются о тех расходах, которые влекут за собой переусложненные системы, и многим компаниям это неведение дорого обходится. Эту склонность явно не стоит демонстрировать. Среди других нежелательных качеств можно выделить узкий кругозор, упрямство и т.д.
В этой главе мы разберем некоторые полезные советы и предложим простой и эффективный подход к решению задач на интервью по проектированию ИТ-систем.
Удачное интервью по проектированию ИТ-систем за 4 шага
Каждое интервью по проектированию ИТ-систем уникально.
Хорошая задача должна носить общий характер и не иметь какого-то одного универсального решения. Но у всех интервью есть общие этапы.
Шаг 1: понять задачу и определить масштаб решения
— Почему тигр зарычал?
В заднем ряду кто-то с готовностью поднял руку.
— Джимми? — кивнул учитель.
— Потому что он ПРОГОЛОДАЛСЯ.
— Отлично, Джимми.
В своем классе Джимми всегда первым отвечал на вопросы. Всякий раз, когда учитель что-то спрашивает, в классе всегда найдется ребенок, который с радостью рискнет поднять руку, даже если у него нет ответа. В нашем случае это Джимми.
Джимми — отличник. Он гордится своим умением быстро отвечать на все вопросы. На экзаменах он обычно раньше всех сдает свою работу. Он первый в списке тех, кого учитель посылает на олимпиады.
НЕ БУДЬТЕ такими, как Джимми.
На интервью по проектированию ИТ-систем быстрый ответ без обдумывания не даст вам дополнительных баллов. Решение задачи без глубокого понимания ее требований является очень плохим знаком, так как такое интервью — это не викторина.
Поэтому не спешите предлагать решение. Повремените. Хорошенько подумайте и задайте вопросы, чтобы уточнить требования и допущения. Это чрезвычайно важно.
Мы, инженеры, любим сложные задачи и спешим выдать на-гора готовые решения, но такой подход, скорее всего, не приведет к проектированию нужных систем. Один из самых важных навыков любого инженера состоит в умении задавать правильные вопросы, делать подходящие предположения и собирать всю информацию, необходимую для создания системы. Поэтому не бойтесь спрашивать.
Услышав вопрос, интервьюер либо прямо ответит, либо попросит вас высказать собственные предположения. Во втором случае свои мысли лучше записать на доске или бумаге. Позже они вам пригодятся.
О чем следует спрашивать? Попытайтесь уточнить требования к архитектуре. Вот список вопросов, с которых можно начать:
— Какие именно возможности мы будем реализовывать?
— Сколько пользователей у нашего продукта?
— Как скоро ожидается наращивание мощностей? Какой масштаб планируется через 3 месяца, полгода, год?
— Как выглядит технологический стек компании? Какие существующие сервисы можно применить для упрощения архитектуры?
Пример
Если вас попросят спроектировать ленту новостей, вам следует прояснить требования, которые к ней предъявляются.
Кандидат: «Это мобильное или веб-приложение? Или и то и другое?»
Интервьюер: «И то и другое».
Кандидат: «Какие самые важные возможности должны быть у этого продукта?»
Интервьюер: «Возможность публиковать статьи и видеть новостные ленты своих друзей».
Кандидат: «Новостная лента сортируется хронологически или в каком-то особом порядке? Особый порядок означает, что каждой статье назначается определенный вес. Например, статьи ваших близких друзей важнее статей, опубликованных в группе».
Интервьюер: «Чтобы не усложнять, предположим, что лента сортируется в обратном хронологическом порядке».
Кандидат: «Сколько друзей может быть у пользователя?»
Интервьюер: «5000».
Кандидат: «Какой объем трафика?»
Интервьюер: «10 миллионов активных пользователей в день (DAU)».
Кандидат: «Может ли лента содержать изображения и видеофайлы наряду с текстом?»
Интервьюер: «В ленте могут быть медиафайлы, включая изображения и видео».
Выше приведены некоторые из вопросов, которые вы можете задать своему интервьюеру. Важно определиться с требованиями и прояснить неоднозначные моменты.
Шаг 2: предложить общее решение и получить согласие
На этом этапе мы пытаемся выработать общее решение и согласовать его с интервьюером. Очень желательно в ходе этого процесса наладить совместную работу.
— Предложите начальный план архитектуры. Поинтересуйтесь мнением интервьюера. Относитесь к нему как к члену своей команды, с которым вы вместе работаете. Хорошие интервьюеры зачастую любят поговорить и поучаствовать в решении задачи.
— Нарисуйте на доске или бумаге блок-схемы с ключевыми компонентами, такими как клиенты (мобильные/браузерные), API-интерфейсы, веб-серверы, хранилища данных, кэши, CDN, очереди сообщений и т.д.
— Выполните приблизительные расчеты, чтобы понять, соответствует ли ваше решение масштабу задачи. Рассуждайте вслух. Прежде чем что-то считать, пообщайтесь с интервьюером.
Это поможет вам сформировать общую архитектуру и, скорее всего, обнаружить крайние случаи, о которых вы еще не думали.Следует ли на этом этапе обозначать конечные точки API-интерфейса и схему базы данных? Это зависит от задачи. Если вас просят спроектировать что-то масштабное, такое как поиск Google, то лучше не углубляться настолько сильно. Если же речь идет о серверной части многопользовательской игры в покер, эти аспекты вполне можно указать. Общайтесь с интервьюером.
Пример
Давайте посмотрим, как происходит разработка общей архитектуры на примере новостной ленты. Вам не нужно понимать, как на самом деле работает эта система. Все детали будут описаны в главе 11.
На высоком уровне архитектура делится на два потока: публикацию статей и составление новостной ленты.
— Посты в ленте. Когда пользователь публикует пост, соответствующая информация записывается в кэш или базу данных, а сам пост появляется в ленте новостей его друзей.
— Составление ленты новостей.
Новостная лента формируется путем группировки постов ваших друзей в обратном хронологическом порядке.
На рис. 3.1 и 3.2 показан общий принцип публикации постов и, соответственно, составления новостной ленты.
Шаг 3: глубокое погружение в проектирование
На этом этапе вы и интервьюер достигли следующих целей:
— согласовали общие требования и будущий масштаб;
— начертили примерную схему архитектуры;
— узнали мнение интервьюера о вашем общем решении;
— получили какое-то базовое представление о том, на каких областях нужно сосредоточиться при подробном проектировании (исходя из того, что ответил интервьюер).
Работая совместно с интервьюером, вы должны определить компоненты архитектуры и назначить им тот или иной приоритет. Стоит подчеркнуть, что все интервью проходят по-разному. Иногда вам могут дать понять, что желательно сосредоточиться на общей архитектуре. Иногда, если кандидат претендует на серьезную должность, обсуждение может коснуться характеристик производительности системы с вероятным упором на узкие места и оценку необходимых ресурсов.
В большинстве случаев кандидата просят углубиться в детали каких-то компонентов системы. Если вы проектируете сервис для сокращения URL-адресов, особый интерес будет представлять функция хеширования, превращающая длинный адрес в короткий. В системе обмена сообщениями двумя интересными аспектами являются снижение латентности и поддержка онлайн/офлайн-статусов.
Ключевую роль играет рациональное использование времени. Очень легко зациклиться на несущественных деталях, которые не позволяют оценить ваши способности. Вы должны показать интервьюеру то, что он хочет о вас узнать. Старайтесь не углубляться в ненужные подробности. Например, лучше не скатываться в подробное обсуждение алгоритма EdgeRank, с помощью которого Facebook взвешивает публикации в своей ленте, так как это отнимает ценное время и не демонстрирует вашу способность проектировать масштабируемые системы.
Пример
Итак, мы обсудили общую архитектуру ленты новостей, и интервьюер одобрил ваше решение. Теперь мы исследуем два самых важных сценария использования.
1. Публикация постов.
2. Выдача новостной ленты.
На рис. 3.3 и 3.4 в деталях показан принцип работы этих двух функций. Подробнее об этом речь пойдет в главе 11.
Шаг 4: подведение итогов
На заключительном этапе вам могут задать несколько уточняющих вопросов или предложить обсуждение других аспектов на ваш выбор. Вот несколько советов, которыми можно руководствоваться.
— Интервьюер может попросить вас обозначить узкие места системы и обсудить потенциальные улучшения. Никогда не утверждайте, что ваше решение идеальное. Всегда можно что-то улучшить. Это отличная возможность продемонстрировать свое критическое мышление и оставить о себе хорошее впечатление.
— Возможно, стоит провести краткий обзор вашей архитектуры, особенно если вы предложили несколько решений. Это позволит интервьюеру освежить память, что может пригодиться после длинного собеседования.
— Будет интересно поговорить о внештатных ситуациях, таких как поломка серверов, разрыв сети и т.
д.
— Стоит затронуть эксплуатационные вопросы. Как вы отслеживаете метрики и журналы ошибок? Как выкатывается система?
— Проведение следующего этапа масштабирования — тоже весьма интересная тема. Например, если ваша текущая архитектура поддерживает 1 миллион пользователей, какие изменения нужно внести, чтобы увеличить эту цифру до 10 миллионов?
— Если еще остается время, предложите дальнейшие улучшения.
В заключение составим краткий список того, что следует и не следует делать.
Рекомендуется
— Всегда уточняйте. Не надейтесь на то, что ваши предположения окажутся верными.
— Определитесь с требованиями.
— Не существует правильного или лучшего ответа. У молодого стартапа и известной компании с миллионами пользователей разные архитектуры, которые решают разные задачи. Убедитесь в том, что вы понимаете требования.
— Делитесь мыслями с интервьюером. Общайтесь с ним.
— По возможности предложите разные подходы.
— Согласовав с интервьюером общую архитектуру, подробно обсудите каждый компонент.
Начинайте проектирование с самых важных компонентов.
— Предлагайте разные идеи. Хороший интервьюер работает с кандидатом, как с членом своей команды.
— Никогда не сдавайтесь.
Не рекомендуется
— Не приходите на интервью, не подготовившись к типичным вопросам.
— Не начинайте работать над решением, пока не уточните требования и собственные предположения.
— Не уделяйте сразу слишком много времени какому-то одному компоненту. Предложите общую архитектуру, а затем уже погружайтесь в детали.
— Если испытываете затруднения, не стесняйтесь обратиться за подсказкой.
— Опять же, не замыкайтесь в себе. Не рассуждайте молча.
— Не думайте, что интервью заканчивается, как только вы изложили свое решение. Интервьюер сам определяет, продолжать или нет. Постоянно интересуйтесь его мнением.
Время, выделяемое на каждый этап
Вопросы, задаваемые на интервью по проектированию ИТ-систем, обычно носят крайне общий характер, и для обсуждения всей архитектуры целиком недостаточно 45 минут или часа.
Очень важно рационально использовать свое время. Сколько минут следует выделить на каждый этап? Ниже приводятся очень приблизительные рекомендации о том, как разбить 45-минутное интервью. Пожалуйста, имейте в виду, что это лишь примерные расчеты: распределение времени зависит от масштабов задачи и требований, которые озвучил интервьюер.
Шаг 1. Понять задачу и определить масштаб: 3–10 минут.
Шаг 2. Предложить общее решение и получить одобрение: 10–15 минут.
Шаг 3. Подробное проектирование: 10–25 минут.
Шаг 4. Подведение итогов: 3–5 минут.
Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Design
Приручая System Design Interview. Как его организовать и как к нему подготовиться / Хабр
Недавно я искал работу Golang разработчиком в нескольких крупных российских ИТ компаниях.
Как я готовился к собеседованиям и как они проходили — об этом можно почитать в статье моего блога. Одним решением алгоритмических задачек тут не обошлось. Для меня стало сюрпризом, что в некоторых компаниях нашего аналога MANGA появилась аналогичная практика проведения секции проектирования систем, известная за рубежом как system design interview.
Мотивация проведения
Все понимают, что большие системы не проектируются за час, но зачем тогда эти интервью проводят? За Google не скажу, но мне понравилось объяснение Александра Поломодова из Тинькофф. Он мотивировал потребность в этой секции тем, что при росте их компании в командах должны появляться люди с экспертизой дизайна новых систем, чтобы команды оставались самостоятельными. Эта мысль нашла во мне большой отклик. На прошлой работе была ровно такая проблема: компания увеличивала количество команд, нанимая джунов и мидлов, чтобы делать всё больше и больше, но когда какой-то команде прилетала задача дизайна новой подсистемы, то часто приходилось звать на помощь единственного «разработчика-архитектора», которому и без того задач хватало.
Минусы такого подхода, думаю, всем очевидны.
Мой опыт
До прохождения этой секции у меня был опыт проектирования одной более-менее нескромной системы, дизайн документ которой писался месяц и занял пару десятков страниц. В свободное от работы время я изучал чужие архитектуры по статьям и докладам. Мне немного помогло то, что рекрутеры кратко описали план интервью и рекомендовали ознакомиться с моделью C4 для описания систем: предстояло не только общаться с интервьюером, но и рисовать схемы в online редакторе. В этот раз обошлось без лагающих интерфейсов: было достаточно пошарить свой экран в Miro или Diagrams.net. Я заранее подготовил доску, разместив шаблоны архитектурных элементов, подготовил текстовые блоки для сбора требований и расчета нагрузки.
В назначенный час мы созвонились с интервьюером, он описал задачу, и я начал заполнять доску, параллельно рассказывая о принимаемых решениях и задавая встречные вопросы. Мне попались классические кейсы, поэтому удалось выполнить план и ответить на вопросы по эксплуатации.
Время прошло очень быстро. Я отметил для себя, что NoSQL хранилища данных — это определённо вектор для моего развития 🙂
Разбор полетов
Вернувшись с собеседований, я начал анализировать полученный опыт и пытался сравнить его с чужим. Среди моих знакомых не было людей, которые проходили подобное, поэтому за основу я взял видеозаписи публичных прохождений этой секции.
То, что я увидел, показалось мне достаточно естественным. В роликах я видел все те проблемы, которые ожидал от этого формата интервью, или с которыми столкнулся сам. Далее мы пройдёмся прямо по этим моментам, а в качестве примеров дам ссылки на записи, которые лучше всего иллюстрируют неприятные ситуации.
Выражу своё уважение к участникам подобных видео-экспериментов: я на себе оценил насколько нервозная обстановка на таком интервью, что может подать людей не с лучшей стороны, а делиться записью произошедшего на большую аудиторию вообще сродни подвигу.
Битва телепатов
Самый часто встречающийся случай: интервьюер не заметил, как кандидата унесло не туда, куда надо было интервьюеру.
Вот пример крайне запущенной ситуации.
Тут предлагалось спроектировать систему мониторинга. Но вместо дизайна убийцы prometheus и grafana, получилась сессия «как всё собрать из готовых кубиков». Учитывая то, что Владимир даже активно обсуждал идеи кандидата, могло сложиться впечатление, что мы на собеседовании на позицию solution architect. Но по финалу стало понятно, что на самом деле ожидалось совсем другое. Жаль, что сам интервьюер не рассказал как бы он решал эту задачу.
Моё мнение об этой задачеЧто касается дизайна этой системы «по-честному»: есть серия статей от автора prometheus про его устройство вплоть до систем хранения данных и выполнения запросов. Если коротко: в этом движке куча нетривиальных идей. Вероятность услышать их от случайного разработчика близка к нулю.
В стрессовой ситуации человек склонен говорить больше о том, в чем хорошо разбирается, и оттягивать переход к сложным темам. Если интервьюер вовремя не перенаправит внимание кандидата, то это закончится разочарованием для обоих.
Вот в этом примере Александр своевременно указал на ошибку и собеседуемый смог её исправить.
Заезженные кейсы
«Задизайните нам VK/Google Drive/Bitly»: говорит интервьюер, надеясь удивить кандидата масштабом задачи. Но проблема в том, что большинство таких архитектур уже подробно разобраны, в том числе на Youtube. Давая такие задания, вы вряд ли проверяете что-то, кроме способности выучить наизусть готовые кейсы.
Тупняк с цифрами
На этапе оценок RPS и объема хранилищ нужно уметь быстро умножать и делить большие числа, переводить единицы измерения. Вот показательный пример того, что бывает, когда кандидату достался задача об очень «прожорливом сервисе» и он оказался к этому не готов. В результате полное решение так и не было представлено.
Задачи «со звёздочкой»
Даже в этом типе интервью можно придумать задачи повышенной сложности. Например, когда добавляется нестандартная алгоритмическая подзадача: дизайн сервиса заказа такси и подзадача быстрого поиска водителей для клиента.
Или как в примере выше: движок для работы с time series данными. Давая такой «гроб», велик риск ввести человека в ступор на раннем этапе. И как потом его оценивать?
Приручаем разбушевавшегося пёсика
Провести осмысленный System Design Interview — это высший пилотаж для интервьюера и большой стресс для кандидата.
Первый должен, не раскрывая всех карт, удержать кандидата в нужном русле, чтобы комплексно оценить навыки. Для второго одновременно думать, рисовать и говорить — тоже тот ещё челлендж. Добавим сюда ещё ограничение по времени, нечеткие требования и постоянные попытки угадать чужие мысли, и получим настоящую олимпиадную задачу для архитекторов.
Такое интервью — это обоюдоострый инструмент. Если в алгоритмической секции интервьюер в принципе может расслабиться, т.к. критерий решения задачи объективный (работает ли решение корректно и с нужной скоростью), то тут причиной провала может быть и он сам. В этом случае негативный фидбэк от известного кандидата высокой квалификации может принести существенный урон репутации компании.
Можно ли с этим что-то сделать? Если навыки дизайна систем для вас всё-таки важны, но у интервьюера нет большого опыта собеседований и вы вообще ни разу не Google, то можно понизить градус гиковости интервью следующими способами.
Ведущий или ведомый
Найдите баланс между слушанием и ведением интервью. Стоит отталкиваться от ваших ожиданий от кандидата, его уровня, реальных условий дизайна систем в вашей компании.
Дом, милый дом
Вместо дизайна больших систем, которые вы изнутри никогда не видели, предложите реализовать то, с чем вы реально работали или над чем работаете сейчас. Интервьюер будет лучше себе представлять то, что предлагается построить, и это снизит вероятность того, что предложенный кейс будет известен кандидату. Кандидат же получит лучшее понимание о масштабе будущих задач.
Детали важнее
Вместо дизайна абстрактных систем можно предложить реализовать какой-то узкий, но максимально конкретный кейс, который можно полностью покрыть за час: интеграция систем, надежная коммуникация, вопросы консистентности, выполнение периодических операций.
Умение решать часто встречающиеся задачи подчас показательнее рисования однотипных схем и абстрактных размышлений.
«У нас лапки»
Вместо проверки того, как можно дорого и богато растянуть банальный кейс до хайлоада, можно попросить оптимизировать стоимость владения, адаптировать решение под текущий ИТ ландшафт компании и навыки имеющихся людей, пусть и жертвуя какими-то характеристиками.
Все всё понимают
Стоит ли требовать всех расчётов по нагрузке, давая только бизнес-метрики, или можно дать кандидату сразу финальные цифры? Есть ли вообще смысл их обсуждать, если вы готовы транслировать кандидату, что ожидаете достаточно стандартное для хайлоада решение: всё должно скейлится в очевидных пределах? Логически развивая тему цифр, вы точно хотите потребовать еще и оценку необходимого количества серверов, баз данных и очередей от человека, который прямо на ваших глазах начинает постепенно дорожать после каждого следующего вашего вопроса?
Дорогу осилит идущий
Если вам понравилась идея, но есть вопросики к деталям реализации, то никто не мешает поступить с секцией проектирования систем так, как поступают у нас со scrum-ом: взять оригинальную идею – проверка навыков дизайна распределенных системам, – и адаптировать её под свои потребности.
С развитием технологий даже в небольших компаниях появляется запрос на людей с пониманием как работают системы целиком. Но даже если кандидат всё-таки не справился с подобным интервью, проектирование может стать направлением для его роста в вашей компании, что тоже win-win. В общем, расставляя собственные акценты, можно получить от этого инструмента пользы больше, чем от следования чужим канонам.
Несомненно, остаётся вопрос к софт-скилам интервьюера. В первую очередь он должен справиться со своим эго: оставаться максимально объективным и уметь слушать собеседника. Давая настолько объёмную задачу, спрашивающий должен определиться: о чем он хочет услышать в деталях, а что можно оставить за скобками. Без хороших навыков общения он не сможет передать свои акценты или корректно указать на проблемы. Участвуя в таких мероприятиях, ваш сотрудник будет заодно развивать своё умение доносить мысли, что полезно и в повседневной работе.
О подготовке к собеседованию
В первую очередь, пройти это интервью поможет конечно реальный опыт построения систем.
Если под сеньористостью кандидата подразумевать его способность брать на себя ответственность за масштабные проекты и справляться с ними, то эта секция — хороший способ её оценить. Если такого опыта нет — начинайте учить матчасть и «тренируйтесь на кошечках».
Для начала можно посмотреть на Youtube канале физтеховского ФПМИ курс «Highload» от автора одноименной конференции. Выделяются лекции тем, что лектор мотивирует студентов находить самые простые рабочие решения и подробно разбирает типичные задачи типа инвалидации кэшей и шардирования реляционных баз.
У меня лично есть пунктик на тему корректности работы распределенных систем. Поэтому я люблю читать статьи об устройстве инструментов, на которые все полагаются: различные базы данных и очереди. Идеи оттуда иногда приходится заимствовать для создания собственных протоколов. Последним таким увлекательным чтивом для меня стала статья об устройстве транзакций в Kafka.
За более фундаментальными знаниями по дизайну систем и просто советами по прохождению интервью можно обратиться к другому докладу того же Александра Поломодова.
Чтобы лучше понимать атмосферу мероприятия, можно посмотреть записи публичных собеседований, которые я упоминал ранее. Если у вас есть знакомый с опытом проведения таких интервью — обратитесь к нему. Существуют сервисы, готовые найти вам практикующих интервьюеров, чтобы провести тестовую сессию.
Быстро закрепить знания, и просто собрать мозг в кучку непосредственно перед интервью, поможет книга «System Design Interview: An Insider’s Guide». Еще в ней много ссылок на статьи из технических блогов крупных компаний. Изучение реальных кейсов помогает пополнять набор рабочих приемов и просто будет для вас постоянным источником вдохновения.
Разогрев
Как уже стало понятно, на собеседовании у вас будут рутинные операции, которые вы должны делать быстро, чтобы осталось время для важного. Потренируйтесь:
Быстро рисовать схемы и делать подписи в выбранном редакторе. Бороться с ним на самом интервью вы вряд ли захотите.
Делать расчеты нагрузки и объемы хранилищ, конвертировать одни единицы в другие.
Волнуясь, легко начать опечатываться в калькуляторе и забыть сколько байт в петабайте.
Подводя итоги
Верю, что system design interview — это ещё один инструмент для развития ИТ индустрии: чем шире в массах разойдутся знания о распределённых системах, тем лучше будут сервисы для наших пользователей. Да, изучение потребует усилий. Но самосовершенствование и создание чего-то большого — это то, за что многие и любят программирование.
Остаётся только надеяться, что несмотря на новую прогрессивную игрушку, компании смогут разумно ею воспользоваться: помогут с обучением и сохранят для кандидатов баланс между требованиями к ним и получаемой компенсацией 🙂
Проектирование системы 101. Пошаговое руководство по проектированию… | Ашис Чакраборти
Пошаговое руководство по проектированию системы
Фото Джонатана Сингера на Unsplash В настоящее время собеседования по проектированию систем являются частью процесса работы технологических компаний высшего уровня.
Многие люди боятся собеседований по системному дизайну, потому что нет определенного шаблона для подготовки. Кроме того, вопросы проектирования системы открыты, и нет стандартного правильного или неправильного ответа, что еще больше усложняет процесс подготовки.
Проектирование системы является одним из наиболее важных и наиболее важных аспектов разработки программного обеспечения. Одна из основных причин заключалась в том, что у каждого свой подход; нет четких пошаговых инструкций.
Борьбу инженеров-программистов с проектированием систем можно разделить на две части:
- Процесс проектирования систем по своей природе неструктурирован; нет правильного ответа, чтобы сказать, что двоичный код правильный или неправильный.
- Разработчики программного обеспечения не имеют опыта разработки сложных и крупномасштабных систем.
В этой статье мы рассмотрим шаги, необходимые для решения проблемы проектирования. Это руководство может помочь вам спроектировать систему. Этот основан на моем опыте изучения архитектурных курсов.
★Шаг 1: Уточнение требований
Нам необходимо уточнить цель системы. Дизайн системы — очень обширная тема; если мы не сузим его до конкретной цели, будет сложно спроектировать систему, особенно для новичков. Иногда ограничения полезны для системы. Это помогает сосредоточиться на основной функции, которую вы пытаетесь разработать. Это проясняет неясности в отношении особенностей системы. Мы можем разделить эти требования на две части:
- Функциональное требование:
Это требование, которое должна выполнять система. Можно сказать, что это главная цель системы. Здесь функция описывается как спецификация поведения между выходами и входами. Что будет системным входом, а что выходом, следует уточнить в этих требованиях.
- Нефункциональное требование:
Теперь о более важных требованиях, которые необходимо проанализировать. Если мы не выполним это требование, это нанесет ущерб бизнес-плану проекта. Эти требования ограничивают проектирование системы из-за различных системных качеств.
Производительность, модифицируемость, доступность, масштабируемость, надежность и т. д. являются важными требованиями к качеству при проектировании системы. Эти «силы» — это то, что нам нужно проанализировать для системы и определить, правильно ли спроектирована наша система.
★Шаг 2: Оценка важных частей
Одним из важных моментов проектирования системы является знание масштаба системы. Что на самом деле означает масштаб при проектировании системы? Количество просмотров статей, количество генерируемых таймлайнов в секунду и т. д. могут измерять масштаб системы. Если измерения системы очень велики, то это высокомасштабные системы.
Еще одна важная оценка касается хранения. Нам нужно знать, сколько памяти потребуется системе, скажем, на 5 лет. Он может только увеличиваться, но нужно иметь оценку.
Он даст направление хранения данных.
В случае System Design of URL Shortening Service вы можете увидеть такой расчет:
Предположим, система хранит все запросы на сокращение URL и их укороченную ссылку в течение 5 лет. Поскольку мы ожидаем, что ежемесячно будет появляться 500 миллионов новых URL-адресов, общее количество объектов, которые мы ожидаем хранить, составит 500 миллионов * (5 * 12) месяцев = 30 Б. Теперь предположим, что каждый сохраняемый объект будет иметь размер примерно 100 байт. Нам потребуется общее хранилище 30 миллиардов * 100 байт = 3 ТБ.
Итак, у вас есть представление о том, сколько памяти необходимо. И вы начинаете в направлении потока данных.
Использование пропускной способности сети также является важным фактором. В случае распределенных систем решающее значение имеет управление использованием пропускной способности. Например, если вы хотите эффективно обрабатывать передачу файлов, вам может потребоваться разделить файл на части.
Если мы будем передавать весь файл каждый раз, когда он обновляется, нам может потребоваться каждый раз передавать файл размером 100 МБ, если размер файла составляет 100 МБ. Скажем, например, мы будем делить файлы на куски по 2 МБ и передавать только измененную часть файлов, как видно из рисунка. Это уменьшит потребление полосы пропускания и облачное хранилище для пользователя.
★Шаг 3: Поток данных
Нам необходимо определить модель данных системы и то, как данные будут передаваться между различными компонентами системы. Нам нужно выяснить сущности системы и различные аспекты управления данными.
Новичкам в проектировании систем следует помнить: «Если вы не знаете, с чего начать проектирование системы, попробуйте начать с потока данных».
Вот несколько сущностей для такой службы, как Medium:
Пользователь: UserId, имя, электронная почта и т.
Д.
Статья: articleID, ContentAparticle, TimeStamp, NumberOfclaps и т. Д.
userFollow: userId1, userId2
подписчики: userId3, userId4
. выбор системы является частью этого раздела. Выбор базы данных NoSQL или SQL является распространенным сценарием. С другой стороны, нам может потребоваться решить, какой тип хранилища необходимо выбрать для фотографий и видео.
★Этап 4. Высокоуровневое проектирование компонентов
Если мы попытаемся спроектировать систему за один раз, это будет сложной задачей. Так что лучше разбивать их как высокоуровневые компоненты. Затем разбейте эти компоненты на детальный проект.
Попробуйте нарисовать блок-схему, представляющую основные компоненты нашей системы в 5–6 частях. Может быть и больше, если система слишком большая. Не существует определенного правила, на сколько компонентов мы можем разделить систему. Просто постарайтесь помнить, что нам нужно определить достаточное количество компонентов, чтобы помочь решить реальные проблемы системы.
Вот общая схема проектирования файлового хранилища и службы синхронизации, например Google Диска.
Рисунок: Высокоуровневый дизайн Google Диска (изображение автора)Сервер обработки файлов будет управлять рабочим процессом обработки файлов. Сервер метаданных позаботится об информации о файле, размере фрагмента и информации о пользователе. Сервер уведомлений сообщит клиентскому приложению об обновлении файлов на всех других устройствах, на которых клиент вошел в систему. Облачное хранилище сохранит файл.
Затем мы можем разобрать эти компоненты для дальнейшего детального проектирования в соответствии с требованиями системы.
★ Этап 5: Рабочий проект
На последнем этапе нам необходимо более глубоко изучить основные компоненты, которые важны для достижения требований к качеству системы.
На этом этапе мы можем проанализировать различные подходы к решению проблемы, их плюсы и минусы и объяснить, почему мы предпочитаем один подход другому.
Анализ компромиссов является важной частью этого раздела. Вот пример:
Так как нам нужно хранить огромные объемы данных, нам может понадобиться секционировать данные для распределения по нескольким базам данных. Может возникнуть вопрос о профиле знаменитости и о том, как мы будем обращаться с такими пользователями, у которых много подписчиков.
Сколько данных нам нужно кэшировать, чтобы ускорить время отклика системы. Где нам нужно использовать балансировщик нагрузки и т. д.?
Вот пример детального проектирования облачного хранилища файлов, такого как Google диск.
Рисунок: Системный дизайн диска Google (Изображение автора)★ Шаг 6: Определите узкие места и устраните их
Теперь у нас есть детальный проект системы. Мы должны найти узкие места системы и найти различные способы их смягчения. Например:
Изображение автора
- Если в нашей системе есть единая точка отказа , нам нужно их удалить. Это может вызвать проблемы с доступностью, что является серьезной проблемой.
- Нам нужно иметь достаточно копий данных, чтобы по-прежнему обслуживать наших пользователей, если мы потеряем несколько серверов. Если реплики данных нет и по какой-то причине данные потеряны, значит, в системе нет данных. Система будет иметь проблемы с надежностью.
- Точно так же нам нужно иметь достаточно копий различных запущенных служб, чтобы несколько сбоев не приводили к полному отключению системы.
Вывод:
Упомянутые выше шаги не являются единственным способом проектирования системы. Это упрощенное руководство для новичков, плохо знакомых с проектированием систем. Очень сложно разработать систему для новичков. Это руководство поможет вам не сбиться с пути и не потеряться в море потенциальных проблем и решений при проектировании системы.
Дизайн системы — это очень обширная тема; если не будет поставлена конкретная цель, спроектировать систему будет сложно, особенно для новичков.
Попробуйте указать требования системы.
Затем найдите модель данных и поток данных. И после высокоуровневого проектирования не стесняйтесь добавлять компоненты, если это необходимо. И самое главное, постарайтесь сосредоточиться на анализе компромиссов решений. Удачи !!
Спасибо за прочтение статьи. Хорошего дня 🙂
Эта статья является частью серии системного проектирования для начинающих. Ссылки на некоторые статьи приведены ниже:
Проектирование ограничителя скорости
Основы проектирования системы: Начало работы с кэшированием
Основы проектирования системы: Архитектура клиент-сервер
Проектирование системы Google Auto-Suggestion Service
Анализ системного проектирования Google Диска
Анализ проектирования системы TinyURL
Доступность в распределенных системах
4 этапа подготовки к собеседованию по проектированию системы в 2023 году? Я могу получить компенсацию, если вы приобретете товары или услуги по разным ссылкам, указанным в этой статье.
image_credit — Дизайн системы от Educative.io
Привет, ребята, если вы ищете новую работу разработчика программного обеспечения в 2023 году, тогда вам следует изучить концепции проектирования систем и решить как можно больше проблем проектирования систем, чтобы преуспеть, но проектирование систем довольно огромный и вам нужно немного больше, чем это, чтобы добиться успеха.
Рынок труда инженеров-программистов очень конкурентен! Особенно, если у вас за плечами несколько лет опыта. А в мире программной инженерии, если вы претендуете на должность старшего инженера/руководителя/архитектора/или на более высокую должность, системный дизайн является наиболее востребованным навыком и, следовательно, одним из самых важных этапов всего процесса.
Если ты все испортишь, все остальное не будет иметь значения. Однако, если вы все сделаете правильно, вы получите прибавку не менее десятков тысяч долларов в год.
Итак, как вам удается проектировать систему? Что ж, вот что я сделал, готовясь к своим интервью с Facebook, Google и Amazon, и это сработало довольно хорошо.
В конце концов я создал для себя контрольный список, который помог мне пройти через большинство моих раундов, поэтому, если вы пойдете по тому же пути, вы сможете придумать что-то, что сработает и для вас.
Прежде чем мы углубимся в детали, что такое собеседование по проектированию системы? Чего на самом деле ожидают интервьюеры от кандидатов?
Ожидания:
Вы должны быть в состоянии спроектировать систему, которая удовлетворяет заданным вам требованиям и хорошо масштабируется.
Ваш дизайн должен быть подключаемым и не ограничивать добавление новых функций.
Вы должны иметь возможность сравнить различные варианты и выбрать наиболее оптимальный. Например, какая база данных является наиболее важной, или какой протокол следует использовать, или какой подход лучше всего подходит для масштабирования системы и т. д.
Вы должны знать основы, важные с точки зрения проектирования системы, такие как:
Балансировщики нагрузки
API
Тайники
Базы данных
Сетевые протоколы
Очереди сообщений
CDN
Подробная информация об машинном обучении и больших данных
Теорема CAP
Мониторинг и аналитика
В прошлом я поделился лучшими курсами по проектированию систем и лучшими вопросами по проектированию программного обеспечения , а в этой статье я поделюсь пошаговым процессом взлома интервью по системному проектированию, таких как концепции, общие вопросы и ресурсы для освоения концепций системного проектирования, такие как этот список основных алгоритмов системного проектирования, из ByteByteGo, отличной платформы для изучения системного проектирования Алекса Сюй, автора книги «Интервью по системному проектированию» — руководства для посвященных, одной из лучших книг по системному проектированию.
Вот как пройти собеседование по системному дизайну любой компании FAANG (Facebook/META, Amazon, Apple, NetFlix и Google) или попасть в FAANG
Существует простой четырехэтапный процесс, чтобы пройти любое Раунд системного проектирования.
Концепции
Учитесь у технологических гигантов
Часто задаваемые вопросы
Практика
1. Изучите основные концепции проектирования систем
Любое собеседование по проектированию системы обязательно потребует от вас разработки базового высокоуровневого проекта любой системы, которую вы пытаетесь построить. Есть компоненты, которые точно понадобятся. Запишите эти компоненты.
Вот несколько —
1. 1 балансировщик нагрузки
У вас не может быть распределенной системы без балансировщика нагрузки для распределения входящих запросов между различными узлами. Это гарантирует правильное использование ресурсов и отсутствие единой точки отказа в вашей системе.
Вот как это делает Nginx.
1.2 Кэш
В большинстве систем есть некоторые взаимодействия с большим количеством операций чтения, некоторая информация, к которой пользователь будет обращаться часто, но не обновлять так часто. Имеет смысл кэшировать эту информацию таким образом, чтобы ее можно было легко получить без необходимости поиска в БД.
Подумайте о низкой задержке. Кроме того, в зависимости от вашего варианта использования вам может потребоваться хранить информацию, к которой чаще всего обращаются, или информацию, к которой обращались недавно. Итак, прочитайте о различных правилах выселения.
Вот хорошая диаграмма того, как кэширование используется в приложении от ByteByteGo
1.3 База данных
Опять же, не может быть системы без какой-либо формы хранения данных. Хотите ли вы хранить файлы, изображения, информацию о продукте, финансовые транзакции или просто сбрасывать все данные о различных взаимодействиях с пользователем, чтобы позже запустить аналитику.
Для всего этого нужны базы данных. Так что читайте об этом. Узнайте, что важно при выборе базы данных, прочитайте о SQL/NoSQL, шаблонах запросов и о том, как теорема CAP может сыграть роль при поиске компромиссов.
1.4 Очереди сообщений
Иногда нашей системе необходимо выполнить некоторые задачи, которые необходимо выполнить, но не обязательно немедленно, или их результат не влияет на путешествие пользователя.
В таких случаях вместо вызова службы и ожидания ответа имеет смысл просто записать сообщение в очередь, чтобы его можно было выполнить позже.
Что делать, если вам нужно вставить информацию в вашу базу данных, и массовая вставка может быть более эффективной? Было бы разумно просто отслеживать эти вставки в очереди сообщений и выполнять 1 массовую вставку вместо сотен вставок один к одному для оптимизации ваших ресурсов.
1.5 CDN
Когда ваши пользователи распределены географически, доставка им контента за разумное время становится настоящей проблемой.
CDN позволяют нам хранить копии наших данных в различных центрах обработки данных, расположенных ближе к местоположению пользователей, чтобы уменьшить задержку. Вот короткое видео о том, как Akamai это делает.
1.6 Аналитика и мониторинг
Это то, что необходимо в каждой создаваемой вами системе. Это скрытое требование, никто не называет его при сборе требований, но каждый интервьюер хочет этого.
Пользователь входит в систему или выходит из нее? Добавить товар в список желаний? Платеж не прошел? Это вся информация для нас! Если произойдет что-то важное, запустите событие и сохраните его в очереди сообщений.
Вы можете выполнять анализ данных в режиме реального времени или просто сбросить их в кластер Hadoop для последующего использования.
Точно так же, если вызов API регулярно завершается сбоем или ресурсы ваших серверов вот-вот закончатся, разве вы не хотели бы знать об этом заранее?
1.7 Сетевые протоколы
В зависимости от ваших требований и типа содержимого, которым вы делитесь, вам может потребоваться принять решение о том, какой сетевой протокол использовать.
Узнайте о различных сетевых протоколах и о том, когда они актуальны, какие компромиссы вам могут понадобиться и т. д.
Первый шаг — узнать обо всех этих концепциях. И под знанием концепций я подразумеваю не просто теоретические знания о том, что это такое, а более практический практический опыт о том, что и когда следует использовать.
Вам необходимо знать такие вещи, как:
Какую альтернативу лучше выбрать в зависимости от варианта использования.
Какие компромиссы необходимо учитывать при принятии этих решений?
Рекомендации для определенных вариантов использования.
Чтобы узнать большинство из этих вещей, я рекомендую пройти** этот курс System Design by CodeKarle**, который охватывает все вышеперечисленное с конкретными примерами из реального мира.
2. Учитесь у технологических гигантов (читайте их инженерный блог)
Это, вероятно, один из самых недооцененных советов, которые вы получите, и он не поможет в краткосрочной перспективе.
Но в долгосрочной перспективе, чтобы стать экспертом в области проектирования систем, лучше всего просматривать технические блоги различных технологических компаний и узнавать, как они решают различные технические проблемы.
Это нарисует четкую картину реальных проблем, с которыми они сталкиваются, и того, насколько инновационно они их решают. Понимание этих вещей поможет вам стать лучше в проектировании систем, а также будет держать вас в курсе последних инноваций в области технологий.
Вот некоторые из лучших блогов, на которые стоит подписаться:
Инженерный блог Facebook
Технический блог Netflix
Инженерный блог Uber
Вы также можете следить за блогами популярных технологических компаний на Medium, это одна из основных причин, по которой многие люди принимают членство в Medium.
Наряду с этим вы также можете подписаться на информационный бюллетень System Design, который ведет Алекс Сюй, доступный на ByteByteGo, чтобы постепенно изучать системный дизайн
3.
Решайте популярные проблемы проектирования систем
Очевидный способ начать подготовку к собеседованию! Знание основ, безусловно, важно, но этого недостаточно! Самый простой способ начать свою практику — просмотреть некоторые часто задаваемые вопросы и их решения.
Большинство собеседований по проектированию систем вращаются вокруг 5-6 часто задаваемых вопросов по проектированию систем, и если вы знаете ответы на эти вопросы, вы, скорее всего, пройдете это собеседование.
Наиболее распространенные вопросы по проектированию системы:
Tinyurl Проблема проектирования системы с решением
Проблема дизайна системы WhatsApp с решением
Проблема дизайна системы Instagram с решением
Проблема проектирования системы YouTube с решением
Дизайн системы Airbnb
Проблема дизайна системы Uber
Как создать Amazon Prime Video
Как создать поиск Google
Как спроектировать NetFlix
Как спроектировать распределенную очередь сообщений
Разработка системы управления библиотекой
Проектирование системы парковки
Если вам нужны ресурсы для решения этих вопросов, что-то, что не только решает вопрос, но также объясняет основные концепции и подход к решению вопросов проектирования системы, тогда этот высоко оцененный курс CodeKarle, где он обсуждает большинство этих тематических исследований и некоторые другие проблемы, которые помогли многим людям взломать свои интервью для таких компаний, как Google, Facebook, Microsoft, Amazon и т.
д. Вы также можете увидеть ссылки, где вы можете найти учебные пособия и видео на YouTube, которые решают эти проблемы.
Grokking Modern System Design for Software Engineers & Managers on Образовательный курс Educative — еще одно место, где вы можете найти решение большинства этих проблем.
4. Практика, практика и еще раз практика
Практика, практика, практика! Я сказал практика? Там много ресурсов.
Я поделился несколькими, в которых подробно обсуждаются некоторые из наиболее популярных проблем проектирования систем. Как только вы пройдете несколько из них, вы начнете замечать закономерность и вскоре сможете самостоятельно придумывать решения.
Получите лучшее представление о том, как устроены системы в вашей организации. Как дела у других команд? Какие факторы они учитывают?
Следующим лучшим вариантом будет попрактиковаться с другом. Убедитесь, что вы прошли несколько пробных собеседований перед настоящим собеседованием, чтобы избежать некоторых распространенных, но легко устранимых ловушек.
Некоторые наиболее распространенные ошибки, которые я видел у людей:
Не ведение интервью
Не задавать вопросов
Неправильная структура интервью
Время истекло
Без учета требований
Не изучить все альтернативные варианты дизайна
Всех этих ошибок можно легко избежать, проведя несколько имитационных интервью с кем-то, кто хорошо разбирается в системном дизайне. И время ваших интервью. Цель должна состоять в том, чтобы найти решение в течение 40 минут, включая время для некоторого обсуждения.
А вот хорошая шпаргалка по собеседованию по системному проектированию от Educative, которую вы можете распечатать и положить на свой стол для быстрого ознакомления с основными концепциями и алгоритмами системного проектирования.
Это все о как подготовиться к собеседованию по проектированию систем в 2023 году .
Я поделился важными темами, концепциями и концепциями интервью по системному дизайну, а также популярными вопросами по системному дизайну для практики, а также отличными ресурсами по системному дизайну для их изучения.
С помощью этого четырехэтапного процесса вы скоро будете готовы к успешному прохождению любого собеседования по проектированию системы! Надеюсь, это должно стать хорошей отправной точкой для вас.
Приятного обучения! и всего наилучшего для собеседования по проектированию системы
Другие ресурсы по проектированию системы Вам могут понравиться
Если вам нужны дополнительные ресурсы для подготовки к собеседованию по проектированию системы, вот мои рекомендации:
- ByteByteGo от Alex Xu
- Курс интервью CodeKarle по системному дизайну на Udemy
- Grokking Modern System Design for Software Engineers & Managers on Educational
Интервью- Mastering the System Design с Фрэнком Кейном (бывшим менеджером по найму Amazon)
- Специализация по проектированию и архитектуре программного обеспечения [Coursera]
- Архитектура веб-приложений и программного обеспечения 101 [Educative.
