System Design. Mobile — как вкатиться?

 Публичный пост

Приветики!

О чем речь

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

Что нашел

Если покопать то находится следующее:

  • Канал на ютьюбчике от staff инженера гугла у которого висит в открытом доступе большая пачка моковых интервью. Довольно полезно, но пока не обнаружил такого интервью чтобы хотелось сказать "топ, вот так я и хочу" - в основном кандидаты довольно потерянные и/или акцент/уровень языка такой, что сложно воспринимать (при всем уважении к ребятам, собесится под запись перед аудиторией это искренний респект). Ну и фидбек у него в конце довольно разносящий, не видел пока ни одного видоса где он бы позитивно отозвался (понятно что output этого вида собесов небинарный, но тем не менее).
  • Репозиторий от вышеупомянутого чувака, где он довольно четко и красиво разложил как он это видит. Довольно интересный подход, но ключевой момент "как он это видит" - есть спорные моменты, а никакой альтернативы найти не удалось.
  • Всратые видосы по 10-15 минут на ютьюбчике в которых предлагают выучить тонну базвордов или другие сомнительные советы.

Погулял по клубу поиском, кажется все что есть опять же про классический System Design.

Что ищу

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

Интересно послушть про опыт других - как вкатывались в данную тему, как готовились к подобным собесам, по каким граблям ходили и тд.
Если вдруг в клубе есть кто-то с опытом проведения данных собесов и желанием помочь в формате мокового интервью - буду дьявольски благодарен!

Свой опыт

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

Заранее спасибо господа и госпожи!

Связанные посты
21 комментарий 👇

Мобилка же в контексте системного дизайна является просто клиентом, может быть весьма жирным и нажористым, но клиентом.
Просто взять из обычного системного дизайна всё что касается клиентов?

Я бы ещё serverless поглядел.

  Развернуть 1 комментарий

@MaximKonovalov, тут я бы не согласился немного 🙂

Мобилка же в контексте системного дизайна является просто клиентом

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

  Развернуть 1 комментарий

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

  • Нужно уметь порассуждать об архитектурах - всякие MVP, MVVM, Clean. Что в какой слой падает и почему. Прочитать букет статей на тему Clean в мобилках и как это работает на практике (спойлер - не всем пунктам надо следовать дотошно, можно дропать доменный слой и юзкейсы, если прилага простая. Или там не между всеми слоями конверсии данных делать, иногда достаточно от сетевого слоя абстрагироваться)
  • Нужно уметь нарисовать диаграмки реализации какой-то фичи с учетом этой архитектуры. Типа - "давайте сделаем кнопку лайк как в инстаграме". И ты начинаешь - вот у нас дергается метод вью модели, модель дергает репозиторий, он передает данные в сервис. В обратную сторону у нас торчит Observable/Flow, потому что число лайков постоянно обновляется, а не статично, а еще мы приделаем локальный кэш, чтобы не ждать полгода, пока запрос на добавление лайка на бэкенде обновился.
  • Нужно уметь задать уточняющие вопросы собеседующему, чтобы выяснить детали, что я описал сверху - "как часто обновляются лайки", "что у нас с сетевой стороны, "а нужен ли кэш" и все такое.
  • Нужно быть готовым к тому, что попросят в этот флоу добавить изменения - "а представьте, что не загрузилось, куда воткнете обработку ошибок и почему?"
  • Обычно я на это все отвечаю с учетом реального опыта работы + чтение всяких статей про модные веяния в архитектуре. Какого-то прям централизованного источника мудрости не встречал.

Еще вот этого парня читал когда-то для упорядочения мышления на интервью https://medium.com/geekculture/system-design-interview-for-mobile-engineers-ce712d6ac2c1

  Развернуть 1 комментарий

@Stenopolz, Спасибо за подробное описание и ссылочку, полистал, выглядит как то что стоит прочитать внимательно 👍🏼

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

  Развернуть 1 комментарий

@dosssik, ну можно и big picture накидать сначала - сразу расставить дефолтные компоненты архитектуры и потом показать, как именно ты их свяжешь. Это происходит в течении трех минут.

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

Была поставлена задача - мы хотим сделать генеалогическое древо пользователя. Дальше шли по этапам

  • Как оформить структуру данных
  • Как потом к этим данным добавить метод по поиску сестер
  • Как оформить данные в виде REST запроса и ответа так, чтобы не тащить все дерево одним запросом, но при этом не делать по 100 запросов, если тебе нужен набор данных заданной глубины (хинт, это известная задача про графы со множественными связями в Json)
  • Как организовать запрос так, чтобы пользователь мог получить доступ только к своим родственникам, а к чужим не мог(если они не общие, конечно)
  • Как эти же данные сложить в базу данных

Выглядит как более общий data design без бэкендовых или мобильных заморочек вовсе

  Развернуть 1 комментарий
Владислав Бауэр Говнокожу в андроид репу 18 октября 2022

О, я всегда думал, что на собесах спрашивают какой-то общий system design)

У нас в компании второй этап чем-то напоминает system design, есть кейс и вы проектируете прилу. Описываешь архитектуру, стек и вот это всё. В некоторых моментах углубляетесь и надо пояснить почему такое решение принято.
Типо MV(что-то) не просто потому что нравится, а потому что отлично заходит под этот кейс. Room не потому что я только этот варик работы с бд знаю. А вот так будет выглядеть какая-нибудь моделька итд.

PS я в итоге просто перефразировал @Stenopolz =)

  Развернуть 1 комментарий

Сам нахожусь на пороге предстоящих интервью. И пока что наткнулся на книжку : Building Mobile Apps at Scale. И у автора есть интересный блог с Ютуб-каналом

