Kotlin engineer interview questions

As asked

Explain structured concurrency in Kotlin coroutines. How does it change the way you launch background work in an Android or JVM service?

Sample answer outline

Structured concurrency means child coroutines are tied to an explicit parent scope, so cancellation, failure and lifetime are visible in the call structure. In Android this usually means using lifecycle-aware scopes such as viewModelScope rather than GlobalScope. In backend services it means request-scoped or application-scoped CoroutineScope objects with clear shutdown behaviour. A failed child should either cancel siblings or be isolated with SupervisorJob when that is intentional. Candidates trip up by launching fire-and-forget work that outlives the user action, leaks resources, or silently drops exceptions.

Expect these follow-ups

• When would you use supervisorScope instead of coroutineScope?
• How do Dispatchers.IO and Dispatchers.Default differ?
• What happens to child coroutines when a ViewModel is cleared?

As asked

Explain structured concurrency in Kotlin. If a coroutine inside a CoroutineScope throws an exception, what exactly happens to its sibling coroutines and the parent scope? How does CancellationException differ from other exceptions in this propagation model?

Sample answer outline

The answer should cover how a child failure cancels the parent scope and all sibling coroutines unless SupervisorScope or SupervisorJob is used. CancellationException is treated specially, it cancels but does not propagate as a failure to the parent. The candidate should distinguish between Job and SupervisorJob and know that launch and async handle exceptions differently.

Expect these follow-ups

• When would you use supervisorScope vs CoroutineScope?
• If async throws, when exactly does the exception surface?

As asked

What is the fundamental difference between a cold Flow and a hot Flow like StateFlow or SharedFlow in Kotlin? Give me a concrete scenario where using a cold Flow would silently cause a bug if you mistakenly used a SharedFlow instead, or vice versa.

Sample answer outline

Cold flows restart their producer for each collector, so a network call in a cold flow fires once per subscriber. SharedFlow has a configurable replay cache and does not restart the producer. A common bug is using a StateFlow for one-shot events: late subscribers get the last cached value and replay side effects like navigation. The answer should mention that SharedFlow with replay=0 is safer for events.

Expect these follow-ups

• How do you implement a one-time event stream safely using SharedFlow?
• What does the buffer operator do to a cold flow and how does it interact with backpressure?

As asked

You have an Android ViewModel that exposes a StateFlow. How do you collect it safely from a Fragment to avoid collecting while the Fragment is in the background? Compare repeatOnLifecycle, flowWithLifecycle, and launchWhenStarted and explain which one you prefer and why.

Sample answer outline

launchWhenStarted is deprecated because the coroutine is suspended but not cancelled, leaking resources. flowWithLifecycle is a Flow operator that wraps the source with lifecycle awareness. repeatOnLifecycle is the recommended approach: it cancels and restarts the collection block based on the lifecycle state, preventing background processing. The candidate should know to call it inside viewLifecycleOwner.lifecycleScope.launch.

Expect these follow-ups

• What happens if the screen rotates while a StateFlow is being collected?
• Why should you not use lifecycleScope.launch directly without repeatOnLifecycle?

As asked

In an Android app using Room, you declare a DAO function that returns Flow<List<Item>>. When does the query run, how does Room emit updates reactively, and what is the risk of collecting this Flow on the main thread?

Sample answer outline

Room wraps the query in a cold Flow that runs on Dispatchers.IO by default and re-emits whenever the underlying table changes. Collection on the main thread is safe because Room dispatches the query internally, but the candidate should note that heavy data transformation on the collector should be done with map {} and flowOn(Dispatchers.Default). They should also mention distinctUntilChanged() to avoid redundant recompositions.

Expect these follow-ups

• How does Room know when to re-emit after a table update?
• What happens if two tables are joined in the query and only one of them changes?

As asked

I ask candidates this frequently because I have seen it misused. Explain when you would reach for let vs run vs apply and what the semantic difference is between them. Give me a concrete case where using the wrong scope function introduces a subtle bug.

Sample answer outline

let transforms a value (returns lambda result, uses it), apply configures and returns the receiver, run is a combination (executes block with this, returns lambda result), also performs side effects and returns the receiver, with operates on a non-null receiver. A subtle bug: using apply on a nullable receiver without safe-call leads to NPE; using let where apply was intended returns Unit instead of the configured object, causing a type error or silent discard.

Expect these follow-ups

• What does also return compared to let?
• When would you use with instead of run?