Modularization Interview Questions
BUILD & TOOLING › Gradle
Walk me through how you'd decide whether a growing single-module app is actually ready to be split into multiple Gradle modules, versus just needing better internal package structure.
What a strong answer covers: Modularization is worth the Gradle and DI wiring overhead when there's real pain: incremental builds are slow because everything recompiles together, multiple teams need clear ownership boundaries, or you have a genuine need for Play Feature Delivery. If the codebase is small or single-team and the actual problem is disorganization, tightening internal visibility and package boundaries within one module solves it without the multi-module overhead of extra build files and cross-boundary DI wiring.
Two features need similar but not identical UI, say a details screen for two different entity types. How do you share that without creating a feature-to-feature dependency, and when would you decide it's not worth extracting a shared module?
What a strong answer covers: Extract the common UI into a shared, entity-agnostic module driven by an interface or shared data model that both features depend on downward, rather than one feature depending on the other's concrete types. If the similarity is superficial, same layout but diverging business rules, a small amount of duplication is usually the better trade, since a premature shared abstraction across features tends to cause more coupling pain than the duplication it was meant to avoid.
You've fully modularized into 40-plus modules with clean api and implementation boundaries everywhere. What real costs have you likely introduced, and how do you know if you've over-modularized?
What a strong answer covers: Symptoms include configuration time growing despite build and compile caching, since evaluating dozens of build.gradle.kts files has fixed overhead per module, plus a proliferation of tiny modules each requiring their own DI wiring that adds boilerplate without meaningfully improving build parallelism or ownership clarity. You know you've overshot when profiled build and CI times don't actually beat a coarser-grained baseline, or when module boundaries don't map to real team boundaries and developers spend more time navigating interfaces than they save in build time.