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

Эта статья будет полезна как кандидатам которые хотят "взломать" System Design интервью, так и руководителям в сфере мобильной разработки, желающих внедрить секцию System Design в своей компании.

В последнее время рынок труда в ИТ-индустрии переходит от рынка соискателя к рынку работодателя и компании все чаще заинтересованы в отборе максимально опытного специалиста, удовлетворяющего всем требованиям. Скорее всего вы слышали о недавних сокращениях в BigTech-компаниях, специалисты из которых наводнили рынок и теперь рубятся за позиции в компаниях поменьше. Однако стандартные наборы вопросов уже давно изжили себя, и большинство как российских так и зарубежных компаний стараются выбирать форматы собеседований которые максимально помогают проявить кандидата в бою. Одним из таких форматов является System Design Interview о котором мы и поговорим сегодня.

Перед тем как перейти к секции System Design давайте рассмотрим какие вообще этапы чаще всего встречаются когда вы ищите новую работу:

• Общение с HR или нанимающим менеджером/руководителем.
  
• Техническое собеседование с инженерами из Android/iOS команды.
  
• System Design интервью
  
• Поведенческое интервью
  
• Оффер
  
  

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

Между этими этапами или вместо какого-то из них может быть этап разработки тестового задания и его защиты (как в примере выше) или решение алгоритмических задач по типу тех, которые есть на Leet Code. Я не буду рассказывать на что обратить внимание при разработке тестового задания или как пройти поведенческое интервью, сконцентрируемся в этой статье на System Design Interview..

System Design интервью - это секция собеседования в которой кандидату предлагается спроектировать архитектуру какого-либо сервиса или приложения с учетом ряда требований. Такой формат собеседования проверяет способность кандидата строить масштабируемые и высоконагруженные системы. Но формат обычно отличается в зависимости от того на какую позицию откликается кандидат. Для мобильного и бэкенд-разработчика ответы будут отличаться. Для мобильного разработчика (неважно Android/iOS) скорее всего не будут задавать вопросы про шардирование и репликации, так как перед Android или iOS-разработчиками лежат совершенно иные задачи. Здесь могут спросить про кэширование локальных данных, скорость отрисовки данных на экране и даже оптимизацию расхода батареи. Примерами заданий могут быть: спроектировать Youtube или Twitter или какой-нибудь мессенджер. Может возникнуть вполне разумный вопрос: "Как можно спроектировать за 1- 2 часа систему над которой трудятся сотни инженеров?" Но здесь и заключается главная фишка System Design Interview: важна не столько архитектура, которую вы предложите, сколько сам процесс проектирования. Важно какие вопросы вы задаете, какие edge-кейсы вы можете предусмотреть и как обосновываете то или иное решение или применение технологии.

Всего можно выделить 4 этапа при прохождении этой секции:

• Понимание задачи и выяснение требований
  
• Общее решение и верхнеуровневый план архитектуры
  
• Подробное описание каждого компонента архитектуры
  
• Подведение итогов
  

Исходя из того, что секция длится 1 час (15 минут обычно отводится на small talk вначале и вопросы от кандидата в конце) чистого времени остается совсем немного (45 минут), поэтому тайм-менеджмент очень важен. Для удобства каждый этап помечен таймингом.

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

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

Для мобильного приложения уместными будут следующие вопросы:

1. Функциональные требования. Кто наши пользователи, как они будут использовать приложение, какие сценарии использования? Какие самые важные возможности должны быть у этого продукта?
   
   
2. Нужно ли спроектировать только мобильное приложение или остальные системы тоже? (Может быть нужно спроектировать API, структуру ответа от сервера)
   
   
3. Должны ли мы поддерживать планшеты/wear OS или только смартфоны?
   
   
4. Какая минимальная версия Android API? (От этого могут зависеть дальнейшие решения)
   
   
5. Нужно ли поддерживать кэширование? Push-нотификации? Авторизацию?
   
   

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

Чтобы не забыть полученную информацию, запишите на доске (в Miro, Draw.io или Excalidraw). Эта информация в дальнейшем вам пригодится.

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

На этом этапе вы уже можете брать виртуальный маркер и начать рисовать верхнеуровневую диаграмму. Вам необходимо нарисовать блоки с ключевыми компонентами системы. Если говорить про Android-разработку, то нужно упомянуть принципы Clean Architecture и разделение по слоям. Примером такой диаграммы может быть пример ниже:

