Kotlin Interview Questions — Practice Quiz

The Kotlin language spec requires every value class to wrap exactly one underlying value, declared as a val property in the primary constructor. A value class with zero properties or with more than one property will not compile.

Inlining can only happen when the compiler knows the concrete static type. Generic collections erase type information and store references, so the value class must be boxed into an object at runtime. This is one of the well-known cases where boxing occurs despite the class being declared value.

For each property in the primary constructor, the Kotlin compiler generates equals()/hashCode() based on those properties, toString() returning the class name and property values, copy() for creating a shallow copy with optional overrides, and componentN() functions to support destructuring declarations.

Kotlin object declarations are initialized lazily — the singleton is not created until first access (the object's class is loaded and its static initializer is triggered on first access). When initialization begins, the superclass constructor runs first (the declared superclass constructor (if any) executes), mirroring normal class construction. Then property initializers and init blocks run in textual order (property initializers and init blocks execute in textual (top-to-bottom) order) — so x is initialized, then the init block runs, then y. Only after all initialization completes is the fully constructed instance handed back to the caller (the fully initialized singleton instance is returned to the caller).

As of Kotlin 2.0, the inline modifier was removed from value class declarations. A value class is now declared with just value class, e.g. value class UserId(val id: String). The compiler still replaces usages with the underlying type at compile time where possible, but the inline keyword is no longer part of the syntax.

The when expression is used as the return value of execute, making it an expression form that Kotlin requires to be exhaustive. Operation is a sealed class with three direct subclasses: Add, Subtract, and Multiply. The when only handles Add and Subtract, omitting Multiply. Because sealed classes enable exhaustiveness checking, the compiler rejects the non-exhaustive when. Adding an is Multiply -> op.a * op.b branch (or an else branch) would fix the compile error.

The Kotlin specification requires that a value class has exactly one underlying property, which must be a val declared in the primary constructor header. var properties, multiple properties, or properties declared only in the class body are all disallowed. The single val becomes the representation that the compiler inlines.

The compiler generates componentN(), equals(), hashCode(), toString(), and copy() based ONLY on the primary constructor parameters. Properties declared in the class body (like greeting) are excluded from all auto-generated functions. Therefore the statement that the auto-generated componentN() functions are produced only for properties declared in the primary constructor, not for properties declared in the class body is true — componentN() is generated only for name and age. The statement that the auto-generated copy() function has parameters matching only the primary constructor properties is true — copy() has parameters for name and age only. The claim that the auto-generated equals() and hashCode() consider every property in the class, including those declared in the body outside the primary constructor is false because greeting is NOT included in equals()/hashCode(). The claim that a data class can be declared open so that other classes may inherit from it is false because data classes cannot be open (they are final by default and the compiler rejects open data class). The claim that the auto-generated toString() includes body-declared properties in addition to primary constructor properties is false because toString() only includes primary constructor properties, so greeting does not appear.

Object declarations in Kotlin are initialized lazily on first access — not when the file is loaded. main prints "Start" first. The expression C.ref is the first access to C, so C's initialization begins. Inside an object, initializers and init blocks run top-to-bottom: C's init block prints "C init", then val ref = B is evaluated, which triggers B's initialization. B's init block prints "B init", then val ref = A triggers A's initialization, printing "A init". With all three objects initialized, C.ref completes and main prints "End". The result is a depth-first, lazy chain: C → B → A.

This question tests staff-level understanding of Kotlin inline value class boxing semantics. Boxing is forced by the JVM type system and generics erasure, not by arbitrary compiler choices. Nullable usage requires the wrapper because primitives cannot be null. Generic type arguments erase to Object, so the boxed form is the only valid representation. Arrays of value classes face the same erasure-to-Object constraint since JVM arrays are reified. Interface dispatch requires a reference type because the value class, when used as an interface it implements, must be accessed through a reference-typed receiver. Note that cross-module boundaries do NOT force boxing: the Kotlin compiler uses name mangling precisely to preserve value-class identity without requiring the boxed form, and inline lambdas do not inherently box captured value-class parameters — the inline modifier inlines the lambda body at the call site, so capture-based boxing only applies to non-inline escaping closures, which is a general closure-capture concern rather than a value-class-specific forced-boxing rule.