What is a Jetpack ViewModel and the problem it solves?

WHAT THIS TESTS: This question tests your understanding of the Android Activity/Fragment lifecycle, specifically the destructive and re-creative nature of configuration changes like screen rotation. The interviewer wants to confirm you know why state is lost and how ViewModel is the architecturally correct way to manage UI-related data across these events, separating it from the transient UI controller.

A GOOD ANSWER COVERS: First, explain the core problem: configuration changes cause Android to destroy and recreate the Activity/Fragment, discarding any in-memory UI state. Second, introduce ViewModel as a class designed to store and manage UI-related data, whose key feature is that it survives these configuration changes. When the Activity is recreated, it receives the same ViewModel instance. Third, clarify that a ViewModel is scoped to a lifecycle owner (Activity/Fragment) and lives until that owner is permanently destroyed, not just reconfigured. Finally, contrast its purpose with onSaveInstanceState: ViewModel is for complex, in-memory data (e.g., network results), while onSaveInstanceState is for small amounts of simple state needed to survive system-initiated process death.

COMMON WRONG ANSWERS: A major red flag is confusing ViewModel's purpose with onSaveInstanceState. Saying a ViewModel survives process death on its own is incorrect; that requires the Saved State module. Another weak answer is simply saying "it saves data" without explaining the lifecycle context or the problem of configuration changes. Finally, describing it as a general data store is wrong; it's specifically for UI-related data and should not hold references to Views or Activities, which would cause memory leaks.

LIKELY FOLLOW-UPS: Expect questions like, "How would you share a ViewModel between two Fragments?" (Answer: Scope it to the parent Activity). Or, "When is a ViewModel's onCleared() method called?" (Answer: When the associated Activity is finished or the Fragment is permanently detached). A tougher one is, "So how do you handle process death with ViewModel?" (Answer: You use the Saved State module for ViewModel, which integrates with the onSaveInstanceState bundle).

ONE CONCRETE EXAMPLE: Imagine a screen fetching 500 user profiles from a network. Without a ViewModel, rotating the screen would destroy the Activity and its list of 500 profiles, forcing a new, expensive network call. With a ViewModel, the list is held in the ViewModel instance. The new Activity instance simply reconnects to the existing ViewModel and immediately displays the data, saving network, battery, and time.

Source: developer.android.com