В зависимости от задачи, компонентов может быть и больше и они могут быть чуть более детальными как в следующем примере:

Важно! Комментируйте вслух почему вы решили использовать тот или иной компонент, какая у него будет ответственность. Например: DataSource будет отвечать за кэширование данных, потому что мы будем использовать offline-first подход.

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

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

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

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

• Api Data Source. Этот компонент будет отвечать за коммуникацию между вашим приложением и сервером.
  
• Local Data Source/Persistence. Для многих мобильных приложений необходима реализация локального персистентного хранилища данных.
  
• Repository - компонент являющийся посредником между вашими Api Data Source и Local Data Source, и вызывающий методы Local Data Source для кэширования например.
  
• UseCase - бизнес-логика для конкретного экрана. Например нужно отсортировать элементы или сделать какие-то расчеты перед тем как отобразить их на экране.
  
• ViewModel, Fragment, RecyclerView - сущности на уровне Presentation-слоя.
  
• DI - компонент отвечающий за Dependency Injection
  

Еще могут быть

• Image Loader
  
• Coordinator
  
• App Module
  
• Push Notification Service
  
  

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

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

Например: вам нужно спроектировать приложение прогноза погоды. Для взаимодействия с сервером можно выбрать REST Api и для Android-приложения использовать библиотеку Retrofit + OkHttp, или можно использовать GraphQL и библиотеку Apollo для мобильного Android-клиента.

И тут вы должны пояснить интервьюеру что мы будем тут использовать Rest Api и связку Retrofit+OkHttp потому что:

REST API — самый популярный сегодня стандарт взаимодействия приложений, поддерживающий CRUD-операции и обмен сообщениями без сохранения состояния. Каждое сообщение самодостаточное и содержит всю информацию, необходимую для его обработки. Сервер не хранит результаты предыдущих сессий с клиентскими приложениями. Его достаточно просто реализовать.

Из минусов такой подход менее эффективен для мобильных платформ так как каждый запрос требует отдельного соединения, и поэтому если нужно очень часто обмениваться данными можно выбрать что-то более подходящее. А еще так как Rest API полагается на HTTP, то из-за HTTP есть еще недостатки такие как: низкая производительность операций сериализации и десериализации данных, передача бинарных данных требует дополнительного кодирования, например, через Base64. Но так как нам не нужно передавать огромное количество данных и не нужно поддерживать изменения погоды в реальном времени, то для приложения прогноза погоды будет достаточно Rest API и Retrofit + OkHttp.

Далее аналогично вы можете пройтись по Local Data Source, расскажете что это за компонент такой для чего он нужен. Можно рассказать об инструментах и библиотеках, например в Android-разработке можно использовать Realm или Room, но Realm является Non-sql решением, а под капотом Room'a реляционная база данных SQLite, а еще оно поддерживает Full Text Search и индексы.

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

Таким образом, шаг за шагом вы проходите каждый компонент и не забудьте рассказать о presentation-слое какой паттерн вы используете (MVP/MVVM/Viper etc) и почему.

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

• Какие метрики будете отслеживать и как?
  
• Как логировать и что?
  
• Как реагировать на отсутствие сети, геолокации?
  
• Для каких компонентов в первую очередь будете писать тесты?
  
  

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

⏰ Следите за временем. Интервьюер может вас отвлекать – ваша задача максимально полно представить решение за короткий срок. Заранее ознакомьтесь со средой в которой будете рисовать. Это может быть Draw.io, Excalidraw.

✍ Потренируйтесь на известных мобильных приложениях и почитайте технические блоги крупных продуктов – они часто пишут как сделали ту или иную крутую фичу. Например вот тут недавно писали как запускали аналог Twitter который называется Threads.

⏳ Попробуйте мок интервью. Попросите ваших коллег или поищите наставника, которые могут послушать вас и провести тестовое собеседование еще до того как вы упустите оффер своей мечты. Или стучитесь ко мне в Telegram или записывайтесь на консультацию через GetMentor

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

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

Чтобы не пропустить следующие статьи на тему Android и мобильной разработки подписывайтесь на Telegram-канал