StateFlow vs SharedFlow in Kotlin: Interview Guide

Preparing for an Android interview? You probably don't need another 2,000-word lecture on Flow.

You need to remember one thing quickly:

StateFlow → What is the current state?
SharedFlow → What happened?

That simple question will help you choose between them in many interview situations.

StateFlow vs SharedFlow — Quick Revision

StateFlow SharedFlow
Represents current state Broadcasts values/events
Always has a current value Does not require an initial value
New collector gets the latest value Replay is configurable
Always keeps one latest value Can replay multiple previous values
Great for UI state Useful for events and broadcasts

Memory trick:

StateFlow = State
SharedFlow = Share

Don't memorize the table. Ask yourself:

"Does my UI need to know the current condition, or do I need to tell collectors that something happened?"

StateFlow vs SharedFlow


1. What is StateFlow?

StateFlow is a hot flow that always holds a current value. A new collector immediately receives that current value and then receives future updates.

That makes it a natural choice for UI state such as:

  • Loading
  • Success
  • Error
  • Logged-in / logged-out
  • Selected tab

Simple example

private val _uiState = MutableStateFlow("Loading")
val uiState = _uiState.asStateFlow()

_uiState.value = "Success"

Think about a login screen.

At first:

Loading

After the API succeeds:

Success

If the UI starts collecting after that, it can still receive Success because StateFlow keeps the current state.

Remember these 5 points

  • It always has a current value.
  • It requires an initial value.
  • New collectors receive the latest value.
  • It is commonly used for UI state.
  • It keeps only the latest state value.

2. What is SharedFlow?

SharedFlow is a hot flow designed to broadcast emitted values to its collectors.

Unlike StateFlow, it does not require an initial value.

private val _events = MutableSharedFlow<String>()
val events = _events.asSharedFlow()

_events.emit("Show Snackbar")

Imagine your ViewModel saying:

"Hey, something just happened!"

That is where SharedFlow can be useful.

Examples:

  • Show a Snackbar
  • Trigger navigation
  • Broadcast an event to multiple collectors
  • Send transient UI events

Remember these 5 points

  • No initial value is required.
  • It can broadcast values to multiple collectors.
  • replay controls how many previous values new collectors receive.
  • Default replay = 0.
  • It is more general than simply calling it an "event flow".

3. The Most Important Difference

Forget the complicated definitions for a moment.

Imagine your Android app is a person talking to you.

StateFlow says:

"Here is my current situation."

SharedFlow says:

"Something happened."

For example:

Current situation:

LoginState.Success

Use StateFlow.

Something happened:

ShowSnackbar("Login failed")

SharedFlow can be appropriate.

This distinction is much easier to remember than memorizing ten rows in a comparison table.

4. Why does StateFlow need an initial value?

Because StateFlow represents state.

If somebody asks:

"What is the current state?"

you cannot answer:

"I don't know yet."

StateFlow therefore always has a current value.

val state = MutableStateFlow("Loading")

The current state is immediately available through:

state.value

That's one of the easiest ways to recognize StateFlow in an interview.

5. What happens when a new collector starts?

StateFlow

The new collector receives the current/latest value.

StateFlow

Current value = "Success"

        ↓

New collector

        ↓

Receives "Success"

So StateFlow behaves like a notice board showing the latest status.

SharedFlow

It depends on its replay configuration.

MutableSharedFlow()

replay = 0

With the default configuration, a new collector does not receive previously emitted values.

You can configure replay:

MutableSharedFlow<String>(
    replay = 2
)

Now new collectors can receive the two most recently replayed values.

Interview trap: Don't say "SharedFlow never replays values."

That's incorrect.

Correct answer: SharedFlow has configurable replay, and the default is zero.

6. Is SharedFlow only for one-time events?

No.

This is a very common interview trap.

SharedFlow is a general-purpose hot flow that broadcasts values. It is often used for events, but it isn't technically defined as "the one-time event flow."

For example:

MutableSharedFlow<UiEvent>()

