Опишите архитектуру проекта: монолитная или мультимодульная
Что проверяют
Понимаете ли вы, зачем в проекте модули, или знаете только слово. Хороший ответ здесь не про то, что проект мультимодульный, а про то, какую проблему деление решало и чего оно стоило команде.
Как отвечать
Скажите, как было на самом деле, и назовите причину. Главная выгода деления на модули Gradle это время сборки: при аккуратных зависимостях пересобирается только затронутый модуль и то, что от него зависит. Дальше идут явные границы между фичами, отдельный прогон тестов и возможность собрать фичу отдельным приложением для проверки.
Цена тоже называется вслух: настройка и поддержка общих конфигураций, каталог версий, слой навигации между фичами, риск запутанного графа зависимостей.
Опишите деление, которое прижилось: тонкий модуль приложения, модули фич, общие модули для сети, хранилища, моделей и элементов интерфейса. Внутри каждого слои данных, домена и представления, однонаправленный поток состояния, внедрение зависимостей. Подчеркните, что многомодульность не заменяет архитектуру внутри модуля: можно разложить проект на два десятка модулей и оставить в каждом ту же кашу.
Где спотыкаются
Говорят, что деление сделали, потому что так правильно, без единого замера. Вопрос, насколько ускорилась сборка и чем это мерили, остаётся без ответа, хотя отчёт сборки как раз и показывает, где уходит время.
Второе: делят по слоям на весь проект, отдельными модулями данных, домена и представления. Любая правка фичи задевает все три сразу, инкрементальность не работает, зависимости остаются общими. Делить полезнее по фичам, а слои держать внутри.
Третье: раздают зависимости через api вместо implementation и складывают всё подряд в общий модуль. Граф становится связным, правка одной строки пересобирает проект целиком, и выгода, ради которой всё затевалось, исчезает.