What is recomposition and what triggers it?
Understand how Compose knows what UI may need to run again when state changes.
What the interviewer is testing
This question isn't really about knowing that "state changes trigger recomposition."
The interviewer wants to know whether you understand how Compose connects state to the UI that depends on it.
If a composable reads observable state, that read creates a dependency Compose can track. When the value changes, Compose knows where the existing Composition may now be out of date and can schedule the relevant work again.
A strong answer explains that relationship before talking about performance, stability, or runtime internals.
❌ Common mistake
If they ask you to elaborate
Imagine the same order screen from the previous question.
The screen shows the order itself and a cart badge:
@Composable
fun OrderScreen(
order: OrderUiModel,
cartCount: Int,
) {
OrderDetails(order)
CartBadge(cartCount)
}Now the user adds another item to the cart.
The order has not changed. The cart count has.
If the observable state behind cartCount changes, Compose knows that the UI reading that value may now describe something different. That work can be scheduled again without treating the entire screen as brand new.
That's the useful way to reason about recomposition:
- State is read by UI.
- That read creates a dependency Compose can track.
- When the value changes, the dependent UI may need to run again.
A composable can also be called again because its parent recomposes and passes different parameters. So "recomposition follows state reads" is a useful shortcut, but the deeper idea is dependency tracking.
That leads naturally to the next question: if state drives these UI updates, what exactly counts as state in Compose, and how does it drive the UI?
Production thinking
This starts to matter when a screen has several independent pieces of state.
An order screen might be refreshing data while a cart badge changes, a dialog opens, and an error banner appears. If every part of the screen depends on one large blob of state, it becomes harder to see what actually depends on what.
Good Compose code keeps those dependencies clear. Give each piece of UI the state it needs, keep business logic and I/O outside composable bodies, and make work that may run again cheap.
I wouldn't start by trying to "stop recomposition." First make the state model and ownership clear. If there is still a measured performance problem, then stability and recomposition tooling become useful follow-ups.