Jetpack Compose
Jetpack Compose Interview Guide
Compose interviews test whether you understand state ownership and effects, not whether you remember every annotation.
Short answer
What matters most
A senior Jetpack Compose interview answer should begin with state ownership and unidirectional data flow. Explain what state belongs in the composable, screen model, saved state or durable data layer. Recomposition is normal; expensive or incorrect work during recomposition is the problem. Side-effect APIs connect composition to work with a lifetime, and their keys define when that work restarts. Stability affects skip behavior but should be measured before it is optimized. Cover lifecycle-aware collection, derived state, list identity, process death, testing and interoperability with Views. The strongest answer links a Compose API to the invariant it protects and explains what happens when navigation, configuration or asynchronous work changes underneath the screen.
State and identity
Describe the source of truth, the event path and the lifetime of remembered state. Use stable keys for items whose identity survives position changes.
- Local presentation state
- Hoisted screen state
- Saved state after process death
- Durable repository data
- Derived values
- Stable list identity
Effects are lifecycle contracts
LaunchedEffect, DisposableEffect and rememberCoroutineScope serve different ownership needs. Explain what starts the work, what restarts it and what cleans it up.
Network calls should not accidentally repeat because a key is unstable. Durable user intent should not disappear merely because composition ended.
Performance without folklore
Measure recomposition, layout and rendering before adding annotations. Keep models stable where it naturally improves reasoning, but do not trade correctness for theoretical skipping.
Discuss baseline profiles, image work, lazy lists and tracing as parts of a complete performance answer.
