Kotlin interviews in 2026 test two things: whether you understand coroutines well enough to write correct concurrent code, and whether you use Kotlin's type system — null safety, sealed classes, data classes — to prevent bugs at compile time. This guide covers both Android and backend Kotlin tracks.
Start Free Practice Interview →Kotlin has become the default language for Android development and is gaining serious traction on the server side with Ktor and Spring Boot. Kotlin interviews have matured beyond syntax knowledge into deep questions about coroutines, type system design, and platform-specific patterns.
Coroutines are the centerpiece of most Kotlin interviews. Beyond coroutines, expect questions on null safety, sealed classes and algebraic data types, extension functions, scope functions, and functional programming patterns. Kotlin interviews split into two tracks: Android Kotlin (Jetpack Compose, ViewModel, StateFlow) and Backend Kotlin (Ktor, Spring Boot, kotlinx.serialization). This guide covers both — identify your track and focus accordingly.
Coroutines and structured concurrency — the dominant topic. suspend functions, CoroutineScope, dispatchers, launch vs async, Flow, exception handling with SupervisorJob, and real-world patterns like debouncing and retry logic.
Null safety and the type system — nullable types (String?), safe call (?.), Elvis (?:), not-null assertion (!!), smart casts, data classes, sealed classes, object declarations, and platform types from Java interop.
Extension functions and scope functions — adding methods to existing classes, choosing between let, apply, run, also, and with.
Functional programming — lambdas, higher-order functions, collection operators (map/filter/fold/flatMap), sequences for lazy evaluation, and inline functions for zero-overhead lambdas.
Kotlin-Java interop — @JvmStatic, @JvmOverloads, @JvmField, SAM conversions, nullability annotations, and designing Kotlin APIs callable from Java.
Platform-specific knowledge — Android: Jetpack Compose, ViewModel, StateFlow/SharedFlow, Room, Hilt/Koin, Gradle Kotlin DSL. Backend: Ktor routing and plugins, Spring Boot with Kotlin, kotlinx.serialization, database access patterns.
If you're coming from another language — especially Java — understanding what Kotlin interviews emphasize differently helps focus preparation.
| Dimension | Kotlin Interview | Java Interview | Dart/Flutter Interview | Swift/iOS Interview |
|---|---|---|---|---|
| Null handling | Nullable types (?), safe calls (?.), Elvis (?:), smart casts. Built into type system, always asked | Optional<T>, null checks, annotations. Library concern, not language guarantee | Sound null safety (Dart 2.12+). late keyword, required keyword | Optionals (?), optional chaining, nil-coalescing (??), guard let |
| Concurrency | Coroutines with structured concurrency. suspend, Flow, Dispatchers. Largest interview topic | Threads, ExecutorService, CompletableFuture, virtual threads (Loom). More verbose | async/await with Futures, Isolates, Streams. Single-threaded event loop | async/await with Swift Concurrency, actors. Similar philosophy to Kotlin |
| Type system | Data classes, sealed classes, extension functions, smart casts, delegation. Expressiveness + safety | Classes, interfaces, generics, records (16+), sealed classes (17+). More verbose | Classes, mixins, extension methods, sealed classes | Structs vs classes, protocols, enums with associated values, property wrappers |
| Functional features | First-class lambdas, higher-order functions, collection operators, sequences, inline. Heavily tested | Streams API, lambdas (Java 8+), method references. Bolted on, not built in | First-class functions, collection operators, cascade notation | Closures, map/filter/reduce, protocol-oriented programming |
| Platform focus | Android (Compose, ViewModel, Room) or Backend (Ktor, Spring Boot). Varies by track | Enterprise (Spring, microservices, JVM tuning). Android increasingly prefers Kotlin | Flutter (widgets, state management, platform channels). Almost always Flutter | iOS/macOS (SwiftUI/UIKit, Combine, Core Data). Always Apple-focused |
| Interop | Kotlin-Java interop (@JvmStatic, platform types, SAM). Always asked — codebases mix both | Rarely asked — Java is the base language | Platform channels, FFI for native features | Swift-ObjC bridging headers. Less common as pure Swift grows |
These questions test whether you've internalized Kotlin's idioms or are still writing Java with Kotlin syntax. The difference is immediately obvious to interviewers.
Null safety is Kotlin's most visible feature and the most common interview opener. It immediately shows whether you think in Kotlin or still think in Java.
Types are non-nullable by default. String can never be null; String? can. The compiler enforces this at compile time. Tools: ?. (safe call — returns null if receiver is null), ?: (Elvis — default when left side is null), !! (not-null assertion — use sparingly), let for scoped null checks, and smart casts (after null check, compiler narrows type automatically). Platform types: Java code returns String! — Kotlin doesn't know nullability. This is where NPEs sneak back in.
Kotlin's null safety is built into the type system, not bolted on like Java's Optional. Every type is non-nullable by default — String means this value can never be null. If it might be null, you declare String?. The compiler enforces this statically, so NullPointerExceptions are essentially eliminated for pure Kotlin code. The three main tools are safe call ?. for chaining on nullable values, Elvis ?: for providing fallbacks, and smart casts that narrow the type after a null check. The let scope function is useful for performing actions only when non-null. The !! operator exists for cases where you know a value is non-null but the compiler can't prove it — but overusing it defeats the purpose of null safety. The one gap is Java interop: Java methods return platform types like String!, meaning Kotlin doesn't know nullability. This is where NPEs can still occur — adding @Nullable and @NonNull annotations to Java code matters.
Sealed classes are one of Kotlin's most powerful features for state modeling. Tests whether you use them effectively.
Sealed classes restrict which classes can inherit — direct subclasses must be in the same package/module. The compiler knows all cases, enabling exhaustive when expressions. Unlike enums, each subclass can have its own properties and state. Use enums for simple fixed value sets; sealed classes when each variant carries different data. Sealed interfaces (Kotlin 1.5+) allow multiple inheritance. Idiomatic for: UI state, network results, navigation events, domain modeling.
let, apply, run, also, and with.Scope functions are used constantly in idiomatic Kotlin. Choosing the wrong one shows you don't think in Kotlin yet.
Differ on two axes: context reference (this or it) and return value (lambda result or context object). let — it, returns lambda result. Null checks, transformations. apply — this, returns context object. Object configuration (builder-like). run — this, returns lambda result. Computing a result with an object. also — it, returns context object. Side effects (logging, validation). with — this, returns lambda result. Multiple operations on same object.
Data classes are one of Kotlin's most-used features. Tests whether you understand what the compiler generates and the gotchas.
Auto-generate equals(), hashCode(), toString(), copy(), and componentN() — all based on primary constructor properties ONLY. Properties in class body are NOT included in equality or toString. Limitations: can't be abstract, open, sealed, or inner. copy() is shallow. Destructuring via component1(), etc. Gotcha: a property declared in the class body doesn't participate in equality — a common source of bugs.
Extension functions are a core Kotlin idiom that doesn't exist in Java. Tests whether you understand both the power and constraints.
Add methods to existing classes without modifying them. Compiled to static methods — receiver passed as first argument. Implications: (1) resolved statically, not dynamically (compile-time type determines call), (2) can't access private/protected members, (3) member function with same signature always wins. Best practices: use for utility functions that logically belong to a type, not for everything.
val, var, and const val? What about lateinit?Fundamentals question testing understanding of Kotlin's approach to immutability and initialization.
val is read-only reference (object itself can still be mutable). var is fully mutable. const val is compile-time constant — must be primitive or String, top-level or in object/companion. lateinit for non-null var that can't be initialized in constructor (common in Android with DI). Check with ::property.isInitialized.
Coroutines are the most important section for Kotlin interviews. Expect at least two or three coroutine questions, and in senior interviews, significantly more.
The most common coroutines question. Tests whether you understand the model at a fundamental level, not just the API.
Coroutines are lightweight, suspendable computations. Unlike threads, they don't map 1:1 to OS threads — thousands share a small pool. suspend functions pause without blocking the thread. Structured concurrency: every coroutine runs in a CoroutineScope. The scope doesn't complete until all children complete. If cancelled, all children cancel. Prevents fire-and-forget leaks. Key difference: creating a coroutine is free (object allocation), suspending doesn't block, cancellation propagates through scope hierarchy.
Coroutines are lightweight, suspendable computations managed by the Kotlin runtime rather than the OS. You can launch hundreds of thousands because they don't each consume an OS thread. When a coroutine suspends — say, waiting for a network response — the thread goes back to the pool for other work. But the really important concept is structured concurrency. Every coroutine runs inside a CoroutineScope, creating a parent-child relationship. The parent doesn't complete until all children complete. If the parent is cancelled, all children cancel. This prevents resource leaks — in Android, coroutines in a ViewModel's scope auto-cancel when the ViewModel clears. No manual cleanup. GlobalScope.launch breaks this — it's unstructured and should be avoided in production.
launch and async. When do you use each?Direct practical question. Getting it wrong signals surface-level coroutine knowledge.
launch returns a Job — fire-and-forget (no result). Use for: UI updates, DB writes, analytics. async returns Deferred<T> — a future with a value. Use for: parallel decomposition where you need results. Critical difference: launch propagates exceptions to parent immediately; async stores the exception and throws on await(). Anti-pattern: async { ... }.await() with immediate await gains no concurrency — same as calling directly.
Dispatcher choice affects performance and correctness. Tests whether you know which work goes on which thread pool.
Dispatchers.Main — UI thread (Android). Dispatchers.IO — blocking I/O (network, disk, DB), elastic thread pool. Dispatchers.Default — CPU-intensive (parsing, sorting), sized to CPU cores. Dispatchers.Unconfined — runs on caller's thread until first suspension, rarely used in production. Use withContext to switch dispatchers. Best practice: suspend functions should be main-safe — internally switch with withContext so callers don't need to know.
Flow is Kotlin's reactive streams solution. Tests understanding of cold vs hot streams and modern data flow patterns.
Flow is a cold, asynchronous stream on coroutines. Cold: doesn't produce values until collected. StateFlow is hot with a current value (replaces LiveData). SharedFlow is hot, broadcasts to multiple collectors. Advantages over LiveData: operators (map, filter, debounce, combine), works on any dispatcher, usable in non-Android code. Advantages over RxJava: smaller API, no Disposable management, built on coroutines. Use stateIn() to convert cold Flow to StateFlow in ViewModels.
Exception handling is the trickiest part of coroutines. Separates real coroutine experience from tutorial knowledge.
Default: child failure cancels parent, which cancels all siblings. SupervisorJob changes this — child failure doesn't cancel parent or siblings. Use supervisorScope when independent tasks shouldn't affect each other. CoroutineExceptionHandler is a last-resort handler. Important: try/catch around launch does NOT catch launched coroutine exceptions — they propagate through the Job hierarchy. For async, exception is stored and rethrown on await().
Practical coroutine pattern combining suspend functions, delay, and exception handling.
Loop with delay() (non-blocking) and exponential calculation. Generic to work with any suspend function. Each retry doubles the delay, capped at a maximum. Last attempt lets exception propagate. Use coerceAtMost for delay cap.
Coroutine questions generate the deepest follow-ups in Kotlin interviews. Our AI simulator generates follow-up questions based on your answers and scores your technical depth, code correctness, and communication clarity.
Start Free Practice Interview →Tailored to Kotlin developer roles. No credit card required.
Kotlin's functional features are used in virtually every codebase. Interviewers test whether you write idiomatic functional code and understand performance implications.
Tests understanding of lazy vs eager evaluation and performance optimization — a key practical skill.
Collection operations are eager — each step creates an intermediate list. Sequences are lazy — elements processed one at a time through the entire chain. Sequences for: large collections, long chains, short-circuiting with take/first. Collections for: small collections where sequence overhead isn't worth it, or when random access is needed. Key: sequences enable short-circuiting — .take(10) on a sequence stops after 10 matches, collections process everything.
Intermediate concept that directly affects performance. Tests understanding of compiler optimizations.
Without inline, every lambda creates an object (and closure). inline inlines both function body AND lambda at call site — zero allocation. This is why let, apply, map, filter are all inline. Also enables reified type parameters — type available at runtime (normally erased by JVM). noinline prevents inlining a specific parameter (needed to store lambdas). crossinline prevents non-local returns.
Practical coding question testing fluency with Kotlin's collection API and functional thinking.
Demonstrate multi-step transformation using map, filter, groupBy, flatMap, associate, partition, fold. Show concise, readable chains. Key operators: groupBy for categorization, flatMap for flattening nested collections, associate for creating maps, partition for splitting by predicate, fold for accumulation.
Kotlin interviews split into two tracks. Android roles focus on Jetpack, lifecycle, and UI patterns. Backend roles focus on Ktor/Spring, serialization, and server-side concurrency.
State management is the core architectural question for Compose. Tests whether you understand the reactive model.
Unidirectional data flow: ViewModel holds state as StateFlow, Compose observes with collectAsStateWithLifecycle(), user events flow up to ViewModel. State hoisting lifts state into ViewModel for testability. remember { mutableStateOf() } for ephemeral UI state (dropdown open, animation). rememberSaveable survives configuration changes. derivedStateOf for computed state. Key distinction: Compose state for ephemeral UI state, StateFlow in ViewModel for business data.
Almost every Kotlin codebase interacts with Java. Tests practical mixed-codebase experience.
Java types appear as platform types (String!) — Kotlin doesn't know nullability. Treat as nullable to be safe. @JvmStatic exposes companion members as Java statics. @JvmOverloads generates Java overloads for default parameters. @JvmField exposes property as a field (no getter/setter). SAM conversion: Kotlin lambdas auto-convert to Java functional interfaces.
Tests backend Kotlin knowledge. Ktor is Kotlin-native and coroutine-first.
Ktor uses plugins for capabilities (content negotiation, auth, CORS). Routing is a coroutine-aware DSL — every handler is a suspend function. Use kotlinx.serialization for JSON with @Serializable data classes. Ktor vs Spring Boot: Ktor is lighter, coroutine-first, Kotlin DSLs. Spring has larger ecosystem, more enterprise features. Spring Boot's Kotlin support is excellent — controllers work with suspend functions.
Kotlin coding questions test whether you write idiomatic Kotlin — using the language's features for concise, readable code. Interviewers notice Java-style code in Kotlin syntax.
Tests practical use of sealed classes, extension functions, and functional error handling.
Sealed class for ValidationResult (Valid, Invalid with error list). Type alias Validator<T> as a function type. Compose validators with a validateAll extension that accumulates errors from all validators. Individual validators are functions returning ValidationResult. Exhaustive when on result.
Combines coroutines (Mutex for thread safety), generics, and practical API design.
Use Mutex (coroutine-aware, non-blocking) instead of synchronized (blocks thread). Store entries with timestamps, check expiration on read. getOrPut method prevents duplicate computation. Use kotlin.time.Duration and TimeSource.Monotonic for reliable timing.
DSL building is a uniquely Kotlin skill combining extension functions, lambdas with receivers, and @DslMarker. Senior-level question.
Use lambdas with receivers (block: HtmlElement.() -> Unit) so builder methods are available inside the lambda. @DslMarker annotation prevents accidental access to outer scope receivers. apply to configure elements. Result: a DSL that reads like a custom language for building HTML trees.
Kotlin behavioral questions focus on migration decisions (Java to Kotlin), working in mixed-language codebases, and choosing between Android and backend patterns.
Almost every Kotlin team has dealt with Java-to-Kotlin migration. Tests practical experience and incremental adoption.
STAR format. Typical strategy: new files in Kotlin, convert utility classes first (low risk), gradually migrate core classes. IntelliJ auto-converter as starting point (needs manual cleanup). Add nullability annotations to Java code that Kotlin calls. Discuss what improved (null safety, conciseness, coroutines) and challenges (build time, team ramp-up, mixed-language debugging).
Tests architectural judgment and practical trade-off reasoning in real Kotlin projects.
Prefer coroutines for new Kotlin code (native, structured concurrency, simpler). Keep RxJava if heavily used and migration cost is high (bridge with Flow.asObservable() and Observable.asFlow()). Callbacks only for simple one-shot operations. Trade-offs: coroutines have simpler error handling/cancellation, RxJava has more operators, callbacks are simplest but lead to callback hell.
Kotlin teams often have mixed experience (especially during Java transitions). Tests collaboration and mentoring.
Establish team Kotlin style guide (scope function conventions, coroutine patterns). Pair programming for complex features (especially coroutines). Code reviews that explain WHY something is more idiomatic. Gradual adoption: start with null safety and data classes, add coroutines, then sealed classes and DSLs.
Both. The guide covers core Kotlin topics (coroutines, null safety, sealed classes, functional programming) that apply to all roles, plus dedicated sections for each track. Android interviews focus on Jetpack Compose, ViewModel, StateFlow, lifecycle-aware coroutines, and Hilt/Koin. Backend interviews focus on Ktor or Spring Boot, server-side coroutines, kotlinx.serialization, and database access patterns.
Coroutines are the single most important topic. Expect at least two to three coroutine questions covering structured concurrency, suspend functions, dispatchers, Flow, and exception handling. For Android roles, lifecycle-aware scopes and StateFlow are particularly important. For backend roles, server-side coroutine patterns and concurrent request handling come up frequently.
You need to understand Kotlin-Java interop — platform types, nullability annotations, @JvmStatic, @JvmOverloads, and SAM conversions. You should identify potential NPE risks when calling Java from Kotlin. Deeper Java knowledge helps for backend roles but isn't mandatory for Android-first positions. See our Java developer interview guide for Java-specific preparation.
Most Kotlin interviews include at least one coding problem in a shared editor. Interviewers want to see idiomatic Kotlin — data classes, sealed classes, extension functions, collection operators, and coroutines rather than Java-style code. Practice writing without IDE auto-complete and know common standard library functions from memory.
Kotlin interviews focus on language features absent in Java — coroutines, null safety, sealed classes with exhaustive when, extension functions, scope functions, and DSL building. Java interviews emphasize OOP design patterns, Spring, JVM tuning, and threading. Kotlin interviews tend to be more practical — interviewers want working code, not design pattern taxonomy.
For Android Kotlin roles in 2026, Jetpack Compose is the expected default. Understand Compose's declarative model, state hoisting, recomposition, side effects (LaunchedEffect, DisposableEffect), and navigation. Traditional View system knowledge is still valuable for legacy code, but Compose is what interviewers prioritize. See our Android developer interview guide for more.
Upload your resume and the job description. Our AI generates Kotlin-specific questions based on the role — covering coroutines, null safety, sealed classes, functional programming, and platform-specific patterns for both Android and backend tracks. Practice with timed responses, camera on, and detailed scoring on technical accuracy and communication. No video is recorded or stored.
Start Free Practice Interview →Personalized Kotlin developer interview prep. No credit card required.