Explain ViewModel, Repository, and Data Source in MVVM
This tests your understanding of separation of concerns. A great answer defines ViewModel (UI state), Repository (data abstraction), and Data Sources (implementation), then explains the unidirectional data flow.
What's really being asked
This question assesses your grasp of separation of concerns, a core principle of modern software architecture. The interviewer wants to see if you understand not just the definition of each MVVM component, but WHY they are separated. A senior-level answer focuses on how this structure creates a testable, maintainable, and lifecycle-aware application by enforcing a unidirectional data flow and establishing a single source of truth.
The full answer
First, define the distinct roles. The ViewModel is a lifecycle-aware UI state holder; it prepares and manages data for the UI and survives configuration changes. The Repository acts as the single source of truth for a specific type of data, abstracting its origin. Data Sources are the concrete implementations for fetching or saving data, like a Room DAO for local database access or a Retrofit service for network calls.
Second, explain the interaction flow. The UI (Activity/Fragment) observes data exposed by the ViewModel (usually via StateFlow or LiveData). The ViewModel never accesses data sources directly; instead, it requests data from the Repository. The Repository contains the logic to decide where to get the data from—for example, fetching from a local cache (Room) first, and only calling the remote data source (Retrofit) if the cache is empty or stale.
Third, highlight the benefits. This separation makes each layer independently testable. You can unit test a ViewModel with a fake Repository, and unit test a Repository with fake data sources. It also decouples the UI from the data layer, simplifying UI logic.
The mistakes people make
A major red flag is describing the ViewModel as directly calling Retrofit or a Room DAO. This completely misses the point of the Repository pattern, which is to abstract these implementation details. This makes the ViewModel brittle and hard to test.
Another common mistake is having the UI (Activity/Fragment) directly reference the Repository. This bypasses the ViewModel's critical role in state management and lifecycle handling, leading to data being lost on configuration changes and potential memory leaks.
Simply defining the components without explaining the data flow or the benefits of the separation indicates a junior-level understanding.
What usually comes next
"How would you handle a user action, like a button click to refresh data, in this architecture?" (UI calls a method on the ViewModel, which then calls a refresh method on the Repository).
"How do you handle network errors?" (The Repository should catch exceptions from the data source and wrap the result in a sealed class like Result<T>, which flows up to the ViewModel to be mapped into a specific UI error state).
"Where would you put business logic that combines data from two different repositories?" (In a UseCase/Interactor class that sits between the ViewModel and the Repositories).
A concrete example
For a user profile screen, the ProfileViewModel exposes a StateFlow<ProfileUiState>. On initialization, it calls userRepository.getProfile(userId). The UserRepository first checks its local data source, UserDao (Room), for the profile. If the data is stale (e.g., cached more than 15 minutes ago), it calls the remote data source, UserApiService (Retrofit), to fetch a fresh profile. It then saves the new data back into Room and returns the updated profile. This data flows back to the ViewModel, which updates its UI state, causing the UI to automatically re-render with the new information.
Interview question
In an MVVM architecture, when a ViewModel needs to load user data, which component should it directly request the data from?
- a.The Remote Data Source, like a Retrofit service, to fetch fresh data.
- b.The Repository, which manages and abstracts the origin of the data.Correct
- c.The UI Controller, such as an Activity or Fragment, which holds the context.
- d.The Local Data Source, like a Room DAO, to check for cached data first.
Why? this is the answer
The ViewModel should only communicate with the Repository. The Repository's role is to abstract data sources, deciding whether to fetch from a local cache or a remote network, and provide a clean API for the ViewModel.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
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