What is composition?
Understand what Compose keeps after your composable functions run.
What the interviewer is testing
This question isn't really about defining the word Composition.
The interviewer wants to know whether you understand why Compose can execute composable functions repeatedly without treating every execution as a completely new screen.
A strong answer explains that Compose remembers the existing UI first. The runtime details come later.
❌ Common mistake
If they ask you to elaborate
Imagine an order screen.
The user opens the screen and sees a loading indicator.
A few moments later, the order arrives.
Your composable function runs again, but Compose doesn't throw away everything it already knows about that screen. It already has a remembered UI to work from. It compares the new description with what already exists and updates what needs to change.
That's why it's useful to think about two different things:
- Your composable functions describe the UI.
- Composition is the UI Compose is currently maintaining.
The next question is naturally:
If Compose remembers the existing UI, how does it know which parts actually need to run again? That's where recomposition comes in.
Production thinking
The value of Composition becomes much clearer on large screens.
A production screen might switch between loading, content, errors, empty states, dialogs and refresh operations many times during its lifetime.
Compose doesn't recreate that screen from scratch every time one of those states changes. It keeps an existing UI and updates it as the application state evolves.
That's where Composition starts to matter in real applications. The more state a screen has, the more valuable that continuity becomes.