Explain the difference between Gradle build types and product flavors.

WHAT THIS TESTS: This question probes whether you understand the two independent axes of Gradle Android builds. Build types control the mechanics of compilation and packaging, while product flavors control the functional identity of the application. Senior engineers are expected to reason about multi-dimensional build graphs, avoid redundant configuration, and know when to extend the build logic rather than duplicate it.

A GOOD ANSWER COVERS: First, define build types as the how dimension. Debug and release are the defaults, and they govern signing configuration, code shrinking and obfuscation via ProGuard or R8, debuggability, and application ID suffixes. Second, define product flavors as the what dimension. Flavors represent different versions of the app intended for different users or markets, such as free versus paid, demo versus full, or staging versus production API endpoints. Third, explain the combinatorial outcome. Gradle creates a build variant for every pairing of build type and product flavor. If you have two build types, debug and release, and two flavors, free and paid, Gradle generates four variants: debugFree, releaseFree, debugPaid, and releasePaid. Fourth, note that build types and flavors can each have their own source sets and dependency scopes, which allows variant-specific code, resources, and manifest entries without forking the entire project.

COMMON WRONG ANSWERS: A major red flag is conflating the two concepts. Candidates sometimes say flavors are just another name for build types, or they create separate flavors for debug and release instead of using build types. Another mistake is claiming that flavors control build optimization settings like minification or signing, which actually belong to build types. Some candidates also forget that variants are the cross product and instead think flavors override build types, leading to incorrect assumptions about how many APKs are produced.

LIKELY FOLLOW-UPS: An interviewer might ask how you would configure a custom build type with its own signing certificate, or how to use flavor dimensions to create more than one axis of flavors, such as tier free versus paid combined with region us versus global. They may also ask about variant-aware dependency management, how to share code between specific variants, or the performance implications of having dozens of variants in a large monorepo.

ONE CONCRETE EXAMPLE: Imagine a news application with a free tier supported by ads and a paid tier without ads, alongside a requirement to hit staging and production backends. You should use two product flavors, free and paid, to swap the ad module and the subscription check logic. You should use two build types, debug and release, to enable logging and a debug certificate in debug while enabling R8 shrinking and the release keystore in release. The resulting variants are debugFree, releaseFree, debugPaid, and releasePaid. The free flavor pulls in the ads SDK dependency only for free variants, while the release build type ensures shrinking is applied to every release variant regardless of flavor. This keeps the concern of distribution identity separate from the concern of build mechanics.

Source: developer.android.com