Interview Questions

No — it is read-only. The List interface has no add, but the object behind it may be an ArrayList that someone else holds as a MutableList and changes. listOf() returns a list you cannot modify through that interface, and a cast to MutableList can even succeed on some implementations. For a defensive copy, use toList(); for true immutability, kotlinx.collections.immutable. When a List crosses into Java it becomes java.util.List, which Java code can try to mutate.

What they are really testing: The read-only versus immutable distinction, which causes shared-state bugs.

Collection operations on an Iterable are eager: list.map { … }.filter { … }.first() builds a full intermediate list at each step. A Sequence is lazy and processes element by element through the whole chain, stopping as soon as the terminal operation is satisfied — no intermediate lists, and first() may touch only a few elements. Sequences win for long chains on large collections, short-circuiting terminals, or infinite sources (generateSequence). For small collections and one or two steps, lists are faster because sequences add per-element overhead. Operations like sorted() must still consume everything. See Module 05.

What they are really testing: That lazy is not automatically faster — the nuanced answer is what they are after.

orders.groupBy { it.customerId } → Map<Id, List<Order>>, for reports. users.associateBy { it.id } → Map<Id, User>, for O(1) lookups (a later duplicate key overwrites). val (valid, invalid) = rows.partition { it.isValid() } splits in one pass. orders.flatMap { it.lines } flattens nested lists. Counting is groupingBy { it }.eachCount(), which avoids building lists at all. Knowing the right one replaces most hand-written loops with mutable maps.

What they are really testing: Standard-library fluency; interviewers watch for hand-rolled loops in live coding.

reduce starts from the first element and throws UnsupportedOperationException on an empty collection; its accumulator has the element type. fold(initial) { acc, x -> … } starts from a value you give, works on empty collections (returns initial) and the accumulator can be a different type — words.fold(0) { acc, w -> acc + w.length }. Prefer fold, or a specific function like sumOf, unless empty input is impossible; reduceOrNull exists when you want a null.

What they are really testing: Edge-case thinking: the empty-collection behaviour is the whole question.

IntArray compiles to a primitive int[]: no boxing, compact, fastest. Array<Int> is Integer[]: every element a boxed object. List<Int> is a read-only interface usually backed by an ArrayList of boxed integers, with the full collection API. Use List by default for APIs; use primitive arrays for hot numeric code, large buffers and algorithm work where boxing shows up in profiles. Arrays are mutable, fixed-size and compare by reference — use contentEquals.

What they are really testing: Awareness of boxing and of array equality semantics.

Structurally modifying a MutableList while iterating it with for (an iterator) throws ConcurrentModificationException — the iterator detects the list changed underneath it. Correct options: list.removeAll { it.expired } (or removeIf), build a new list with filter, or use the iterator’s own remove() with an explicit iterator() loop. The name is misleading: this happens on a single thread. See Module 05.

What they are really testing: Whether you have actually hit it, and know it is not a threading issue.

By default a generic type is invariant: MutableList<String> is not a MutableList<Any>, because you could add an Int to it. out T (covariance) means the type only produces T, so List<String> is a List<Any> — Kotlin’s read-only List is declared List<out E>. in T (contravariance) means it only consumes T, so a Comparator<Any> can be used where a Comparator<String> is expected. Kotlin puts this on the declaration (declaration-site variance) instead of on every use like Java’s ? extends / ? super. See Module 09.

What they are really testing: Producer-out, consumer-in, and why List is covariant while MutableList is not.

List<*> is a star projection: a list of some specific type you do not know. You can read elements as Any? but, for a mutable type, you cannot add anything, because the real element type is unknown. MutableList<Any?> accepts anything. Use star projection when you only need to inspect a value of an unknown generic type — if (x is List<*>) — which is also the only generic is check the JVM allows, because of type erasure.

What they are really testing: Type erasure and safe handling of unknown generic types.

Generic type arguments are erased at runtime, so inside a normal fun <T> you cannot write x is T or T::class. An inline function is copied into each call site, where the real type is known, so marking the parameter reified lets the compiler substitute it:

inline fun <reified T> List<Any>.only(): List<T> = filterIsInstance<T>()

val names = mixed.only<String>()

