What is a ViewModel and what lifecycle problem does it solve?
Tests config-change survival: ViewModel outlives Activity recreation so state survives rotation. Strong answer notes it holds non-serializable data and separates concerns, but does not survive process death.
What's really being asked
Whether you understand the difference between an Activity instance lifecycle and the user's conceptual screen session, and whether you know where to place non-UI logic so it survives configuration changes without leaking memory.
A GOOD ANSWER COVERS four things in order. First, define the problem: when the device rotates, the system destroys and recreates the Activity or Fragment by default, so any instance variables or async results held directly in the UI controller are lost. Second, explain ViewModel's scope: it is retained as long as the ViewModelStoreOwner (usually an Activity or Fragment) is alive in the back stack, which means it survives configuration changes but is cleared when the owner is finished for good, such as on back press. Third, describe what belongs inside: UI-related data that is expensive to reload, non-serializable objects like LiveData or Flow subscribers, and business logic that should not live in the Activity. Fourth, draw the boundary with onSaveInstanceState: ViewModel does not survive process death, so transient UI state still needs to be saved via onSaveInstanceState or SavedStateHandle for system-initiated destruction.
COMMON WRONG ANSWERS include saying ViewModel prevents all memory leaks automatically, claiming it replaces onSaveInstanceState entirely, or confusing it with the deprecated retained fragment pattern. Another red flag is stating that ViewModel survives process death without mentioning SavedStateHandle.
LIKELY FOLLOW-UPS include how ViewModel is actually retained under the hood via ViewModelStore and a factory, how to share a ViewModel between fragments using the Activity scope, and when to use SavedStateHandle versus plain ViewModel fields.
A concrete example
A user opens a news app and loads a list of fifty articles. Without a ViewModel, rotation triggers a new network request because the Activity is recreated and the list variable is null. With a ViewModel, the articles list lives in the ViewModel, survives rotation, and the new Activity instance simply re-observes the same data without another request.
Interview question
Which statement best describes the division of responsibility between ViewModel and onSaveInstanceState?
- a.onSaveInstanceState should hold non-serializable objects and expensive-to-reload data
- b.ViewModel survives process death and system-initiated destruction without help
- c.ViewModel handles config-change survival while onSaveInstanceState handles system-initiated destructionCorrect
- d.ViewModel replaces onSaveInstanceState so only one persistence mechanism is needed
Why? this is the answer
ViewModel survives configuration changes like rotation but is destroyed during process death, so transient UI state must still be saved with onSaveInstanceState or SavedStateHandle. Option D is tempting but wrong because ViewModel does not replace onSaveInstanceState entirely.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #jetpack
- #viewmodel
- #lifecycle
- #configuration-changes
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