Top 60 Kotlin Interview Questions (2026)

Kotlin is a statically typed language from JetBrains that runs on the JVM and interoperates fully with Java. It's known for concise syntax and null safety built into the type system.

Its popularity took off when Google made it the preferred language for Android in 2019. Teams also reach for it on the backend because it removes Java's boilerplate while reusing the entire Java ecosystem, so migration happens one file at a time.

val declares a read-only reference: once assigned, it can't be reassigned. var declares a reassignable reference. Prefer val by default and reach for var only when you actually mutate.

One trap: val is not deep immutability. A val pointing at a mutable list still lets you change the list's contents; it only stops you from pointing the name at a different list.

Kotlin splits every type into nullable and non-nullable at compile time. String can never hold null; String? can. The compiler forces you to handle the null case before you use a nullable value, so most NullPointerExceptions get caught before the code runs.

The tools are the safe call ?., the Elvis operator ?:, and the not-null assertion !!. Null safety in the type system is Kotlin's headline feature.

?. calls a member only if the receiver is non-null, otherwise the whole expression is null. ?: returns its left side when that side is non-null, otherwise the right side, so it supplies a default.

Chaining them is the idiomatic null-handling pattern: reach into a nullable chain safely, then fall back to a default.

!! converts a nullable type to its non-null counterpart and throws a NullPointerException if the value is actually null. It tells the compiler 'trust me, this isn't null.'

Avoid it whenever a safe call plus Elvis, or a null check, would work. Reaching for !! is often a sign the nullability wasn't modeled properly. It brings back the exact crash Kotlin is designed to prevent.

A data class holds data and auto-generates equals(), hashCode(), toString(), componentN() for destructuring, and copy() from the properties in its primary constructor. It replaces a page of Java boilerplate with one line.

copy() is the everyday tool: make a modified duplicate while keeping the original untouched, which fits immutable-style code.

== checks structural equality and calls equals(); === checks referential equality, whether two names point to the same object in memory. This is the reverse of Java, where == is referential.

For data classes, == compares field by field. Use === only when you specifically care about object identity.

when replaces the switch statement and is an expression, so it returns a value. It matches literals, ranges (in 1..10), types (is String), and arbitrary boolean conditions, with no fall-through and no break.

When used as an expression with a return value, it must be exhaustive, which the compiler enforces for sealed types and enums.

if returns a value in Kotlin, so you assign its result directly. This is why Kotlin has no ternary operator (a ? b : c); if/else fills that role and reads better.

The same expression-orientation applies to when and try, which keeps code assignment-based rather than statement-heavy.

Kotlin is statically typed, but the compiler infers types from the right-hand side, so you often skip annotations. val count = 5 is inferred as Int; val name = "Asha" as String.

Types are still checked at compile time; inference just removes the noise. Annotate explicitly for public APIs and where inference would pick a wider or surprising type.

Add a question mark: String? can hold null, String cannot. The two are distinct types, and the compiler won't let you assign null to a non-null type or use a nullable one without a null check.

This split is what moves null bugs from runtime to compile time. Default to non-null and add ? only where absence is a real, expected state.

String templates embed variables and expressions directly in a string with $name for a variable and ${expression} for anything more complex. No concatenation, no format placeholders.

They're evaluated at runtime and are the everyday way to build strings, similar to Python f-strings or JavaScript template literals.

Functions use the fun keyword with parameter types after each name and the return type after the parameter list. Single-expression functions drop the braces and use =.

Default arguments give parameters fallback values, and named arguments let callers pass them in any order and skip the ones with defaults, which removes the need for many overloads.

List is a read-only interface: you can read and iterate but there's no add or remove. MutableList extends it with mutating operations. listOf() returns a List, mutableListOf() returns a MutableList.

Read-only is not the same as immutable. A List reference can point at a list that something else still mutates. It's about the interface you expose, not a hard guarantee.

Kotlin has no C-style for loop. You iterate over ranges and collections: for (i in 1..5), for (item in list). Ranges use .. (inclusive), until (exclusive end), downTo, and step.

while and do-while exist as usual. For index and value together, use withIndex() rather than a manual counter.

Kotlin has no static keyword. A companion object is a single object tied to a class that holds members you'd call statically in Java: factory methods, constants, and class-level state. You access them through the class name.

Under the hood it's a real object instance, so companion members can implement interfaces and be extended, which plain Java statics can't.

List<String?> is a non-null list that may contain null elements. List<String>? is a nullable list of non-null strings, so the whole list can be null. List<String?>? is both: a nullable list that may hold null elements.

Reading these precisely matters because the ? placement changes exactly what can be null.

Any is the root of the non-null type hierarchy, like Object in Java. Unit is the type of a function that returns no meaningful value; it has one instance and is usually omitted. Nothing is the type with no values, returned by functions that never return normally (they always throw or loop forever).

