Explain Structured Concurrency in Kotlin Coroutines

What's really being asked

This question checks if you understand the structural guarantees of Kotlin coroutines. Interviewers want to see that you know coroutines are not free-floating threads but form a strict parent-child hierarchy through CoroutineScope and Job. They are looking for awareness of lifecycle management, cancellation propagation, and how structured concurrency eliminates the need to manually track every background task. At the senior level, they also expect you to contrast this with GlobalScope and raw thread spawning.

The full answer

First, define structured concurrency as the principle that every coroutine must be launched within a CoroutineScope that bounds its lifetime. Second, explain the parent-child relationship: when a coroutine builder like launch or async is called on a scope, the new coroutine becomes a child Job of the scope's Job. The parent waits for all children to complete before it completes itself. Third, describe cancellation propagation: if the parent scope is cancelled, the cancellation signal flows recursively to every child and grandchild, causing them to throw CancellationException and clean up. Fourth, connect this to resource leaks: because no coroutine can outlive its scope, launching work inside a ViewModelScope or lifecycleScope guarantees that rotating a screen or navigating away automatically cancels ongoing network calls or computations, preventing memory leaks and wasted CPU.

The mistakes people make

A red flag is describing coroutines as fire-and-forget background threads that run independently. Another mistake is saying you must manually keep references to every Job and cancel them one by one. Some candidates confuse structured concurrency with the unrelated async-await pattern or believe only the immediate child is cancelled while nested grandchildren survive. Failing to mention SupervisorJob as the exception to parent failure propagation is also a gap at the senior level. Claiming that GlobalScope is acceptable for production code is another serious warning sign.

What usually comes next

The interviewer may ask how SupervisorJob differs from a regular Job, when you would use GlobalScope and why it is discouraged, or how exception handling differs between launch and async in a structured hierarchy. They might also ask how to bridge structured concurrency with callback-based APIs, how coroutineScope and supervisorScope builders enforce structure in suspend functions, or what happens to an async deferred value when its parent is cancelled.

A concrete example

Imagine a ViewModel that fetches a user profile and then loads avatar thumbnails inside the same viewModelScope. If the user closes the screen, the viewModelScope is cancelled. Because of structured concurrency, the profile request and every thumbnail sub-job are cancelled automatically. Without structured concurrency, those network calls could complete, attempt to update a destroyed Fragment, and leak the UI controller or waste bandwidth.