Hot vs cold Kotlin Flows and StateFlow use case

What's really being asked

This question evaluates whether you understand the lifecycle and sharing semantics of Kotlin Coroutines streams. Interviewers want to see that you know cold flows are lazy and tied to individual collectors, while hot flows are eager and broadcast to multiple consumers. They are also checking if you can map these mechanics to real Android architecture decisions, specifically why ViewModel UI state is typically modeled with StateFlow rather than a plain Flow.

The full answer

First, define the core distinction. A cold Flow does not start emitting until a collector begins collecting, and it runs its upstream code independently for every collector. A hot SharedFlow or StateFlow is backed by a producer that runs independently of collectors, broadcasting emissions to all current subscribers. Second, explain StateFlow specifics. It is a specialized SharedFlow that always holds a single current value, requires an initial value, and only emits to collectors when the value changes via equality comparison. Third, give the Android scenario. In a ViewModel, expose screen state as StateFlow so the UI can collect it across configuration changes and always receive the latest state immediately upon subscription without re-triggering the underlying data load. Fourth, mention the practical API. You typically use stateIn to convert a cold Flow into a StateFlow inside a ViewModel, specifying a scope and a SharingStarted strategy such as WhileSubscribed or Eagerly.

The mistakes people make

Saying that Flow is always better because it is simpler, without acknowledging the cost of re-running network or database queries for every collector. Claiming that StateFlow is just LiveData without being able to explain the differences in threading, initial value requirements, or the fact that StateFlow has no lifecycle awareness on its own. Another red flag is suggesting Flow with the shareIn operator as equivalent to StateFlow for UI state, without noting that StateFlow provides a synchronous value read via its value property and distinctUntilChanged behavior by default.

What usually comes next

The interviewer may ask how stateIn behaves with SharingStarted.WhileSubscribed versus Eagerly, or how long the upstream flow stays active. They might ask what happens if you collect a StateFlow from multiple fragments, or how to handle events that should not be replayed, which leads to SharedFlow with replay=0. You could also be asked to compare StateFlow to LiveData and explain why StateFlow is preferred in pure Kotlin Coroutines architectures.

A concrete example

Imagine a news app where a ViewModel loads a list of articles from a repository. If the repository returns a cold Flow, collecting it from two different UI components would execute two separate network requests. Instead, the ViewModel collects that repository Flow into a StateFlow using stateIn. Now both the list screen and a detail pane can collect the StateFlow, each immediately getting the current article list without duplicating work, and surviving a screen rotation because the StateFlow lives in the ViewModel scope.