What are the advantages of a Kotlin data class?

What's really being asked

This question tests your practical understanding of Kotlin's language features beyond basic syntax. The interviewer wants to see that you understand the 'why' behind data classes: their role in reducing boilerplate, preventing bugs from hand-written equals/hashCode methods, and enabling modern architectural patterns like MVI that rely on immutable state. It separates your ability to define a data container from a class with complex business logic.

The full answer

First, state the primary advantage: The compiler automatically generates useful, standard functions based on the properties in the primary constructor. This saves significant development time and eliminates a common source of bugs.

Second, name the key generated functions. A senior candidate should know at least four of the five: equals()/hashCode() for value-based comparison and use in collections like Sets/Maps; toString() for readable logging output (e.g., User(name=Sharif, age=24)) instead of a memory address; copy() for creating new instances from existing ones with modified properties; and componentN() functions which enable destructuring declarations.

Third, explain a practical use case for copy(). The key is immutability. In Android, UI state is often represented by an immutable data class. When an event occurs (e.g., data loads), you use copy() to create a new state object. For example: val newState = currentState.copy(isLoading = false, data = loadedData). This new object is then emitted to the UI. This avoids complex mutation, race conditions, and makes state changes predictable and easy to debug.

The mistakes people make

A vague answer like "it's just shorter" without specifics. This shows a shallow understanding.

Only mentioning toString(). This is the most trivial benefit and misses the crucial roles of equals() and copy() in application architecture.

Describing copy() as a way "to change the object." This is a major red flag. The entire point of copy() in immutable patterns is to create a new object, not mutate the original. The original instance remains unchanged.

Confusing copy() with a deep copy. The generated copy() is a shallow copy. If a property is a mutable object, the reference is copied, not the object itself. Changes to that nested object will be reflected in both the original and the copied parent object.

What usually comes next

"When would you NOT use a data class?" (When the class has significant behavior, needs to be inherited from (it's final by default), or when object identity is more important than value equality.)

"What are the requirements for a data class?" (Must have a primary constructor with at least one parameter; all primary constructor parameters must be val or var; cannot be abstract, open, sealed, or inner.)

A concrete example

In a ViewModel using MVI, you manage UI state with a data class: data class NewsUiState(val articles: List<Article> = emptyList(), val isLoading: Boolean = true)

When a network request finishes, you update the state not by changing the isLoading property, but by creating a new state object: val currentState = _uiState.value

val newState = currentState.copy(isLoading = false, articles = fetchedArticles)

_uiState.value = newState

This creates a clear, predictable, and immutable flow of state from the ViewModel to the UI.