What the interviewer is testing

This sounds like a question about two Compose APIs, but the interviewer is really testing whether you understand state lifetime.

The interviewer isn't comparing APIs. They're looking for whether you think about how long a piece of UI state should exist before you choose an API.

A strong answer separates recomposition from recreation. They're different lifecycle boundaries, so state may need a different lifetime at each one.

❌ Common mistake

If they ask you to elaborate

Imagine a checkout screen.

The user is halfway through typing their delivery address.

If another part of the screen recomposes, should the address disappear?

Of course not.

While they are typing, other state on the screen may change and Compose may re-run the search field. Losing the text on every recomposition would make the UI unusable.

That's the lifetime remember handles:

@Composable
fun ProductSearch() {
    var query by remember { mutableStateOf("") }

    SearchField(
        value = query,
        onValueChange = { query = it },
    )
}

The composable can run again and query still belongs to the same place in the Composition.

Now change the boundary instead of the API.

The user rotates the device. The Activity is recreated, so the old Composition is gone. If that search text should still be there afterwards, the requirement is no longer just "survive recomposition."

If that UI state should come back after recreation, that's where rememberSaveable fits:

@Composable
fun ProductSearch() {
    var query by rememberSaveable { mutableStateOf("") }

    SearchField(
        value = query,
        onValueChange = { query = it },
    )
}

Same state. Different lifetime requirement.

The next question is different again: if multiple composables need the same state, should one composable own it at all?

Production thinking

Production screens rarely have one lifetime for every piece of UI state.

A checkout screen might have an expanded delivery section, a selected tab, temporary form input, and a confirmation dialog. Those values do not all need the same lifetime.

Not every piece of UI state needs the same lifetime. Some can disappear with the Composition, some should come back after recreation, and some shouldn't be owned by the composable at all.

In production, I would make the lifetime decision before choosing the API:

• Does the value only need to survive recomposition?
• Should the user get it back after the Activity is recreated?
• Is this actually screen or business state that belongs to another owner?

That last question is where state hoisting and screen-level state holders come in. remember and rememberSaveable solve UI state lifetime; they do not decide application architecture.

Follow-up questions

What separates a senior answer

Key takeaways

Learn more