Nothing is what makes throw usable as an expression and lets the compiler know code after it is unreachable.

After you check a type with is (or check for null), the compiler automatically casts the value inside that scope, so you use it as the checked type without an explicit cast. This is the smart cast.

It works only when the compiler can prove the value can't change between the check and the use, which is why smart casts don't apply to mutable var properties that other code could reassign.

as is an unsafe cast that throws a ClassCastException if the object isn't the target type. as? is a safe cast that returns null instead of throwing when the cast fails.

Pair as? with the Elvis operator to cast and provide a fallback in one line, which avoids both the crash and a separate type check.

When a function body is one expression, you can drop the braces and the return keyword and use =. The return type is often inferred too, so the whole function fits on one line.

It reads well for small pure functions and mappers. For anything with multiple statements, use the block body with braces.

Kotlin has public (the default), private, protected, and internal. The big differences from Java: public is the default instead of package-private, and internal means visible within the same compilation module, which Java has no equivalent for.

private at the top level means file-scoped, and protected in Kotlin is not visible to the same package (unlike Java).

The primary constructor is part of the class header and is where you declare and often initialize properties directly (class User(val name: String)). Secondary constructors are declared inside the body with the constructor keyword and must delegate to the primary one with this(...).

The init block holds setup logic that runs with the primary constructor. Most Kotlin classes need only a primary constructor plus default arguments, so secondary constructors are less common than in Java.

Because return and throw are expressions of type Nothing, they fit on the right side of ?:. So val id = user?.id ?: return handles the null case by leaving the function, and ?: throw does the same with an exception.

This flattens nested null checks into a straight line of guard clauses, which reads better than deep if nesting.

No. Kotlin has no checked exceptions, so no function forces callers to catch or declare what it might throw, and there's no throws clause you must satisfy. Every exception is effectively unchecked.

The reasoning is that checked exceptions in large Java codebases often led to empty catch blocks or blanket rethrows that added noise without safety. You still use try/catch; you just aren't compelled to by the compiler.

An extension function adds a method to an existing type without inheriting from it or editing its source. You write fun String.shout() = uppercase() and then call it as if String defined it.

They're resolved statically at compile time based on the declared type of the receiver, not the runtime type. So they don't override members and can't participate in polymorphism, which is the usual follow-up trap.

A higher-order function takes a function as a parameter or returns one. Kotlin has first-class function types like (Int) -> Int, so functions pass around like any value.

Lambdas are the concise literal syntax. When a lambda is the last argument, it moves outside the parentheses (trailing lambda), which is why builders like list.map { } read so cleanly. A single parameter is available as it.

These five run a block on an object and differ in two ways: what the block sees the object as (it or this) and what the block returns (the object or the lambda result). let and also expose it; run, with, and apply expose this. apply and also return the object; let, run, and with return the lambda result.

In practice: let for null-safe transforms, apply for configuring an object, also for side effects like logging, run for computing a result from an object.

A coroutine is a lightweight unit of concurrency you can suspend and resume without blocking a thread. Many coroutines run on a small pool of threads, so you can have hundreds of thousands where you'd have far fewer threads.

The key difference: suspension is cooperative and cheap, while a blocked thread holds an OS resource. Coroutines make async code read top to bottom, like sequential code, instead of nested callbacks.

A suspend function can pause execution and resume later without blocking the calling thread. The suspend keyword tells the compiler to transform it so it can save and restore state at each suspension point.

You can only call a suspend function from another suspend function or from inside a coroutine builder like launch, async, or runBlocking. Calling one from ordinary code is a compile error, which is how the compiler enforces the coroutine boundary.

launch starts a coroutine that doesn't return a result and gives you a Job to manage its lifecycle (cancel, join). Use it for fire-and-forget work. async starts a coroutine that computes a value and returns a Deferred<T>; call await() to get the result.

The pattern for parallel work is starting several asyncs, then awaiting them all, so the tasks overlap instead of running one after another.

Structured concurrency means every coroutine runs inside a scope, and the scope won't finish until all its child coroutines finish. Cancelling the scope cancels the children, and a failing child cancels its siblings by default.

This prevents leaked coroutines and lost exceptions. coroutineScope { } and the lifecycle-tied scopes on Android are how you get it in practice.

A sealed class defines a closed set of subtypes known at compile time; all direct subclasses must be declared in the same module. It models a fixed set of states, like a network result that's Loading, Success, or Error.

The payoff is exhaustive when: because the compiler knows every subtype, a when over a sealed class needs no else branch, and adding a new subtype turns forgotten cases into compile errors.

An enum is a fixed set of single instances that all share the same shape. A sealed class is a fixed set of subtypes that can each carry different data and have multiple instances. So enum values are constants; sealed subtypes are types.

