What the interviewer is testing

This question sounds like it's about Compose state APIs, but the interviewer is really checking whether you understand the relationship between state and UI.

A strong answer explains that the screen is a description of its current state. When that state changes, the UI may need to describe something different, and Compose uses observable state to connect those changes to recomposition.

If you jump straight to remember, mutableStateOf, or StateFlow, you're talking about storage and lifetime before explaining what state actually is.

❌ Common mistake

If they ask you to elaborate

Imagine the order screen from the previous questions.

At different moments it may need to show:

Loading
Order #42
Unable to load order

Those are not three different screens. They're three possible states of the same screen.

A composable can describe the UI directly from whichever state is current:

@Composable
fun OrderScreen(state: OrderUiState) {
    when (state) {
        OrderUiState.Loading -> LoadingContent()
        is OrderUiState.Content -> OrderContent(state.order)
        is OrderUiState.Error -> ErrorContent(state.message)
    }
}

The important part isn't the when. It's that the composable doesn't need instructions like "hide the spinner, show the content, clear the error."

It receives the current truth and describes the UI for that truth.

When the state changes from Loading to Content, Compose can run the UI that depends on that value again and update the existing Composition. That's the connection between state and the recomposition model from CMP-003.

Once that relationship is clear, the next question becomes about lifetime: if some state belongs to the UI, how do you keep it around when composables execute again or the screen is recreated?

Production thinking

State becomes much more important when a production screen can represent several conditions at once.

Imagine checkout with loading, payment availability, validation errors, a selected delivery option, and a network failure. If those values are scattered across unrelated mutable variables, it's easy for the UI to describe combinations that should never exist.

The goal isn't to make everything "Compose state." The goal is to make the current UI truth explicit so the screen can be reasoned about from its inputs.

That usually means giving a composable the state it needs, keeping that state coherent, and letting the UI derive what it displays from those values rather than manually coordinating a chain of UI mutations.

Where that state should live and who should own it are separate decisions. Those come next when you talk about state lifetime, hoisting, and screen-level state holders.

Follow-up questions

What separates a senior answer

Key takeaways

Learn more