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

Что проверяют

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

Как отвечать

Рассказывайте про свой проект сверху вниз, с причиной каждого решения. Каркас, на который ложится современное Android-приложение:

• UI-слой: Jetpack Compose или фрагменты, ViewModel держит состояние экрана в StateFlow. Поток однонаправленный: UI шлёт событие, получает новое состояние;
• domain-слой: классы UseCase там, где логика переиспользуется между экранами. В официальном гайде он опциональный;
• data-слой: репозитории как единый источник правды, Room локально, Retrofit или Ktor поверх OkHttp для сети;
• DI: Hilt или Koin, скоупы приложения и экрана;
• асинхронность: корутины и Flow, viewModelScope, диспетчеры внедряются, чтобы подменять их в тестах;
• модули: :core, :feature-*, общие Gradle-конвенции. Скажите, что дала разбивка: время сборки, границы между командами.

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

Если архитектуру заложили до вас, так и скажите. Расскажите, что в ней поняли, что улучшили и что предлагали поменять. Это честнее и звучит сильнее, чем присвоенное чужое решение.

Где спотыкаются

Перечисляют аббревиатуры без причин. «У нас MVVM, Room, Dagger» ничего не говорит, а «выбрали MVI, потому что у экрана оплаты семь состояний и они расходились» уже ответ.

Складывают всю логику во ViewModel, а репозиторий превращают в прокладку над Retrofit. На вопрос про тесты тогда отвечать нечем.

Держатся устаревшего стека без оговорок. LiveData и чистый Dagger ещё встречаются, но, называя их, будьте готовы объяснить, почему не StateFlow и Hilt и как бы вы мигрировали.