https://www.mobileatscale.com/

  Развернуть 1 комментарий

@nemironium, я читал эту книжку, и там совсем не про систем-дизайн приложений, а скорее про проблемы мобильных разработчиков в кроссфункциональных командах при росте числа пользователей и числа самих разработчиков. То есть книга больше для менеджеров и про сам код в ней очень мало. Однако как полезное незамысловатое чтиво очень занимательно.

  Развернуть 1 комментарий

@nemironium, Добавил книжку в стек того что хочу почитать, спасибо!

  Развернуть 1 комментарий

На mobile engineer достаточно условный system design спрашивают, даже в компаниях типа Meta, Doordash и Reddit. Как правило, все упрощается в том числе тем, что интервью длится 45-60 минут, за которые ну очень сложно много что спроектировать. В половине случаев меня на интевью просили накидать архитектуру экрана списка и подробной информации. Здесь же можно предложить целевое REST API, если его нет в условии.
Сначала объясняешь по слоям, какие подходы, паттерны собираешься использовать, как происходит передача данных, какие объекты. Далее более детально все или частично, что успеешь или на чем будут основные вопросы интервьюера. Обычно в таких задачах есть какие-то предыусловия, например, что данные могут измениться в случайный момент и нужно поддержать их актуальность, или что делать, в случае если надо приложение работает в оффлайне и пользователь может изменить данные, как их потом отправить на сервер?
Думаю, тут где-то 80% опыта + 20% приобретенных знаний (в том числе разные обсуждения/статьи как в каком-то приложении реализована какая-то фича).
Слышал, что в некоторых компаниях из MANGA могут задать более расплывчатые вопросы по типу "спроектируй приложение музыка" или читалку книг.
В текущей ситуации, когда у тебя есть реальный опыт, советую идти с наиболее абстрактных уровней вниз, разбивать крупную задачу на более мелкие и задавать уточняющие вопросы по API, кэшу, оффлайн-работе и учитывать все крайние условия. Если начнешь опускаться слишком глубоко в детали с самого начала, есть риск слишком там завязнуть и упустить задачу в целом.

  Развернуть 1 комментарий

@vav_ivan, спасибо 👍🏼

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

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

  Развернуть 1 комментарий

По System Design рекомендую этот проект https://bytebytego.com/.
Чем он интересен:

  • У автора есть 2 неплохих книги.
  • Discord сервер только по приглашению, где можно обсудить детали, пообщаться на тему Sys design или забукать mock интервью с другими участниками. Там есть spreadsheet, где каждый выставляет ссылку на calendly. Или можно просто постить в канал. Сообщество довольно активное, кто-нибудь быстро откликнется.

-Инвайт линк https://discord.com/invite/kdjq9psJb8 (вроде работает еще).

  • Надо знать английский.
  Развернуть 1 комментарий

@KApsHKTcdhHs8ME0, Выглядит интересно но не нашел информации в контексте мобилок. Спасибо в любом случае, бекенд тоже интересно, но после того как с мобильными собесами разберусь 🙂

  Развернуть 1 комментарий

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

Общее описание процесса - https://themobileinterview.com/cracking-the-mobile-system-design-interview/

Более подробно с примерами ответов (хотя со многими пунктами не согласен, некоторые ответы все же из мира бэкенда) - https://davescommutebloghome.wpcomstaging.com/category/interviewing/

Примерный список тем, которые нужно затронуть - https://www.shashankthakur.dev/2021/10/system-design-interview-for-mobile.html

Репозиторий с кучей инфы по теме - https://github.com/weeeBox/mobile-system-design

В этом же репозитории есть упражнения (хотя можно и самому себе придумывать "спроектируй 2гис на iOS") - https://github.com/weeeBox/mobile-system-design/tree/master/exercises

Пример ответа - задизайнить ленту фб -

  Развернуть 1 комментарий

@daemon100, спасибо за ссылки!👍🏼
Половину уже находил и прочитал, остальное на очереди теперь

  Развернуть 1 комментарий
m.koutun Director of Engineering 24 октября 2022

https://proandroiddev.com/a-simple-framework-for-mobile-system-design-interviews-89f6f4134b84 вот очень хорошая серия статей про mobile system design

  Развернуть 1 комментарий

@mkoutun, Ага, мне тоже понравился этот подход, собственно его и упоминал в посте как первое что нашел - автор статьи перенес это дело на гитхаб где более детально расписал идеи и примеры.

  Развернуть 1 комментарий

@dosssik, тогда я бы ничего другого не искал, тут очень круто описан подход по system design в терминах понятных мобильному разработчику.
Все остальное это уже про кругозор и его скорее можно получить дополнительными знаниями: условно принципы системного дизайна для бэканда будут такими же, просто там уже будут важны именно знания особенностей распределенных систем

  Развернуть 1 комментарий

@mkoutun, согласен, я его в итоге и использовал как основной ресурс для подготовки (у автора на youtube еще добротная подборка мок-интервью с фидбеком в конце).
Было интересно узнать, есть ли другие, ощутимо отличающиеся подходы, но ничего радикально другого не нашел 🙂

  Развернуть 1 комментарий

@dosssik, удачи тебе в собесе! по моему опыту, если ты разложишь задачу, как предложено в статьях - у тебя все получится
Еще важно применить этот принцип на твой опыт, часто system design может быть на основании твоего бэграунда.
Ну и скорее ты можешь найти какие-то обобщения с примеров выше. Главное добавить реальных продуктовых трейдофов и как вы с ними справлялись

  Развернуть 1 комментарий

@mkoutun, спасибо! 😄

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб