Explain Recomposition in Jetpack Compose
This tests your core understanding of Compose's declarative model. Explain that recomposition is re-running composables when state they read changes. Mention that Compose optimizes by only recomposing the nearest scope and skipping composables with stable…
What's really being asked
This question probes your fundamental understanding of the declarative UI paradigm in Compose. The interviewer wants to see if you grasp how Compose efficiently updates the UI, which is a stark contrast to the imperative View system. It's a test of your knowledge of state management, the Compose compiler's role, and performance optimization principles like skipping.
The full answer
A strong answer explains four key points in order. First, define recomposition as the process of calling your composable functions again when their inputs change. Second, specify that the trigger is a change to a State<T> object that was read during a previous composition. Third, explain the primary optimization is "smart recomposition" or "scoped recomposition," where Compose only re-runs the specific composables that read the changed state, not the entire UI tree. Fourth, describe "skipping," where the runtime avoids re-running a composable altogether if its parameters are stable and have not changed since the last composition, even if its parent recomposes.
The mistakes people make
A major red flag is describing recomposition as a full UI redraw, similar to invalidate() in the old View system. Another common mistake is being vague about the trigger, for example, saying "when data changes" instead of specifically "when a State object that was read is updated." Candidates also often fail to mention "skipping" as a distinct and critical optimization. Finally, confusing recomposition (re-running the function) with the subsequent measure, layout, and draw phases shows a shallow understanding.
What usually comes next
Expect questions like: "What makes a type 'stable' versus 'unstable' and why does it matter for skipping?" or "How would you debug unnecessary or excessive recompositions?" (Answer: Use the Layout Inspector in Android Studio). They might also ask about the role of remember in preserving state across recompositions or how to handle side effects using LaunchedEffect.
A concrete example
Imagine a ProfileScreen composable holding a name state variable. It contains two children: UserName(name = name) and a static ProfileHeader(title = "User Details"). When the name state changes, ProfileScreen and UserName will recompose because they read the state. However, ProfileHeader will be skipped by the Compose runtime because its input ("User Details") is stable and has not changed, saving rendering work.
Interview question
When a state object is updated, how does Jetpack Compose efficiently perform recomposition?
- a.It re-runs the entire composable tree from the root to ensure UI consistency.
- b.It directly modifies the underlying UI widgets, bypassing the need to re-run any composable functions.
- c.It re-runs only the composables that read the changed state, potentially skipping children with unchanged, stable inputs.Correct
- d.It only re-runs the composable where the state was declared, but always re-runs all of its children.
Why? this is the answer
Compose's efficiency comes from smart, scoped recomposition. It re-runs only the functions that read the changed state and can skip re-running child composables if their inputs are stable and unchanged. Redrawing the entire tree is a common misconception from older UI toolkits.
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