Explain launch vs. async in Kotlin Coroutines
Tests your grasp of structured concurrency, return values, and exceptions. launch is for fire-and-forget tasks (returns Job), while async is for tasks that produce a result (returns Deferred).
What's really being asked
This question tests your understanding of structured concurrency and the specific roles of different coroutine builders. The interviewer wants to know if you can distinguish between work that has side effects ("fire-and-forget") and work that produces a result. They are also probing your knowledge of how return types (Job vs. Deferred) and exception handling differ. For a senior role, this includes the implications for parallel work and error propagation.
The full answer
A solid answer covers four key points. First, the return type: launch returns a Job, representing a handle to the coroutine, but it carries no result. async returns a Deferred<T>, which is a Job that also promises a future result of type T. Second, the primary use case: launch is for operations where you don't need a direct result, like updating a UI, logging, or triggering a one-way network call. async is for performing a computation in parallel and using its result later. Third, retrieving the result: with async, you must call .await() on the Deferred object to get the result, which suspends the calling coroutine until the value is ready. There is no equivalent for launch. Fourth, exception handling: an uncaught exception in launch propagates up the Job hierarchy and can crash the parent coroutine immediately. An exception in async is stored within the Deferred and is only re-thrown when .await() is called.
The mistakes people make
A major red flag is describing async without mentioning .await(). This shows a fundamental misunderstanding of how to consume the result. Another common mistake is using async for fire-and-forget tasks; this creates a Deferred object that is never awaited, which can silently swallow exceptions. Simply stating "async is for parallel, launch is for sequential" is an oversimplification; both enable concurrency. The key differentiator is the need for a return value. Finally, forgetting that Deferred is a sub-type of Job indicates a surface-level understanding.
What usually comes next
How would you run multiple async operations in parallel and wait for all of them to complete? (Answer: awaitAll(deferred1, deferred2)). What happens if you use async but never call .await()? (Answer: The work runs, but the result is lost, and more importantly, any exception is silently dropped). How does exception handling change inside a supervisorScope? (Answer: A failure in one child does not cancel other children or the supervisor itself).
A concrete example
Use launch for a simple UI update or logging event. For example: viewModelScope.launch { analytics.logEvent("screen_view") }. Use async when you need to fetch two independent pieces of data from a network and combine them. For example: val userDeferred = async { api.fetchUser() } and val profileDeferred = async { api.fetchUserProfile() }. You would then use val user = userDeferred.await() and val profile = profileDeferred.await() to get the results. This is far more efficient than fetching them sequentially.
Interview question
For a Kotlin Coroutine task that updates a UI element and does not require a return value, which builder is most appropriate?
- a.runBlocking
- b.withContext
- c.async
- d.launchCorrect
Why? this is the answer
The correct choice is launch because it is designed for 'fire-and-forget' operations, such as UI updates, where a direct result is not needed and it returns a Job. Using async for such a task would create a Deferred object whose result is never awaited, potentially leading to silently swallowed exceptions.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
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