📚 Реальные задачи на System Design собеседовании для мобильного разработчика

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

Итак, какого типа задачи ожидать на System Design интервью для мобильного разработчика? Это реальные задачи которые я видел:

📌 Спроектировать приложение прогноз погоды.
📌 Спроектировать банковское приложение для отслеживания котировок акций.
📌 Спроектировать приложение для отслеживания заказа.
📌 Спроектировать приложение редактор картинок

Таким образом, на позиции мобильного разработчика от вас никто не ждет что вы сможете спроектировать высоконагруженный бэкенд, однако иметь представление о сетевом слое все-таки необходимо. Вы должны уметь рассказать о плюсах и минусах например REST API vs GraphQL и доказать почему именно REST подойдет вашему приложению которое вы проектируете.

О чем еще неплохо порассуждать и показать что вы знаете о чем говорите:

📌 Реляционные БД vs No-SQL решения
📌 Server-Driven UI
📌 Способы тестирования и плюсы минусы тех или иных подходов
📌 MVP vs MVVM vs MVI.

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

Ну и напоследок, самое главное что от вас ожидают на System Design интервью - это способность задать уточняющие вопросы, предложить идеи. Не начинайте рисовать диаграммы пока не спросите 5-10 вопросов. Если молча начать проектировать архитектуру - это красный флаг.

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

- Набор примеров задач для System Design Interview
- System Design. Подготовка к сложному интервью. Автор:Алекс Сюй
- System Design Template
- System Design CheatSheet

📺 Enhancing Jetpack Compose app performance (28 мин) - большое видео с советами про оптимизацию скорости работы Compose UI

#performance @compose_broadcast

Feature freeze для JDK 22 выглядит прямо прикольно. Много интересных приятных изменений. Прямо разворошили этот улей за последние несколько лет.

#java #jdk

⚙️ Взламываем System Design интервью для мобильного разработчика.

Как и обещал, написал детальную статью по System Design интервью для мобильных разработчиков. Тут кратко расскажу про этапы и рекомендации, а на хабре более подробно с примерами и диаграммами. https://habr.com/ru/articles/781404/

В зависимости от процессов найма в компании на System Design у вас будет скорее всего около 1 часа. Это супер мало, поэтому четко планируйте время и старайтесь придерживаться следующего тайминга:

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

2️⃣ Построение общей архитектуры верхнего уровня. (10-15 минут).

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

3️⃣ Детальное описание каждого компонента вашей архитектуры и выбор решения. (20 минут).

На данном шаге вы согласовали требования и спроектировали примерную архитектуру. Теперь необходимо углубиться в каждый из компонентов и описать как бы вы реализовывали тот или иной компонент. Имея список компонентов (в реальном интервью он у вас на схеме перед глазами) вам необходимо пройтись по каждому и рассказать плюсы минусы альтернативных решений и почему вы выбрали именно это. Например реализация кэширования через Room vs Realm, использование сокетов или Rest API и т.д.

4️⃣ Подведение итогов и ответы на вопросы. (10 минут).

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

Рекомендации

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

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

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

С большим опозданием, но все же опубликовал исходный код с доклада.

Там самые разные компиляторные плагины, такие как:
- подсветка рекомпозиций
- логирование причин рекомпозиций
- удаление вызовов функции sourceInformation
- генерация/удаление/отображение testTag
- анализ стабильности параметров composable функций

Все компиляторные плагины подключаются к проекту как gradle plugin. Можно все по отдельности, а можно вместе - так удобнее настраивать.

В проверках стабильности параметров поддержаны самые последние обновления Compose Compiler, а именно возможность задавать в файле классы, которые надо пропустить в проверках. Подробнее писали тут.

Кроме этого есть ещё idea plugin. Правда в виде jar, так как получил отказ при попытке публикации в JetBrains Marketplace.
Он умеет отображать какие testTag будут сгенерированы компиляторным плагином, а так же проверять стабильность параметров функций и отображать ошибку в редакторе кода. Конечно, не на 100%, как это в компиляторном плагине сделано, но, думаю, в большинстве случаев правильно.

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

Если будут проблемы или вопросы - пишите. Попробуем решить)

github.com/VKCOM/vkompose

Хак через десериализацию
#android

Давно я не появлялся на канале: со мной всё хорошо, но дела под конец года забрали всё свободное время, а серая погода — забрала всё желание писать. Но… надо не забывать вас, поэтому возвращаюсь!

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

Короч я устал отдыхать, и решил начать год с публикации материала для новичков. Надеюсь, что он будет полезен всем кто только пришел в мобильный инфобез или собирается прийти. Возможно я буду дополнять и актуализировать этот материал, если пойму, что упустил какие-то важные детали или что-то эволюционировало слишком сильно. Всем продуктивного года! 👨‍🔬

Такая вот работа получилась. Большая статья про шифрование в Android и атаки на него.

Pending Intents, что это и зачем?

Крайне полезная статья про механизм Pending Intents в Android, которая очень хорошо структурирована.

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

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

#android #intents

Официальная энциклопедия от JetBrains по интеропу между Kotlin и Swift. Рассказывается как работать с разными фичами Kotlin из Swift кода

Создание и использование BOM в Gradle

В статье рассказывается про то, как можно организовать BOM (bill of materials) для управления версиями зависимостей + рассматриваются более сложные кейсы создания и использования BOM в Gradle-проектах.

👉 Зачем вообще нужен BOM?
👉 Как выглядит BOM?
👉 Когда создавать свой BOM?
👉 Что такое Rich Model и Gradle Module Metadata?
👉 Как несколько BOM сочетаются друг с другом?
👉 Управление версиями Gradle-плагинов через BOM

Читать (Ru)

HashMap для Jetpack Compose
#compose #performance

Интересная статья, где рассказывается про минусы стандартной HashMap в контектсте использования Jetpack Compose.

При использовании mutableMapOf() под капотом создаётся LinkedHashMap(), которая довольна хороша, но имеет недостаток: при каждом новом добавлении элемента создаётся LinkedHashMapEntry, из-за чего структура не очень memory-friendly.

Ну и сходу предлагается использовать другую структуру — ScatterMap, у которой подобных недостатков нет. В статье есть и замеры, и описывается главный недостаток этого подхода: структура хоть и map-based, но не наследуется от привычного нам Map, хотя и имеет подобные ему классы.

Стоит ли бежать заменять мапы на неё? Безусловно, нет: сам автор признаётся, что вам просто стоит иметь в виду, что такая структура существует и вы вспомните о ней, когда аллокация памяти будет очень критичным моментом.