What they are really testing: Understanding erasure and what inlining actually does.

inline copies the function body and its lambda arguments into the caller, removing the lambda object allocation and allowing a plain return inside the lambda to return from the enclosing function (a non-local return). noinline on a lambda parameter keeps it as an object, needed when you store it or pass it to a non-inline function. crossinline keeps it inlined but forbids non-local returns, needed when the lambda is called from another context (a Runnable, a nested lambda) where returning from the outer function would be impossible. Inline only small higher-order functions — inlining big bodies bloats bytecode.

What they are really testing: Knowing the three and the non-local return rule — the classic mid-level Kotlin question.

fun <T : Comparable<T>> max(a: T, b: T) sets an upper bound: T must be comparable. The default bound is Any?, so write T : Any to forbid nullable type arguments. For more than one bound, use a where clause:

fun <T> sortedTexts(xs: List<T>): List<T>
    where T : CharSequence, T : Comparable<T> = xs.sorted()

What they are really testing: Precision with type parameters, including the nullable default bound.

A coroutine is a computation that can suspend — pause without blocking a thread — and resume later, possibly on another thread. Threads are OS resources: about a megabyte of stack each, expensive to create and to context-switch, so a server cannot have a million of them. Coroutines are objects on the heap; a small thread pool runs many thousands of them, and while one waits for I/O its thread runs others. You write sequential-looking code (val user = api.load(id)) instead of callbacks. The language provides suspend; the kotlinx.coroutines library provides launch, async, dispatchers and Flow. See Module 10.

What they are really testing: The suspend-versus-block distinction, stated precisely.

The compiler rewrites it in continuation-passing style: it gets an extra hidden parameter, a Continuation, and returns Any?. The body becomes a state machine — each suspension point is a label, and local variables that live across suspension points are stored in the continuation object. When a call suspends, the function returns the marker COROUTINE_SUSPENDED and the thread is free; when the result arrives, something calls continuation.resumeWith(result) and execution jumps back to the saved label. That is why a suspend function can only be called from another suspend function or a coroutine builder — it needs a continuation to pass.

What they are really testing: Depth beyond usage: CPS, the state machine and why the calling restriction exists.

launch starts a coroutine for its side effect and returns a Job (to cancel or join); an exception in it propagates to its parent immediately. async returns a Deferred<T>, a future you await() for a result; use it to run things in parallel:

coroutineScope {
    val user = async { api.user(id) }
    val orders = async { api.orders(id) }
    Profile(user.await(), orders.await())
}

What they are really testing: Correct parallel decomposition and the exception-propagation detail.

Every coroutine is launched in a CoroutineScope, which makes it a child of that scope’s Job. The rules: a parent does not complete until all children complete; cancelling a parent cancels all children; a failing child cancels the parent and therefore its siblings. So no coroutine can leak — when a screen’s viewModelScope is cancelled, or a request’s coroutineScope { } fails, everything it started stops. supervisorScope / SupervisorJob change one rule: a child’s failure does not cancel its siblings — used when tasks are independent, like loading several widgets. GlobalScope opts out of all of this, which is why it is discouraged.

What they are really testing: The three rules and when to reach for a supervisor.

A dispatcher decides which thread(s) run a coroutine. Default is a pool sized to the CPU cores, for CPU-bound work (parsing, sorting). IO is a larger, elastic pool (64 threads or the core count, whichever is larger) for blocking calls — JDBC, file I/O, legacy SDKs. Main is the UI thread on Android. withContext(Dispatchers.IO) { … } switches for a block and returns its result. Convention: a suspend function should be main-safe — it switches dispatcher itself so callers never have to think about it. Truly suspending APIs (Ktor client, Retrofit suspend functions, Room) do not need IO at all.

What they are really testing: Main-safety as a design principle, not just which dispatcher exists.

Cancelling a Job only sets a flag; the coroutine stops when it next reaches a suspension point that checks it (every kotlinx suspending function does), which throws CancellationException. A tight CPU loop with no suspension ignores cancellation unless it calls ensureActive() or yield(), or checks isActive. You break cancellation by swallowing CancellationException: catch (e: Exception) around a suspend call, or runCatching { }, catches it and the coroutine keeps running. Rethrow it, or catch specific exception types. Cleanup that must suspend goes in withContext(NonCancellable) inside finally.