Reach for an enum when the cases are just labels (days, directions). Reach for a sealed class when each case needs its own fields, like Success(data) versus Error(message).

object creates a singleton: one instance, defined and instantiated in a single declaration, thread-safe by the language. Use it for stateless helpers, a single shared registry, or a manager where one instance is correct.

The same keyword also makes anonymous objects (object : Listener { }) and companion objects inside a class. All three are the same idea: an object without a reusable class.

The functional pipeline set: map (transform), filter (keep matching), reduce and fold (accumulate), groupBy (bucket by key), associate (build a map), and flatMap (map then flatten). They chain into readable pipelines that replace manual loops.

Know that these run eagerly on collections, building an intermediate list at each step. For large chains, asSequence() makes them lazy, which is the natural follow-up.

Operations on a List are eager: each step (filter, map) builds a full intermediate list before the next runs. A Sequence is lazy: elements flow through the whole chain one at a time, and nothing runs until a terminal operation like toList() or sum().

For short chains on small data, lists are fine and simpler. For long chains or large data, sequences avoid the intermediate allocations and can short-circuit early with operations like first.

Generics let a class or function work over a type parameter, like List<T>. Variance controls subtyping between generic types. out marks a producer: the type is only returned, so List<Dog> can be treated as List<Animal> (covariance). in marks a consumer: the type is only accepted, giving contravariance.

The mnemonic is producer-out, consumer-in. Where you can't annotate the class, a type projection at the use site (List<out Animal>) does the same job.

Normally type arguments are erased at runtime, so you can't check T directly. Marking an inline function's type parameter reified keeps the actual type available at runtime, letting you write x is T or T::class inside the function.

It works only on inline functions, because the compiler substitutes the real type at each call site. It's what makes helpers like a type-safe fromJson<User>() possible.

An inline function has its body, and its lambda arguments, copied into each call site at compile time instead of being called as separate objects. This removes the object allocation and call overhead that lambdas would otherwise add.

The main wins: cheaper higher-order functions in hot code, non-local returns from lambdas, and reified type parameters. The cost is larger bytecode, so inlining big functions is counterproductive.

lateinit var promises a non-null var will be assigned before first use; it skips an initial value and throws if you read it too early. It's for var properties set by a framework or setup method, and only for non-primitive types.

by lazy { } computes a val's value on first access and caches it, thread-safe by default. Use lazy for expensive values you may not need; use lateinit for dependency-injected or framework-initialized fields.

The by keyword delegates work to another object. Class delegation (class A(b: B) : Interface by b) forwards interface methods to a wrapped instance, giving composition without inheritance boilerplate. Property delegation routes get and set through a delegate that implements getValue and setValue.

lazy, observable, and Map-backed properties are all built on property delegation, so understanding by explains how those work.

Destructuring unpacks an object into several variables in one line: val (name, age) = user. It calls the object's component1(), component2(), and so on, which data classes generate automatically.

It shines when iterating maps (for ((key, value) in map)) and returning multiple values via a data class or Pair. Use an underscore to skip a component you don't need.

An infix function is called without the dot and parentheses (1 to 2 instead of 1.to(2)); it must be a single-parameter member or extension marked infix. Operator overloading maps symbols like +, [], and in to functions named plus, get, contains, and so on via the operator modifier.

Both improve readability for DSL-like APIs, but overusing them hurts clarity, so reserve operators for meanings people already expect.

try runs code that may throw, catch handles a specific exception type, and finally always runs for cleanup. Kotlin has no checked exceptions, so you catch what you choose to.

The twist is that try is an expression: it returns the value of the try block, or of the matching catch block if one fires. So you can assign the result of a try directly, which fits Kotlin's expression-oriented style.

A CoroutineContext is a set of elements that configure a coroutine: its Job, its dispatcher, an optional name, and an exception handler. It's inherited by children and combined with the + operator.

The dispatcher decides which thread or pool runs the coroutine. Dispatchers.Default is for CPU work, Dispatchers.IO for blocking I/O with a larger pool, and Dispatchers.Main for the UI thread. withContext switches dispatcher for a block, which is how you move blocking work off the main thread.

Cancellation is cooperative. Cancelling a coroutine sets a flag and throws CancellationException at the next suspension point. Suspending functions in kotlinx.coroutines check for cancellation, but a tight CPU loop with no suspension won't notice.

To stay cancellable in long computations, call ensureActive() or yield() periodically, or check isActive. Also, run cleanup in finally, and if you must suspend during cleanup, wrap it in withContext(NonCancellable).

A Flow is an asynchronous stream of multiple values produced over time, built on coroutines. A suspend function returns one value; a Flow emits many. Flows are cold by default: the producer block runs fresh for each collector and only when collection starts.