can be used to broadcast UI events when that behavior fits the application.

If you say:

"SharedFlow is only for one-time events."

An experienced interviewer can immediately ask:

"Then what does replay do?"

And suddenly the interview became more interesting. 😄

A safer answer is:

SharedFlow is a hot flow that broadcasts values. It is commonly useful for events, and its replay behavior is configurable.

7. StateFlow and configuration changes

This is another place where interview answers often become misleading.

You may hear:

"StateFlow survives rotation."

That's not quite the right explanation.

The ViewModel survives the configuration change.

If the StateFlow is stored inside that ViewModel, its current state is still available when the new UI starts collecting.

ViewModel
   │
   └── StateFlow
          │
          ├── Old UI
          │
          └── New UI after rotation

So remember:

ViewModel → survives configuration changes

StateFlow → holds the current state

Those two ideas work together.

8. Real Android Example — Login Screen

Suppose your login screen has three states:

Loading
Success
Error

This is a perfect example of state.

sealed interface LoginState {
    data object Loading : LoginState
    data object Success : LoginState
    data class Error(
        val message: String
    ) : LoginState
}

Then your ViewModel can expose:

private val _state =
    MutableStateFlow<LoginState>(
        LoginState.Loading
    )

val state = _state.asStateFlow()

The UI doesn't need to ask:

"What happened five seconds ago?"

It asks:

"What is the login state right now?"

That's StateFlow.

9. Real Android Example — Snackbar Event

Now imagine the login API fails.

You want to tell the UI:

"Invalid username or password"

That is an event.

private val _events =
    MutableSharedFlow<String>()

val events = _events.asSharedFlow()

suspend fun showError() {
    _events.emit("Invalid username or password")
}

The important point is that you are communicating:

"Something happened."

not:

"This is the permanent current state of the screen."

10. One Important SharedFlow Problem

Suppose you create:

MutableSharedFlow<String>(
    replay = 0
)

and emit an event when nobody is collecting it.

With the default configuration, that event is not stored for a future collector.

So this:

_events.emit("Navigate")

doesn't mean:

"Store this forever and give it to the next screen."

That's why event delivery needs to be designed carefully.

Interview question:

"Can SharedFlow lose an event?"

A good answer is:

Yes. With the default replay = 0, an emission is not replayed to a collector that starts later. The exact behavior also depends on subscribers and buffering configuration.

11. One Important StateFlow Detail

StateFlow doesn't emit an update simply because you assigned a value.

If the new value is equal to the current value, StateFlow suppresses the emission.

state.value = "Success"
state.value = "Success"

The second equal value does not produce another StateFlow update to collectors.

This behavior is based on equality.

So if an interviewer asks:

"Does StateFlow emit every assignment?"

Answer:

No. Equal values are conflated and don't result in a new emission.

12. Common Interview Mistakes

❌ Mistake 1: "StateFlow is for Compose"

No.

StateFlow is a Kotlin Flow type. It can be used with Compose, XML views, Fragments, services, and other consumers.

❌ Mistake 2: "SharedFlow is always one-time"

No. SharedFlow is configurable. Replay and buffering affect its behavior.

❌ Mistake 3: "StateFlow survives rotation"

The ViewModel normally survives the configuration change. StateFlow simply continues to hold its state when it is owned by that ViewModel.

❌ Mistake 4: "SharedFlow stores the last event"

Not by default.

MutableSharedFlow() has replay = 0.

❌ Mistake 5: "StateFlow and SharedFlow are completely unrelated"

They're actually closely related.

StateFlow is a specialized form of SharedFlow designed specifically for representing state.

13. Mid-Level Interview Questions

  1. Why does StateFlow require an initial value?
  2. What happens when a new collector starts collecting StateFlow?
  3. What is the default replay value of SharedFlow?
  4. Can SharedFlow replay previous values?
  5. Why is StateFlow suitable for UI state?
  6. Can SharedFlow be used for more than one-time events?
  7. What happens if StateFlow receives the same value again?
  8. What is the difference between hot and cold Flow?

