What is the difference between viewModelScope and lifecycleScope?
This tests scope ownership across configuration changes. viewModelScope survives rotation because it lives in ViewModel, while lifecycleScope dies with UI; use former for logic and latter for UI tasks. Never launch data loads in lifecycleScope.
What's really being asked
This question evaluates whether you understand the ownership model of structured concurrency in the Android UI layer and can distinguish between a scope that survives configuration changes and one that is tightly coupled to a UI component's lifecycle. Interviewers want to see that you know where to launch coroutines so they do not leak, duplicate, or cancel at the wrong time. They also want to hear that you respect the single source of truth principle by keeping long-running data production out of UI-bound scopes.
The full answer
First, define viewModelScope as a CoroutineScope tied to a ViewModel that lives until onCleared is called, meaning it survives configuration changes like screen rotation. Second, define lifecycleScope as a CoroutineScope tied to a LifecycleOwner such as an Activity or Fragment that cancels when the lifecycle reaches DESTROYED. Third, explain the decision rule: use viewModelScope for business logic, data transformations, and repository calls that should continue across rotation; use lifecycleScope for UI-scoped work like animations, scrolling telemetry, or one-shot events that should not outlive the current window. Fourth, mention that lifecycleScope is safe for collecting flows in the UI when paired with repeatOnLifecycle to avoid wasting resources in the background. Finally, note that viewModelScope uses a SupervisorJob so child failures do not crash unrelated work.
The mistakes people make
A red flag is claiming the two scopes are interchangeable. Another mistake is saying viewModelScope is global or lives for the entire application; it is local to a single ViewModel instance. Candidates sometimes argue that lifecycleScope survives rotation because it is lifecycle-aware, which is backwards. Also, using lifecycleScope to trigger a network request and then wondering why the result never arrives after rotation is a classic anti-pattern that signals weak architecture intuition.
What usually comes next
The interviewer may ask how to collect a StateFlow in a Fragment without leaking the collector, which leads to viewLifecycleOwner.lifecycleScope and repeatOnLifecycle. They might ask what happens if you launch a coroutine in a Fragment's lifecycleScope during onCreateView and the user rotates the screen. They could also ask about custom scopes, such as when to use a manually managed SupervisorJob versus these built-in options.
A concrete example
Imagine a search screen with a ViewModel that debounces user input and queries a repository. You launch the debounce collector in viewModelScope so that typing continues smoothly across rotation. However, you use lifecycleScope to trigger a one-time snackbar message when the Fragment receives a one-shot event from the ViewModel via Channel or SharedFlow, because the snackbar should only show while the Fragment is visible and should disappear if the user leaves the screen.
Interview question
You launch a coroutine to load search results from a repository. Which approach ensures the load continues if the user rotates the device?
- a.Launch it in lifecycleScope because it is bound to the Activity and automatically restarts the coroutine after rotation.
- b.Launch it in viewModelScope because it is tied to the ViewModel and stays active across rotation until onCleared.Correct
- c.Launch it in lifecycleScope because that scope is lifecycle-aware and therefore survives configuration changes.
- d.Launch it in viewModelScope because it is a global application scope that never cancels.
Why? this is the answer
viewModelScope remains active until the ViewModel is cleared, so it survives configuration changes, whereas lifecycleScope cancels when the UI is destroyed. It is also not global; it is local to a single ViewModel instance.
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