When to use a sealed class instead of an enum?

What's really being asked

This question probes your ability to model complex, yet finite, states in a type-safe way. The interviewer wants to see if you understand the fundamental difference between a set of constant values (enum) and a restricted class hierarchy (sealed class). It's a test of choosing the right tool for state representation, particularly when states can carry different associated data.

The full answer

A strong answer explains the core distinction and then provides a concrete example. First, clarify the limitation of enums: all enum constants are instances of the same enum class and cannot hold different types of data. They are perfect for simple, fixed sets of values like Direction.NORTH or Status.PENDING. Second, introduce sealed classes as the solution for richer state machines. Explain that a sealed class allows you to define a restricted hierarchy where subclasses can be completely different types (data class, object, regular class). This is the key. Third, provide the canonical network request example: sealed class NetworkResult. Define subclasses like object Loading, data class Success(val data: User), and data class Error(val message: String). This shows how each state can hold different or no data. Fourth, demonstrate how the when expression provides compile-time exhaustive checks, preventing you from forgetting to handle a state.

The mistakes people make

A major red flag is saying they are mostly interchangeable or that the only difference is syntax. Another weak answer focuses only on the when statement's exhaustiveness, which is a benefit of both enums and sealed classes. The crucial difference is the ability of sealed class subclasses to have their own unique properties and state. Forgetting to mention that subclasses can be a data class, object, or class shows a shallow understanding. Saying a sealed class can have infinite subclasses is also incorrect; the hierarchy is restricted to the file or module where it's defined.

What usually comes next

"What's the difference between a sealed class and a regular abstract class with a private constructor?" (Answer: The compiler knows all direct subclasses of a sealed class at compile time, enabling exhaustive when checks, which isn't true for a regular abstract class). "Can a sealed class have multiple instances of a subclass?" (Answer: Yes, if the subclass is a data class or class, like Success(user1) and Success(user2). If it's an object, it's a singleton).

A concrete example

For representing UI state, an enum is too simple. enum class UiState { LOADING, SUCCESS, ERROR } can't hold the user data on success or the error message. A sealed class is perfect: sealed class UiState { object Loading : UiState(); data class Success(val users: List<User>) : UiState(); data class Error(val message: String) : UiState(); }. Now your Success state can actually hold the list of users, which is impossible with an enum.