Explain the difference between launch and async in Kotlin Coroutines
This tests scope behavior and side effects versus results. A strong answer says launch returns a Job for side effects, async returns a Deferred for results, and both are scope children. A red flag is using async for all tasks or ignoring exception handling.
What's really being asked
The interviewer wants to know if you understand structured concurrency and the semantic difference between fire-and-forget and result-bearing coroutine builders. This is not about memorizing API signatures; it is about knowing when to spawn a side effect versus when to compute a value asynchronously and how scope parent-child relationships govern lifecycle and error propagation.
The full answer
First, state that launch returns a Job and is used for side effects where the caller does not need a result back. Second, state that async returns a Deferred, which is a subtype of Job, and that you call await on it to receive the computed value. Third, emphasize that both are children of the CoroutineScope they are called on, meaning the scope cannot finish until they finish, and cancellation of the scope cancels them. Fourth, mention that structured concurrency rules apply to both: they inherit context, should not have their parent Job overridden, and their failures can propagate to the parent depending on whether the parent is a regular Job or a SupervisorJob.
The mistakes people make
A red flag is saying async is just a faster or better version of launch. Another red flag is claiming that async does not participate in structured concurrency or that you can pass a custom Job into its context without breaking the parent-child relationship. Candidates also stumble by saying exceptions in async always crash the app; in reality, unhandled exceptions in async propagate through structured concurrency similarly to launch when you await, but the timing differs. Confusing the two often reveals a lack of production debugging experience.
What usually comes next
The interviewer may ask what happens if you call await on a Deferred that was cancelled, or how exceptions propagate when multiple async calls run inside a supervisor scope. They might also ask why you should prefer coroutineScope builder with async for parallel decomposition instead of using GlobalScope, or how to handle the case where one async failure should not cancel its siblings.
A concrete example
Imagine a screen that needs to load a user profile and a settings object simultaneously. You launch a coroutineScope block and inside it call val user = async { repository.fetchUser() } and val settings = async { repository.fetchSettings() }. Then you await both. If the scope is tied to a ViewModel lifecycle, both fetches cancel automatically when the ViewModel clears. If you had used launch for both, you would have no clean way to return the fetched objects to the caller.
Interview question
You need to fetch two pieces of data in parallel inside a ViewModel and return both results to the caller. Which choice best follows structured concurrency?
- a.Use async for both calls and await each Deferred before returningCorrect
- b.Use launch for both calls and assign the results to global variables
- c.Use async with a custom Job to prevent cancellation from the ViewModel scope
- d.Use launch because async coroutines are not children of the calling scope
Why? this is the answer
async returns a Deferred that lets you retrieve computed values with await, which is exactly what you need when results must be returned, whereas launch is fire-and-forget. Option C is tempting but wrong because injecting a custom Job breaks the parent-child relationship required by structured concurrency.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
- #kotlin
- #coroutines
- #structured-concurrency
- #android
- #concurrency
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 kotlin — each one lists the topics its interview covers.
See open roles