How does a ViewModel survive configuration changes?

What's really being asked

This question probes your knowledge of Android's component lifecycles and modern state management patterns. The interviewer wants to see that you understand why ViewModel exists and how it solves the specific problem of retaining UI state during configuration changes, where the Activity instance is destroyed but the user's task is not finished. It separates candidates who only know the basic Activity lifecycle from those who understand modern architecture.

The full answer

A strong answer walks through the mechanism in four steps. First, ViewModels are managed by a ViewModelProvider. Second, this provider retrieves the ViewModel from a ViewModelStore, which is owned by a ViewModelStoreOwner (like an Activity or Fragment). Third, this ViewModelStore is the key component; it is not destroyed during configuration changes. When the Activity is recreated, the new Activity instance connects to the same ViewModelStore and receives the existing ViewModel instance. Finally, clarify the scope: the ViewModel lives until its associated scope is permanently destroyed (e.g., the Activity finishes via finish() or the user navigates away), at which point its onCleared() method is called.

The mistakes people make

A major red flag is conflating ViewModel with onSaveInstanceState. ViewModels do NOT survive process death; they are in-memory objects. Stating they do is a critical error. Another mistake is being vague, saying it "just survives" without mentioning the ViewModelStore and the scoping mechanism. A junior answer might also incorrectly tie the ViewModel's lifecycle to the Application context, which is too broad a scope and generally an anti-pattern for UI-related data.

What usually comes next

"How would you handle state that does need to survive process death?" (Answer: SavedStateHandle injected into the ViewModel). "What's the difference between a ViewModel scoped to an Activity versus a Fragment?" (Answer: Scope and data sharing; a Fragment ViewModel is destroyed with the Fragment, while multiple fragments can share an Activity-scoped ViewModel). "When exactly is onCleared() called?" (Answer: When the ViewModelStoreOwner is permanently destroyed, e.g., Activity.finish()).

A concrete example

Imagine a user is filling out a complex registration form. They rotate their phone. The Activity instance is destroyed and a new one is created. Without a ViewModel, all typed data would be lost. With a ViewModel, the form data (e.g., MutableStateFlow<String>) is held in the ViewModel instance. The new Activity instance gets the same ViewModel from the ViewModelStore and re-populates its UI from the ViewModel's state. This works for large, complex data (like a 2MB user-selected bitmap) that cannot be put in onSaveInstanceState's Bundle, which is limited to about 1MB on recent devices.