When would you use a sealed class instead of an enum?

What's really being asked

This question tests your understanding of a core concept in type-safe design: modeling restricted hierarchies. The interviewer isn't just checking syntax; they want to see if you can differentiate between a fixed set of constants (enums) and a fixed set of types that can each carry their own unique state (sealed classes). Your ability to articulate this difference, especially in the context of state management (like API responses or UI states), demonstrates senior-level language proficiency.

The full answer

First, state the core difference: enums represent a set of singleton instances, while sealed classes represent a closed hierarchy of types. All enum constants are of the same type. Subclasses of a sealed class can be different types.

Second, explain the key advantage of sealed classes: holding state. Because subclasses are distinct types, they can have their own properties. For example, Success(data: User) holds a User object, while Error(message: String) holds an error message. An enum cannot elegantly model this heterogeneous state.

Third, mention the similarity: both work with when expressions to provide compile-time exhaustiveness. The compiler will force you to handle every possible case, which prevents runtime errors when new states are added.

Finally, provide the requested code example, showing an object for a stateless case (Loading) and classes for stateful cases (Success, Error).

The mistakes people make

A major red flag is suggesting they are mostly interchangeable. Another is trying to shoehorn state into an enum, for example, by adding a mutable var data: Any? property. This is not type-safe and defeats the purpose of using a restricted class system. A less severe mistake is only describing what they are without explaining why you'd choose one over the other based on the need to associate different data with different states.

What usually comes next

Expect follow-ups like, "When would you use a sealed interface instead of a sealed class?" (Answer: For multiple inheritance, or when classes in the hierarchy don't share a common implementation). Another is, "Can a subclass of a sealed class be another sealed class?" (Answer: Yes, to create more complex, nested state machines).

A concrete example

To model a network request, you could define a sealed class like this:

sealed class NetworkResult { object Loading : NetworkResult() data class Success(val data: List<String>) : NetworkResult() data class Error(val message: String) : NetworkResult() }

Then, you can use an exhaustive when expression to handle all possible states in a type-safe way:

fun handleResult(result: NetworkResult) {

when (result) {

is NetworkResult.Loading -> println("Loading...") is NetworkResult.Success -> println("Success: ${result.data.size} items loaded") is NetworkResult.Error -> println("Error: ${result.message}") } }

If you later added a NetworkResult.Cancelled state, the compiler would show an error at every when block until you handled the new case.