A Channel is hot and shares emissions between receivers, more like a queue for communicating between coroutines. Flow is for declarative streams; Channel is for passing values between running coroutines. SharedFlow and StateFlow are the hot, multicast variants of Flow.

An exception in a launch coroutine propagates up through the Job hierarchy and, by default, cancels the parent and siblings (structured concurrency). In async, the exception is stored in the Deferred and re-thrown when you call await().

A CoroutineExceptionHandler in the context catches uncaught exceptions from launch at the top level. To stop one child's failure from cancelling siblings, use a SupervisorJob or supervisorScope, where children fail independently.

In an inline function, lambda parameters are inlined by default. noinline opts a specific lambda out of inlining, which you need when you want to store it or pass it on as an object. crossinline keeps the lambda inlined but forbids non-local returns from it, which matters when the lambda is invoked from another execution context like a nested runnable.

The reason both exist is that inlining changes what a lambda can do: an inlined lambda can return from the enclosing function, and that isn't always safe or possible.

A value class wraps a single value and, where the compiler can, represents it at runtime as the underlying value with no wrapper object allocated. So you get a distinct type for type safety without the boxing cost.

The classic use is stopping primitive-obsession bugs: UserId and OrderId can both wrap Long yet be different types, so you can't pass one where the other is expected. The wrapper disappears at runtime in most cases.

Kotlin compiles to the same JVM bytecode as Java, so each can call the other directly. Kotlin adds annotations to smooth the seam: @JvmStatic exposes companion members as Java statics, @JvmOverloads generates overloads for default arguments, and @JvmField exposes a property as a plain field.

The sharp edge is platform types. Java values have unknown nullability, so Kotlin treats them as platform types (String!) and can't enforce null safety on them. If Java returns null into a Kotlin non-null type, you get a runtime failure at the boundary. Annotating the Java side or checking at the boundary is the fix.

Most of it is compile-time: the compiler tracks nullable versus non-null types and rejects unsafe uses, so there's no runtime type distinction for that part. On top of that, the compiler inserts runtime null checks at boundaries, notably intrinsic checks on public function parameters, so a null slipping in from Java fails fast with a clear message.

So null safety is a compiler feature backed by defensive runtime checks at the edges, not a JVM type-system change.

Implement getValue (and setValue for a var) with the delegate signatures, then attach it with by. The delegate receives the owning object and the property metadata, so one delegate can serve many properties and add behavior like validation, logging, or caching.

This is the same mechanism behind lazy and Delegates.observable, so writing one shows you understand what by actually does.

Objects that are equal by equals() must return the same hashCode(), and hashCode must stay stable while the object is used as a map key or set member. Break it and objects vanish inside hash maps.

Data classes generate both from the primary-constructor properties, so they satisfy the contract automatically. The trap is a data class with a mutable var in the constructor used as a map key: mutating it changes the hash and corrupts the map, which is why value objects should be immutable.

Kotlin Multiplatform lets you share code across targets (JVM, Android, iOS, JS, native) by writing common logic once and compiling it to each platform. You share business logic while keeping platform-specific UI native.

The expect/actual mechanism handles platform differences: common code declares expect fun currentTime() with no body, and each platform provides an actual implementation. The compiler binds them per target, so shared code calls one API backed by platform-specific code.

tailrec tells the compiler to rewrite a tail-recursive function into a loop, so deep recursion doesn't overflow the stack. It applies only when the recursive call is the very last operation in the function, with nothing left to do after it returns.

If the call isn't truly in tail position, the compiler warns and leaves it as ordinary recursion. It's how you write a recursive algorithm safely on the JVM, which has no native tail-call elimination.

Kotlin DSLs combine three features: lambdas with receiver (a lambda whose this is a builder object), trailing lambda syntax, and extension functions. Together they let a config block read like structured markup while staying fully type-checked.

@DslMarker prevents accidental access to an outer builder's scope from an inner block, which keeps nested builders unambiguous. This is how libraries like the kotlinx.html and Gradle Kotlin DSLs work.

Smart casts need the compiler to prove a value can't change between the check and the use. They fail on mutable var properties, especially open ones or ones from another module, because other code could reassign them after the check. The fix is copying into a local val first.

Contracts let a function tell the compiler about its effects, for example that returning true implies an argument is non-null, so smart casts and definite-assignment analysis work across your own helper functions.

The usual suspects: non-inlined lambdas allocate objects, boxing happens when generics or nullable primitives (Int?) force wrapper types, and long eager collection chains build an intermediate list at every step. None of these matter until a profiler says they do.

The fixes map one to one: inline hot higher-order functions, use value classes or primitive arrays (IntArray) to dodge boxing, and switch heavy chains to sequences. As always, measure first with a JVM profiler, because Kotlin's costs are the JVM's costs plus a thin layer.