Android & Jetpack Compose Interview Questions
Android interviews increasingly focus on Jetpack Compose fundamentals alongside classic platform knowledge: lifecycle, state management, coroutines, and architecture. Interviewers are less interested in whether you can recite an API signature and more interested in whether you understand why Compose behaves the way it does — why recomposition happens, why state hoisting matters, why a poorly scoped coroutine leaks. This topic collects the most commonly asked questions across those areas with answers precise enough to use directly, along with the reasoning that should accompany them in an actual interview conversation.
Cricket analogy: A talent scout doesn't just ask if a batter knows the rules of LBW; they probe whether the batter understands why they shouldered arms to a ball just outside off stump, the reasoning behind the shot selection.
Composition and Recomposition
A very common opener is: 'What triggers recomposition in Compose?' The correct answer is that recomposition is triggered when a State object read during a previous composition changes value — Compose's snapshot system tracks exactly which State reads happened inside which composable scope, and only re-executes the smallest scopes that actually read the changed state, not the whole tree. A strong follow-up answer distinguishes this from a full re-render: Compose is not like relayout-on-every-frame; it is fine-grained and skips composables whose inputs are unchanged (skippability), provided their parameters are stable.
Cricket analogy: Recomposition is like a third umpire review that only re-examines the exact delivery in question, not the entire innings, because the snapshot system knows precisely which frame changed.
Architecture and State Ownership
Another staple is: 'What is state hoisting and why use it?' State hoisting means moving state up to a common ancestor (often a ViewModel) and passing it down as an immutable value plus an event callback, turning a composable into a stateless function of its inputs. This makes composables reusable, testable in isolation, and easier to reason about because a single source of truth exists instead of duplicated, possibly-diverging copies of the same state. Interviewers often pair this with 'explain unidirectional data flow' — the pattern where state flows down and events flow up, which is what state hoisting enables at scale across a whole screen or app.
Cricket analogy: State hoisting is like a captain who doesn't let each fielder independently decide the field placement; the captain (the ViewModel) sets the plan and fielders just execute and signal back if something changes.
// Common interview task: convert this stateful composable to be stateless via hoisting.
// Before: state is trapped inside the composable, hard to test or reuse.
@Composable
fun Counter() {
var count by remember { mutableStateOf(0) }
Button(onClick = { count++ }) {
Text("Count: $count")
}
}
// After: hoisted — caller owns the state, composable is a pure function of its params.
@Composable
fun Counter(count: Int, onIncrement: () -> Unit) {
Button(onClick = onIncrement) {
Text("Count: $count")
}
}
@Composable
fun CounterScreen(viewModel: CounterViewModel = viewModel()) {
val count by viewModel.count.collectAsStateWithLifecycle()
Counter(count = count, onIncrement = viewModel::increment)
}A strong signal in interviews is explaining trade-offs, not just definitions. For 'remember vs rememberSaveable,' the sharp answer isn't just 'one survives rotation' — it's that remember only survives recomposition within the same instance, rememberSaveable additionally survives configuration change and process death by writing into the saved-instance-state Bundle, and therefore has stricter type constraints (Bundle-compatible or a custom Saver).
Avoid answering architecture questions with only buzzwords ('we use MVVM and Clean Architecture'). Interviewers frequently probe deeper — e.g. 'where exactly does business logic live, in the ViewModel or a UseCase?' or 'how does your Repository decide between cache and network?' Be ready to justify layering decisions with concrete reasoning, not just name the pattern.
Beyond composition and architecture, expect questions across the stack: 'Why does LazyColumn need a key on each item?' (to preserve item identity and scroll/animation state across reordering and to enable smarter diffing); 'What's the difference between StateFlow and SharedFlow?' (StateFlow always has a current value and conflates emissions, SharedFlow is configurable and can replay zero or more values without requiring an initial one); 'What does derivedStateOf do?' (recomputes a value from other State reads only when those inputs actually change, preventing unnecessary recomposition of dependents on every unrelated recomposition).
Cricket analogy: Giving LazyColumn a key per row is like a scorecard tracking each batter by name rather than by batting position, so a retired-hurt substitution doesn't scramble everyone else's recorded stats.
- Recomposition is triggered by State reads changing value, and Compose skips unaffected scopes when inputs are stable.
- State hoisting turns composables into pure functions of state + event callbacks, enabling reuse and testability.
- rememberSaveable differs from remember by surviving configuration change and process death via the saved-instance-state Bundle.
- Be ready to justify architecture choices concretely (where business logic lives, cache-vs-network decisions), not just name-drop patterns.
- Know the purpose of common APIs precisely: LazyColumn keys, StateFlow vs SharedFlow, derivedStateOf.
- Interviewers reward reasoning about trade-offs over memorized definitions.
Practice what you learned
1. What precisely triggers a recomposition in Jetpack Compose?
2. What is the main benefit of state hoisting?
3. How does rememberSaveable differ from remember?
4. Why is providing a stable key to each LazyColumn item considered important in interviews?
5. What is a key distinction between StateFlow and SharedFlow that often comes up in interviews?
Was this page helpful?
You May Also Like
Common Android & Compose Pitfalls
The recurring mistakes developers make with recomposition, state, coroutines, and lists in Jetpack Compose, and the concrete fixes for each.
Android & Jetpack Compose Quick Reference
A condensed reference of the core Jetpack Compose APIs, state tools, and architecture building blocks for fast lookup while coding.
State Hoisting
Learn the Compose pattern of moving state up to a caller so composables become stateless, reusable, and easier to test.
MVVM in Android
How the Model-View-ViewModel pattern maps onto Compose apps, separating UI state, business logic, and data sources into clean, testable layers.