Explain Gradle Build Types vs. Product Flavors
Tests your grasp of Gradle's build matrix. A great answer defines build types for lifecycle (debug/release) and product flavors for user-facing versions (free/paid), then explains how they combine into variants.
What's really being asked
This question tests your understanding of the Gradle build matrix and its separation of concerns. The interviewer wants to see if you can distinguish between configurations for the build process itself (the 'how') versus configurations for the final product's features and identity (the 'what'). It's a test of practical, large-scale project architecture, not just rote definitions.
The full answer
A strong answer explains the concepts in a specific order. First, define Build Types as configurations for the packaging and signing process, tied to the development lifecycle. The two defaults are debug (for development, with debug symbols, no minification) and release (for production, with ProGuard/R8 enabled, signed with a production key). Second, define Product Flavors as different versions of your app that you release to users, such as free and paid. Flavors can change resources (icons, strings), source code, and critically, the applicationId. Third, explain that a Build Variant is the Cartesian product of a build type and a product flavor. With two build types and two flavors, you get four variants: freeDebug, freeRelease, paidDebug, and paidRelease. Finally, for bonus points, mention flavorDimensions as the tool for managing multiple, orthogonal sets of flavors (e.g., a 'tier' dimension for free/paid and a 'store' dimension for Google Play/Amazon).
The mistakes people make
The most common red flag is conflating the two. For example, suggesting a staging build type to change an API endpoint. While technically possible, this is poor practice. An API endpoint is a feature of the app, not a property of the build process. The correct approach is a staging product flavor. Another weak answer gives vague definitions like "they both change how the app is built" without mentioning specifics like signing keys, ProGuard, applicationId, or source sets. Failing to explain that variants are the combination of the two is also a sign of a junior-level understanding.
What usually comes next
Expect questions like: "How would you share code between some flavors but not others?" (Answer: Use source sets like src/paid/java). "What is a flavorDimension and when is it necessary?" (Answer: When you have multiple independent flavor groups, like [free, paid] and [google, amazon]). "How does this affect your dependency management?" (Answer: Using flavor-specific configurations like paidImplementation vs. implementation).
A concrete example
Consider a white-label app for two customers. You would create two product flavors: customerA and customerB. The customerA flavor would have its own applicationId ('com.app.customera'), theme colors, and a build config field for its API endpoint ('api.customera.com'). The customerB flavor would have its own unique values. You would still have the standard debug and release build types. This setup creates four build variants (customerADebug, customerARelease, etc.), allowing you to build a debug APK for customer A's QA team and a separate, production-signed release AAB for customer B's Play Store listing, all from a single codebase.
Interview question
Your app needs to connect to a different backend API for an internal 'staging' environment versus the public 'production' release. What is the standard Gradle approach for this?
- a.Create two product flavors, `staging` and `production`, and use build config fields for the API endpoints.Correct
- b.Use a `flavorDimension` to manage the `staging` and `production` environments.
- c.Create two build types, `staging` and `production`, and configure the API endpoint in each.
- d.Define a new build variant named `staging` and override the API endpoint in its source set.
Why? this is the answer
Product flavors define 'what' the app is (e.g., which backend it targets), while build types define 'how' it's built (e.g., debug vs. release). Using a build type for an API endpoint is a common but incorrect practice.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles