Common Kotlin Interview Questions

Kotlin interviews tend to circle back to the same handful of language features because they are exactly the areas where Kotlin diverges most sharply from Java: null safety, immutability, concise class declarations, and coroutines. Interviewers use these questions to check whether you understand *why* a feature exists, not just its syntax. This guide walks through the questions that come up again and again, with answers phrased the way you should phrase them out loud.

var declares a mutable reference — you can reassign it after initialization. val declares a read-only (immutable) reference — once assigned, it cannot be reassigned. Note that val only makes the reference immutable, not necessarily the object it points to: a val list can still be a MutableList whose contents change, even though the variable itself can never point to a different object. Kotlin encourages val by default to reduce accidental mutation and make code easier to reason about.

Kotlin's type system distinguishes nullable types (String?) from non-nullable types (String) at compile time. A non-nullable type can never hold null, so the compiler rejects any assignment or dereference that could NPE without you explicitly handling it. This pushes null-pointer bugs from runtime crashes to compile-time errors, which is why Kotlin is often described as 'null-safe by design' rather than merely 'null-safe by convention.'

The safe-call operator ?. evaluates the expression to the right only if the receiver is non-null, otherwise it short-circuits to null. The Elvis operator ?: supplies a default value when the expression on its left is null, and is commonly chained after a safe call, e.g. user?.name ?: "Unknown". The not-null assertion operator !! forcibly casts a nullable value to non-null, throwing a NullPointerException immediately if it actually is null — it should be used sparingly, only when you can prove null is impossible.

Marking a class 'data' tells the compiler to auto-generate equals(), hashCode(), toString(), a componentN() function per property (enabling destructuring), and a copy() function for creating modified shallow copies. A regular class gets none of this for free — you'd hand-write equals/hashCode/toString yourself. Data classes are meant for classes whose primary purpose is holding data; they require at least one parameter in the primary constructor and all primary-constructor parameters participate in the generated functions.

Enums represent a fixed set of instances where every case has the same shape (same properties). Sealed classes represent a fixed, closed set of subtypes where each subtype can carry different data and different structure — for example a Result sealed class with Success(data: T) and Error(message: String) subtypes that hold completely different fields. Because the subtype hierarchy is closed to the module/package that declares it, a when expression over a sealed class can be exhaustive without an else branch, which the compiler checks for you.

An extension function lets you add a new function to an existing class without modifying its source or subclassing it, e.g. fun String.lastChar(): Char. Under the hood the compiler turns it into a static function that takes the receiver as its first parameter, so it never actually changes the class or has access to private members. Crucially, extension function resolution is static (resolved by the declared/compile-time type), not dynamic like real member functions — so if a subclass declares an extension with the same signature, the one that runs is chosen by the variable's static type, not its runtime type.

lateinit lets you declare a non-null var without initializing it immediately, deferring initialization to later (commonly used for dependency injection or Android lifecycle fields); it only works on var properties of non-primitive, non-nullable types, and accessing it before initialization throws an exception. lazy is a delegated property built on a lambda that computes the value on first access and caches it thereafter; it works on val properties and is thread-safe by default (SYNCHRONIZED mode), making it the natural choice for expensive one-time computations.

Kotlin has no 'static' keyword. Instead, a class can declare a companion object, which is a real singleton object tied to the class that can hold properties/functions callable without an instance (ClassName.member). Unlike Java statics, a companion object is an actual object — it can implement interfaces, have an instance passed around, and be extended with extension functions — giving you static-like access with more flexibility.

== calls the structural equals() function (checking value/content equality, with null-safety built in), which is roughly equivalent to Java's .equals(). === checks referential equality — whether both operands point to the exact same object in memory, equivalent to Java's ==. For data classes, == uses the generated equals() and compares property values, while === would only be true if both variables reference the identical instance.

A coroutine is a lightweight, suspendable unit of work managed by the Kotlin runtime, not the OS — thousands can run concurrently on a small pool of real threads because a suspended coroutine doesn't block its underlying thread, it simply yields it back. Threads are OS-level constructs that are comparatively expensive to create and always occupy their own stack while blocked. Coroutines use structured concurrency (scopes, jobs) to make cancellation and error propagation predictable, whereas raw thread management requires manual bookkeeping.

The primary constructor is declared in the class header (class User(val name: String, val age: Int)) and is the main entry point for initialization, often paired with init blocks. Secondary constructors are declared inside the class body with the constructor keyword and must delegate to the primary constructor (directly or transitively) via this(...) if a primary constructor exists. Secondary constructors are typically used to offer alternate ways to construct an object, such as for Java interop or overloaded construction patterns.

After the compiler proves a nullable or supertype variable satisfies a check — such as an is check or a null comparison — it automatically treats the variable as the narrower, non-null type for the rest of that scope, without requiring an explicit cast. For example, inside if (obj is String) { obj.length } the compiler knows obj is a String and lets you call String members directly. Smart casts only work on val variables (or vars the compiler can prove aren't modified between the check and the use), because a mutable var could theoretically change type in between.