What is remember in Compose and how do you use mutableStateOf?

This tests state survival across recompositions. Good answers say remember caches values across recompositions, pairs with mutableStateOf for observable state, and shows a counter. A red flag is mutableStateOf without remember, state resets per recomposition.
What's really being asked
This question checks whether you understand the Compose composition lifecycle and the distinction between ephemeral local variables and state that survives recomposition. Interviewers want to know if you can explain why plain vals inside a composable are recreated on every recomposition, and how remember provides a slot in the composition tree to persist a value across recompositions without leaking it across the entire app like a ViewModel might.
The full answer
First, define remember as a composable function that stores a single object in the composition and returns it on subsequent recompositions. Second, explain that remember alone does not make state observable; you pair it with mutableStateOf to create a state holder that both survives recomposition and triggers recomposition when the value changes. Third, mention that the remembered value is scoped to the composable's position in the tree and is forgotten when the composable leaves the composition. Fourth, provide a concise code snippet showing the pattern val count by remember { mutableStateOf(0) } and a button that increments it.
The mistakes people make
A major red flag is claiming that mutableStateOf alone is sufficient; without remember, the state object is recreated every recomposition and all user changes are lost. Another mistake is confusing remember with rememberSaveable; candidates should not claim remember survives configuration changes or process death. A third error is suggesting global variables or ViewModel usage for purely local UI state like a text field's transient input or a dropdown's expanded flag, which shows poor scoping judgment.
What usually comes next
The interviewer may ask when to use rememberSaveable instead of remember, which tests whether you know that rememberSaveable persists across configuration changes using the saved instance state mechanism. They might ask about the performance implications of remember versus derivedStateOf, or how to hoist state from a composable to a parent or ViewModel. You should also be ready to explain why remember accepts a key or keys parameter and what happens when those keys change.
A concrete example
A clean example is a simple counter inside a greeting card. Inside a composable function named CounterCard, you write var count by remember { mutableStateOf(0) }. Then you display the count in a Text composable and provide a Button whose onClick lambda increments count. Because remember caches the MutableState instance, clicking the button updates the observed value, Compose invalidates the relevant scope, and the UI recomposes to show the new number. If you removed remember and only wrote var count = mutableStateOf(0), the count would reset to zero on every recomposition because the variable would be reinitialized each time the function ran.
Interview question
Why is remember typically paired with mutableStateOf for local composable state?
- a.remember triggers recomposition automatically, while mutableStateOf stores the value in the composition tree
- b.remember makes state observable to the composition, while mutableStateOf caches the initial value across recompositions
- c.remember persists the state across recompositions, while mutableStateOf makes it observable and triggers recomposition when changedCorrect
- d.remember persists state across configuration changes, while mutableStateOf initializes the state holder
Why? this is the answer
remember caches the state object across recompositions, and mutableStateOf wraps that value so Compose can observe changes and recompose. Option D is tempting but wrong because remember does not survive configuration changes; rememberSaveable does.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #jetpack-compose
- #state-management
- #kotlin
- #remember
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