14. Senior-Level Scenario Questions

Scenario 1: Navigation happens twice after rotation

Question: Your app uses a flow to trigger navigation. After rotation, navigation happens again. What would you investigate?

Think: Is the navigation action being modelled as persistent state? What replay behavior is being used? How is the UI collecting the event?

The important lesson is not simply "replace StateFlow with SharedFlow."

First understand whether you're representing state or an event, and then choose the flow semantics accordingly.

Scenario 2: Two screens need the same updates

Question: Two active collectors need to receive the same emitted values. What could you use?

Answer: SharedFlow is designed to broadcast values to multiple collectors.

Scenario 3: New UI must immediately know the current state

Question: A newly recreated UI needs the latest login state immediately. Which is a natural choice?

Answer: StateFlow.

15. The 10-Second Interview Answer

If the interviewer asks:

"What's the difference between StateFlow and SharedFlow?"

You can answer:

StateFlow represents current state. It always has a value and new collectors receive the latest state. SharedFlow is a general hot flow that broadcasts values to collectors and has configurable replay. In Android, I commonly use StateFlow for UI state and SharedFlow when I need event-style or broadcast behavior.

Then stop.

Don't give a five-minute answer to a thirty-second question.

16. Final Cheat Sheet

Question Remember
What is StateFlow? Hot flow that represents current state
Does StateFlow need an initial value? Yes
What does a new StateFlow collector receive? Current/latest value
What is SharedFlow? Hot flow that broadcasts values
Does SharedFlow need an initial value? No
Default SharedFlow replay? 0
Can SharedFlow replay? Yes, configurable
Best mental model? StateFlow = current state; SharedFlow = something happened
Does StateFlow emit equal values? No, equal updates are conflated

StateFlow → What is happening now?

SharedFlow → What happened?

If you remember that distinction and understand the replay behavior, you already have the foundation to answer most StateFlow vs SharedFlow interview questions.

Related Android Interview Topics

  • Flow in Kotlin
  • Cold Flow vs Hot Flow
  • LiveData vs Flow
  • Coroutine Scope and SupervisorScope
  • Launch vs Async
  • State Management in Jetpack Compose

Comments

Post a Comment

Popular posts from this blog

Android Developer Interview Questions 2026 — Complete Roadmap & Answers

Image
Preparing for Android developer interviews in 2026 can feel overwhelming—not because the concepts are complex, but because topics are scattered across Kotlin, Coroutines, Jetpack Compose, and System Design. This complete roadmap organizes the core topics you will be tested on during technical screens and coding rounds in 2026. Use this guide as: A quick revision checklist before your interview A structured learning roadmap A reference guide for core Android concepts 1. Kotlin Basics & Core Syntax val vs var val : Read-only reference (immutable pointer). var : Mutable reference (can be reassigned). Rule of thumb: Always default to val for thread safety and defensive programming. lateinit vs lazy // Used for non-null var properties initialized later (e.g., Dependency Injection) lateinit var repository: UserRepository // Thread-safe initialization triggered only on first access val database: AppDatabase by lazy { AppDatabase.getInstance(context) } ...
Read more

MVVM vs Clean MVVM in Android: Which Architecture Should You Choose in 2026?

Image
MVVM vs Clean MVVM   Which Architecture Should You Choose in 2026? Introduction One of the most common questions I hear from Android developers is: "Should I use MVVM or Clean MVVM?" I have been developing Android applications for more than seven years, and I have worked on everything from small utility apps to enterprise-level products used by thousands of users. Interestingly, many projects start with simple MVVM and later move toward Clean MVVM as the application grows. The confusion usually comes from the fact that both architectures use ViewModel, Repository, Coroutines, Flow, and modern Android libraries. At first glance, they look very similar. However, the differences become obvious when the project becomes larger, multiple developers start contributing, and business logic becomes more complex. In this article, I will explain both architectures using practical examples, discuss their advantages and drawbacks, and share what has worked for me in real projects. What is ...
Read more