Explain Jetpack Compose recomposition, its triggers, and optimizations.

WHAT THIS TESTS: Whether you understand the difference between Compose's declarative reactive model and imperative view systems. Interviewers want to see that you know recomposition is not a full layout pass but a targeted re-execution of composable functions, and that you can explain the optimization machinery that makes this feasible at 60fps. They also care if you understand the three phases of Compose composition layout and drawing and where recomposition sits in that pipeline.

A GOOD ANSWER COVERS: First, define recomposition as the phase where Compose re-executes composable functions whose inputs or state have changed. Second, state that the primary trigger is mutation of observable State objects during the composition phase or external events such as user input or network callbacks. Third, explain that Compose avoids re-rendering the entire UI by skipping composables whose parameters are stable and have not changed, leveraging the slot table and positional memoization to compare inputs cheaply. Fourth, mention that side effects must be isolated using APIs like LaunchedEffect or SideEffect because recompositions can occur frequently and must remain idempotent. Fifth, note that recomposition is optimistic and can be abandoned if state changes again before completion, which is why composables should not assume they will reach the layout or draw phase.

COMMON WRONG ANSWERS: Claiming that recomposition invalidates the entire screen or triggers a full measure and layout pass for every state change. Confusing recomposition with the layout or drawing phases of the Compose pipeline. Suggesting that manual diffing is required. Arguing that Compose uses a virtual DOM like React rather than a custom composer with slot tables and gap buffers. Saying that remember prevents recomposition rather than caching state across recompositions.

LIKELY FOLLOW-UPS: How does Compose determine parameter stability and why does marking a class as stable matter? What happens if you perform non-idempotent work inside a composable function? How would you debug excessive recompositions in a lazy list? When should you use derivedStateOf versus remember to reduce recomposition frequency? How do you force a recomposition manually and why is that usually a design smell?

ONE CONCRETE EXAMPLE: Imagine a Column containing a header Text, a Button, and a list of ten Cards driven by a list state. If the user clicks the button and increments an integer counter used only in the header, Compose recomposes the header composable but skips the Cards because their stable list input has not changed. If the counter were passed down as an unstable lambda capturing it inside each Card without proper keying or remember, the Cards might recompose unnecessarily, demonstrating why stability and proper state hoisting matter. You could fix this by hoisting the counter read into the header alone or by ensuring the Cards accept stable parameters.