Разработчик Сергей, который прошёл полный цикл собеседований в три компании FAANG, уже сделал подробный разбор алгоритмического и поведенческого интервью в Facebook, Amazon и Google.
В заключительной части он говорит о высокоуровневом испытании, требующем широкого кругозора, — System Design.
Разработчик Сергей, который прошёл полный цикл собеседований в три компании FAANG, уже сделал подробный разбор алгоритмического и поведенческого интервью в Facebook, Amazon и Google.
В заключительной части он говорит о высокоуровневом испытании, требующем широкого кругозора, — System Design.
Собеседование по проектированию проверяет ваши навыки построения высокоуровневых архитектур для современных нагруженных приложений, умение обосновывать выбранные решения, спускаться до технических деталей, видеть как работает приложение целиком.
В большинстве своём это задания на построение какого-либо веб-сервиса. Клиентами веб-сервиса бывают или браузеры, или мобильные приложения, или все сразу. У меня есть подозрение, что опыт работы в нагруженном бэкенде является мощным преимуществом для этого вида собеседования. А вот узкий опыт разработки только десктоп-приложений, мобильных приложений или фронта снижает вероятность пройти это интервью без дополнительной подготовки.
Вот примерные формулировки заданий на проектирование:
Как видите, вопросы очень открытые, но предполагается определённая схема ответа, и как обычно, времени на всё впритык. Обращу внимание на подводные камни. В первом вопросе будет проблемой добиться уникальности максимально коротких URL, генерируемых кластером машин. Во втором вопросе будет куча проблем вокруг повторных крэшей на одном устройстве, переинсталляции приложений, регулярное отсутствие интернета у мобильного телефона, сложность определения, что такое «активный пользователь», например, у мессенджера. Многие из этих проблем не кажутся проблемами, когда вы о них тут читаете, но их можно просто упустить из виду. В третьей задаче сразу всё сложно и проблем много.
Во-первых, начинаем с уточнения деталей. Правильно ли мы понимаем суть задачи, сколько предполагается посетителей в сутки, какой будет поток запросов, объёмы данных. На некоторые важные вопросы у собеседующего может не быть ответов, тогда делайте свою грубую оценку. Умение делать оценки и обосновывать их будет тоже учитываться.
Потом рисуем на специальном сайте высокоуровневую схему приложения. Обычно это блоки вида «мобильное приложение», «браузер», «балансировщик», «кластер бэкенд машин», «кластер машин с фронтендом», «распределённая база данных» и далее по вкусу и смыслу. Часто добавляются дополнительные специализированные базы данных, дополнительные веб-сервисы, кэши, очереди сообщений между ними и т. п. Как и в алгоритмическом интервью, желательно пояснять, что вы делаете и зачем, а не рисовать молча.
Далее прорисовываем детали с упором на те части, которые вам более знакомы. Можно выбрать фреймворк для фронтенда, выбрать язык и фреймворк для бэкенда. Для каждого узла схемы не забудьте нарисовать и пояснить, будет ли это одна копия или же кластер. Для очередей сообщений определитесь, как с ней будут общаться читатели — активно читать (long polling) или подписываться и получать уведомления о новых сообщениях. Часто собеседующий сам может вас спросить про детали, если ему покажется недостаточной их проработка.
Обязательно выберите тип базы данных (БД) и конкретный продукт этого типа. У меня был целый лист со шпаргалкой по выбору БД, так как большинство этих баз я видел только на картинке. Обязательно обоснуйте, почему у вас, скажем, реляционная БД, а не колоночная NoSQL. Почему выбрали MySQL, а не конкурента?
«Я выбрал реляционную базу данных, потому что для нашего финансового сервиса крайне важно поддержание целостности данных; это будет MySQL, а не Oracle, потому что у неё лицензия сильно дешевле, а также у нас нагрузка предполагается не столь высокая».
Следующий этап — описать схему базы данных, описать схему данных в сообщениях очереди (если они есть).
Ещё обязательная часть ответа — это описать API серверов. API я обычно описывал как функции с типизированными аргументами и возвращаемыми значениями. Обычно нет нужды спускаться слишком близко к HTTP. Хорошим ходом может быть заложить возможность вернуть ошибку в ходе выполнения запроса, заложить такие вещи, как асинхронность, идемпотентность и т.п, но у меня для таких нюансов обычно не хватало времени.
Последним штрихом будет показать, как работает типичный сценарий. Какие при этом будут генерироваться запросы, через какие модули они будут проходить, кто их будет обрабатывать, как данные для ответа будут собираться, как данные будут растекаться по системе (если такое предусмотрено).
Например, типичный сайт с кнопкой «лайкнуть пост» будет работать примерно так:
У разных компаний FAANG в основном похожие требования к проектированию. Но у Amazon, кроме обычного проектирования, было и дополнительное смешанное интервью: проектирование с кодированием. Это неожиданный формат, где мне приходилось писать псевдокод для веб-сервиса, описывающий решение задачи. Было немного и алгоритмического (базовые вещи), и взаимодействие с клиентами сервиса. Например, итеративно решались вопросы недоверия клиенту, пытающемуся читерить, добавлялась асинхронность обработки длительных запросов от клиента. Всё это лишь псевдокод, надо показать правильные намерения и принципиальную возможность решить задачу указанным вами способом.
Если вы молодой разработчик, то провал проектирования может сильно не влиять на получение предложения о работе. Просто вы получите предложение на позицию ниже. Кажется, это интервью могут вообще не дать претендентам на невысокую позицию, но это не точно.
CAP-теорема (очень полезно почитать, если вы не слышали о ней раньше)
Официальное видео от Amazon «Amazon System Design Preparation (SIP)»
Стороннее демо-интервью «Amazon System Design Interview: Design Parking Garage»
Стороннее демо-интервью «Facebook System Design Interview: Design Twitter»
Надеюсь, мой опыт собеседований, описанный в данной серии статей, кому-нибудь пригодится, чтобы вдохновиться, трезво оценить силы и пройти этот путь с успехом. В конечном итоге выучить недостающее и натренироваться проходить интервью вполне реально. Я убеждён, что знания, приобретённые в процессе подготовки, обогащают нас как специалистов в computer science. Если задуматься, то можно ли считаться хотя бы начинающим специалистом в computer science человеку, который не может решать таких задач по алгоритмизации? И можно ли в наше время интернета считаться опытным специалистом человеку, который не способен решать такие задачи по проектированию?
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Меня просили задизайнить в разных компаниях
distributed counter of requests in REST API make paid rest api (all clients rest requests should charge the client) tickets reservation system Instagram (photo sharing service with news feed) how to migrate data from Skype for business into Ms teams
Невероятно полезная информация.
Так надо бы кое что сказать и о том как выполнялся сам дизайн. Проблемы, решения.
А то пока получается как в детской песенке:
"Какой хороший я и песенка моя."
Для опытного разраба наоборот, самое легкое, т.к. используешь знания из опыта, а не специально сидишь месяцами и запоминаешь паттерны только для интервью.
Зависит от опыта. Фаанги спрашивают задизайнить распределенную систему, но не каждый имеет опыт именно в этом(это не значит, что опыт плохой, просто другой). Плюс формат ответа предполагает, что вы зададите вопросы и прикините числа, запросы в секунду, кол-во инстансов, необходимое место в хранилище идт.
Такой опыт совсем не у каждого, часто это так выглядит "а закинем в облако оно заскейлит". Так что приходится немного потренить именно такой формат.
Название статьи уже сменили на менее кликбейтное и ближе к реальности. :) Без "самое сложное интервью".
Но со следующим автором (@sup) я тоже согласен. Опыт очень тут помогает, но опыт весьма специфический требуется.
Стоит вспомнить, что Дима Королёв организует System Design Meetup, на котором всему этому можно научиться:
https://twitter.com/SysDesignMeetup
Привет! Как думаешь, откуда минусы?
На UI (mobile, web) эта часть обычно сильно проще, чем на vanilla SWE.
Ну оно и понятно, многих проблем, вроде масштабируемости, в принципе там не существует.
А когда нанимают мобильных разработчиков на Senior позицию, то им не дают по-вашему system design интервью?
У вас есть информация про это?
Дают, и на фронт-энд тоже дают. Просто по моему субъективному ощущению эти систем дизайн вопросы проще, причем на порядок.
Основной упор на vanilla SWE system design идет на масштабируемость и отказоустойчивость - в каком месте на мобилках или вебе это нужно? кроме каких-нибудь бесконечных списков/feed-ов c ленивым рендерингом (а-ля sliding window) я например ничего не могу придумать.
Конечно System Design это уровень Seniors или Architects. Тут важен и experiense, и background, и профессиональный кругозор разработчика.
Опыт, как правило, узкий. В определённой сфере.
Можно, конечно, поднатаскаться на трейнигах как проходить такие интервью. Однако опытный интервьюер будет видеть что перед ним школьник.
Поэтому важным является хорошее классическое образование в Computer Science. И если оно есть то и опыт приобретается намного быстрее и эффективнее.
Респектабельные компании часто требуют от претендентов степени магистра в Computer Science, a бокалавров даже не приглашают на интервью.
бокал.авров никто не приглашает без справки от нарколога
Вот бакалавров можно...
Порекомендуйте English тичер please, очень хочу shine в обществе!
У меня диплом БГУ.
I don't have master of computer science.
Uber, Amazon, Meta, Uber invited me before...
Если не знаете как ответить, тогда можно сходить на 15+ суточный Workshop туда, где самые опытные и ответственные люди.
System Design (от Alex A. из CocoaHeads Belarus)
https://www.educative.io/courses/grokking-the-system-design-interview – классика https://www.youtube.com/playlist?list=PLMCXHnjXnTnvo6alSjVkgxV-VH6EPyvoX – плейлист от братьев индусов, но качество материала хорошее и смотреть интересно https://github.com/donnemartin/system-design-primer – бэкенд гайд по system design https://dataintensive.net – Книга «с кабанчиком» https://courses.systeminterview.com/courses/system-design-interview-an-insider-s-guide – курс по system design и отзыв на него https://github.com/checkcheckzz/system-design-interview – How to prepare system design questions for an IT company https://www.freecodecamp.org/news/systems-design-for-interviews/ – System design Interview Questions https://www.youtube.com/watch?v=ZgdS0EUmn70 – просто какой-то видос