What they are really testing: The catch (e: Exception) bug — one of the most common coroutine bugs in real code reviews.

A Flow is cold: nothing runs until someone calls collect, and each collector gets its own execution — like a function that returns many values over time. StateFlow is hot: it always holds a current value, new collectors get the latest value immediately, and equal consecutive values are skipped — the standard holder for UI state. SharedFlow is hot with no required value and configurable replay — for events broadcast to several collectors. stateIn / shareIn turn a cold flow into a hot one within a scope, e.g. stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), initial).

What they are really testing: Cold versus hot, and which one belongs in a ViewModel.

GlobalScope.launch starts a coroutine tied to nothing: it is not cancelled when the screen or request that started it goes away, errors go to no parent, and tests cannot wait for it — a leak by design. Use a scope with a lifecycle (viewModelScope, a request scope, an application scope you inject). runBlocking blocks the current thread until its coroutines finish; it is for main functions and tests (though runTest is better for tests). Inside a coroutine or on the Android main thread it wastes a thread or freezes the UI, and on a limited dispatcher it can deadlock.

What they are really testing: Whether you understand scopes as lifecycles.

A type coming from Java whose nullability Kotlin cannot know, shown in IDE hints as String!. Kotlin lets you treat it as nullable or non-null; if you treat it as non-null and Java returns null, you get a NullPointerException at that line — null safety has a hole at every Java boundary. Defences: declare the Kotlin variable type explicitly (val name: String? = javaUser.getName()), and annotate Java code with @Nullable/@NonNull (JSpecify, JetBrains or AndroidX annotations), which Kotlin reads and enforces.

What they are really testing: Awareness that Kotlin null safety is only as good as its Java boundaries.

They shape how Kotlin code looks from Java. @JvmStatic on a companion or object member generates a real static method, so Java writes Util.parse() instead of Util.Companion.parse(). @JvmField exposes a property as a public field with no getter/setter. @JvmOverloads generates overloads for functions with default arguments. @JvmName renames a function or file class in bytecode — also used to resolve clashes like fun f(xs: List<String>) and fun f(xs: List<Int>), which erase to the same signature.

What they are really testing: Experience maintaining a mixed Java/Kotlin codebase.

Kotlin never forces you to catch or declare exceptions, so a Kotlin function can throw IOException without saying so. Java callers then cannot write catch (IOException e) around it — javac rejects catching a checked exception the method does not declare. Add @Throws(IOException::class) to the Kotlin function to emit the throws clause. Within Kotlin, document thrown exceptions in KDoc, or model expected failures as return values (a sealed result type) instead of exceptions.

What they are really testing: Interop detail plus a design opinion about expected versus exceptional failures.

A SAM (single abstract method) interface can be implemented with a lambda: executor.execute { work() } converts the lambda to a Java Runnable. This works automatically for Java interfaces. For a Kotlin interface you must declare it fun interface:

fun interface Validator { fun validate(s: String): Boolean }

val notBlank = Validator { it.isNotBlank() }

What they are really testing: Knowing why a Kotlin interface does not accept a lambda by default.

class LoggingList<T>(private val inner: MutableList<T>) : MutableList<T> by inner implements the whole interface by forwarding to inner; you override only what you want to change, e.g. add. That is composition without the boilerplate, and a safer alternative to inheriting from a concrete class. Property delegation (val x by lazy { }, var name by Delegates.observable("") { … }, val id by map) moves a property’s get/set logic into a reusable object with getValue/setValue. Android’s by viewModels() and Compose’s by remember { mutableStateOf(…) } are both property delegates.

What they are really testing: Using the language feature as a design tool — composition over inheritance.

@JvmInline value class UserId(val raw: String) wraps exactly one value to give it a distinct type — you can no longer pass an OrderId where a UserId belongs — while compiling to the bare String in most places, so there is no extra object. It is boxed when used as a nullable type, as a generic type argument (List<UserId>), or through an interface it implements. Functions that take value classes get mangled names in bytecode, so Java cannot call them easily. See Module 08.

What they are really testing: Type-safe domain modelling and knowing the performance fine print.