Kotlin Interview Questions

Null safety is a language feature that distinguishes between types that can hold null and types that cannot, catching many null pointer exceptions at compile time instead of runtime. A regular type like String cannot hold null, while a nullable type is written as String?.

val declares a read-only reference that can only be assigned once, similar to final in Java, while var declares a mutable reference that can be reassigned. Kotlin encourages using val by default and reaching for var only when reassignment is genuinely needed.

A nullable type is written with a question mark after the type name, like String?, indicating the variable can hold either a value of that type or null. The compiler then requires you to handle the null case explicitly before using the value in most contexts.

The safe call operator, written as ?., calls a method or accesses a property only if the object isn't null, returning null instead of throwing an exception if it is. For example, person?.name returns null if person is null, rather than crashing.

The Elvis operator, written as ?:, provides a default value to use when the expression on its left is null, like val name = person?.name ?: "Unknown". It's a concise way to handle nulls with a fallback value.

The not-null assertion operator, !!, forces a nullable type to be treated as non-null, throwing a NullPointerException if the value actually turns out to be null. It's generally discouraged except when you're certain the value can't be null and want that certainty enforced explicitly.

A data class is a class specifically designed to hold data, automatically generating useful methods like equals(), hashCode(), toString(), and copy() based on its properties. It's declared with the data keyword before the class definition.

An extension function lets you add new functionality to an existing class without modifying its source code or using inheritance, like fun String.isPalindrome(): Boolean. It's a common way to add utility methods to classes you don't own, including Java's standard library classes.

A class defines a blueprint from which multiple instances can be created. An object declaration defines a class and creates a single instance of it simultaneously, giving you a singleton without needing separate boilerplate to enforce that pattern.

A companion object is an object declared inside a class that lets you define members tied to the class itself rather than to instances of it, similar in purpose to static members in Java. It's accessed through the class name directly.

A lambda expression is an anonymous function that can be passed around as a value, written in curly braces like { x, y -> x + y }. Lambdas are used extensively with Kotlin's collection functions, like map and filter.

A function is defined with the fun keyword and has a name, while a lambda is an anonymous block of code that can be assigned to a variable or passed as an argument. Lambdas are more concise for short, one-off pieces of logic that don't need to be reused elsewhere.

String interpolation lets you embed expressions directly inside a string using the dollar sign, like "Hello, $name" or "Total: ${price * quantity}". It replaces the need for manual string concatenation in most cases.

A when expression is Kotlin's more powerful replacement for a traditional switch statement, letting you match a value against multiple conditions, including ranges and types, and it can return a value directly. It's often used both for control flow and as an expression assigned to a variable.

The == operator checks structural equality, comparing whether two objects have equivalent content, calling equals() under the hood. The === operator checks referential equality, comparing whether two variables point to the exact same object in memory.

Kotlin provides List, Set, and Map as its core collection types, each with both a read-only interface and a mutable variant, like List versus MutableList. This distinction lets you control whether a collection can be modified after creation directly through its type.

A List is read-only, meaning you can't add, remove, or replace elements through that interface, though the underlying collection might still be mutable elsewhere. A MutableList exposes methods like add() and remove(), explicitly allowing modification.

A primary constructor is part of the class header itself, like class Person(val name: String, val age: Int), rather than a separate constructor block inside the class body. Properties declared directly in the primary constructor are automatically created as class properties.

A secondary constructor is an additional constructor defined inside the class body using the constructor keyword, used when a class needs more than one way to be instantiated. Secondary constructors must delegate to the primary constructor, either directly or indirectly.

When a lambda has exactly one parameter, Kotlin lets you omit naming it explicitly and refer to it as it, like list.filter { it > 5 }. This shorthand keeps simple lambdas more concise.

The fun keyword is used to declare a function in Kotlin, like fun greet(name: String): String. Every standalone function or method definition in Kotlin starts with it.

Type inference lets the compiler automatically determine a variable's type based on its assigned value, so you don't need to explicitly declare the type every time, like val age = 25 inferring Int. You can still declare the type explicitly when it improves clarity or when there's no initial value to infer from.

An interface can declare methods with or without implementations and a class can implement multiple interfaces, while an abstract class can hold constructor logic and state but a class can only extend one abstract class. Interfaces in Kotlin can also include default method implementations, unlike older versions of some other languages.

A range represents a sequence of values between a start and end point, created with the .. operator, like 1..10, commonly used in for loops and when expressions. Kotlin also provides until and downTo for creating ranges with different bounds or direction.

The let function executes a block of code using the object it's called on as the argument, commonly combined with the safe call operator to run code only if a nullable value isn't null, like person?.let { print(it.name) }. It's one of Kotlin's several standard scope functions.

A sealed class restricts which classes can inherit from it to a known, limited set defined within the same file or module, which lets a when expression over a sealed class be checked exhaustively at compile time. It's commonly used to represent a fixed set of possible states or outcomes.

An enum class defines a fixed set of named constant values, like enum class Direction { NORTH, SOUTH, EAST, WEST }. Kotlin's enum classes can also hold properties and methods, making them more flexible than a simple list of constants.

Any is the root type of Kotlin's type hierarchy, similar to Object in Java. Unit represents the absence of a meaningful return value, similar to void, and Nothing represents a function that never returns normally, like one that always throws an exception.

A top-level function is a function declared directly in a file, outside of any class, unlike Java where every method must belong to a class. This lets Kotlin code avoid unnecessary utility classes just to hold standalone helper functions.

Default parameter values let you specify a value a parameter should use if the caller doesn't provide one explicitly, like fun greet(name: String = "World"). This reduces the need for multiple overloaded function signatures just to handle optional parameters.

Named arguments let you specify function arguments by their parameter name rather than strict positional order, like greet(name = "Alice", greeting = "Hi"). This improves readability, especially for functions with several parameters of the same type.

An expression body lets you define a function with a single expression after an equals sign, like fun square(x: Int) = x * x, with the return type inferred. A block body uses curly braces and an explicit return statement, needed for functions with more than one statement.

Destructuring lets you unpack an object's properties into multiple variables in a single statement, like val (name, age) = person, commonly used with data classes since they automatically support this through generated component functions. It's also frequently used when iterating over a Map's entries.

The 'in' and 'out' keywords define variance for generic types, with 'out' marking a type as covariant, meaning it can only be produced, not consumed, and 'in' marking it as contravariant, meaning it can only be consumed, not produced. This gives more flexibility when working with generic types in inheritance hierarchies than Java's more limited wildcard system.

The lateinit modifier lets you declare a non-nullable variable without initializing it immediately, deferring initialization until later, commonly used for properties that get set up in a framework lifecycle method rather than a constructor. It only works with var and non-primitive, non-nullable types.

I'd use an enum when each state is simple and doesn't need to carry different associated data. I'd reach for a sealed class when different states need to hold different data, like a Success state carrying a result versus an Error state carrying an exception, since sealed classes support that variation naturally.

I'd wrap the blocking call using withContext(Dispatchers.IO) so it runs on a thread pool suited for blocking work rather than blocking the calling coroutine's dispatcher, which is often the main thread in UI applications. I'd avoid calling blocking code directly inside a suspend function without that context switch, since it would defeat the purpose of using coroutines in the first place.

I'd use apply when configuring an object's properties and wanting to return that same object, let when transforming a value or running code conditionally on a non-null result, and also when running a side effect, like logging, without changing what gets returned. Picking based on what the return value should be and whether the receiver is referenced as it or this usually makes the right choice clear.

I'd wrap the Java API behind a Kotlin-friendly layer that translates nullable Java returns into proper Kotlin nullable types, or into sealed result types where a richer representation of success and failure makes the calling code cleaner. I'd avoid propagating Java's implicit nullability assumptions throughout the Kotlin codebase unchecked, since that undermines the safety Kotlin's type system is meant to provide.

I'd use structured concurrency and try-catch blocks within the coroutine itself for expected failures, and rely on a CoroutineExceptionHandler for unexpected exceptions that would otherwise crash the coroutine's scope. I'd be careful with cancellation exceptions specifically, since catching them too broadly can interfere with a coroutine's ability to be cancelled properly.

I'd consider whether a data class is even the right fit, since its generated equals() is based on all primary constructor properties by default, and if only some properties should count toward equality, I'd either exclude the irrelevant ones from the primary constructor or write a regular class with custom equals() and hashCode() instead. Forcing a data class to behave against its default generated behavior often leads to confusing code.

I'd scope extension functions narrowly to genuinely reusable, well-named utilities, and avoid adding an extension just to save a few characters of typing in one place. I'd also be cautious about extensions on very broad types, like Any, since those can make code harder to reason about by making it unclear where a method actually comes from.

I'd use kotlinx-coroutines-test's TestDispatcher and runTest to control coroutine execution deterministically in tests, rather than relying on real delays or thread timing, which would make tests slow and flaky. I'd also make sure the code under test accepts an injectable dispatcher, so tests can substitute the test dispatcher instead of the code hardcoding Dispatchers.IO or similar.

I'd prefer confining the mutable state to a single coroutine and communicating with it through a Channel or Flow, rather than trying to synchronize direct access from multiple coroutines with locks. When that's not practical, I'd use a Mutex to guard the critical section explicitly rather than relying on unsynchronized access.

I'd typically replace a Java builder pattern with a data class using named arguments and default parameter values, since Kotlin's function call syntax already gives most of the builder pattern's readability benefits without the extra boilerplate. I'd only keep a builder-style approach if the construction logic is genuinely complex enough that named arguments alone don't capture it well.

I'd use a suspend function when the operation produces exactly one result, like a single network response. I'd reach for Flow when the operation genuinely produces a stream of values over time, like live updates from a database or repeated emissions from a sensor.

I'd add explicit null checks at the Kotlin boundary where Java code is called, rather than trusting Java's lack of compile-time null guarantees, and consider annotating the Java code with nullability annotations where possible to improve the inferred platform types Kotlin sees. I'd treat every unannotated Java return value with healthy suspicion until proven otherwise by the actual runtime behavior.

I'd use the inline keyword for small, frequently called higher-order functions, since inlining avoids the overhead of creating a separate lambda object and function call at each use site. I'd avoid inlining large functions though, since that can bloat the compiled bytecode significantly without a meaningful performance benefit.

I'd avoid relying heavily on Kotlin-specific features that don't translate well to Java, like default parameter values, unless the function is also annotated with @JvmOverloads to generate the necessary overloads for Java callers. I'd also be mindful of how Kotlin's null safety types appear to Java callers, since Java code doesn't get the same compile-time enforcement Kotlin provides.

I'd use an extension function when the logic conceptually operates on a specific type and reads naturally as if it were a method on that type, and a plain top-level function when it doesn't clearly belong to any particular type. I'd avoid defaulting everything to extension functions just for the syntax convenience, since overusing them can make it harder to tell where behavior actually lives.

I'd rely on the compiler's exhaustiveness checking for sealed classes, making sure the when expression doesn't include an else branch unless genuinely needed, so adding a new subtype later causes a compile error at every place that needs updating rather than silently falling through. This is one of the clearest practical benefits of sealed classes over a more open type hierarchy.

I'd typically replace it with a Kotlin object declaration, which gives thread-safe lazy initialization of the singleton instance by default without needing the manual double-checked locking boilerplate common in older Java singleton implementations. I'd still review whether the singleton's mutable state is genuinely necessary, since global mutable state carries the same risks in Kotlin as it does in any language.

I'd wrap primitive values that carry specific meaning, like a UserId represented as a raw Int, in a value class so the type system can catch mistakes like passing a raw Int where a UserId was expected. I'd weigh this against the added indirection for very hot code paths, though value classes are specifically designed to avoid runtime overhead in most cases by being inlined at compile time.

I'd default to internal or private visibility for anything not genuinely meant to be part of a module's public surface, rather than leaving everything public by default out of convenience. I'd only widen visibility deliberately when there's a real need for another module or consumer to access it.

I'd return a Job or Deferred from the launching function so the caller has an explicit handle to cancel the operation if needed, rather than only exposing a suspend function with no way to interrupt it once started. I'd also make sure the underlying work checks for cancellation cooperatively, since simply having a Job to cancel doesn't help if the work inside never checks whether it's still active.

I'd use Kotlin's built-in Result type for simple cases where success and failure are the only two outcomes and failure is naturally represented by a Throwable. I'd reach for a custom sealed class when the domain needs more than a binary success or failure distinction, like multiple specific failure reasons each carrying different data.

I'd avoid deeply nesting multiple scope functions like let, apply, and also within a single expression, even though it's syntactically valid, since that quickly becomes hard to read and debug. I'd break the logic into named intermediate variables or separate statements once a chain starts requiring real effort to trace through mentally.

I'd mark a function as suspend only when it genuinely performs asynchronous work or calls another suspend function, rather than marking functions suspend by default out of habit. Marking a purely synchronous function as suspend adds confusion for callers about why it needs a coroutine context when it doesn't actually suspend execution.

I'd check for coroutines launched with a scope that outlives its intended lifecycle, like one tied to GlobalScope holding a reference to a short-lived object, since that's a common source of leaks specific to coroutine-based code. I'd use heap dump analysis tools to trace what's actually holding the reference alive, rather than assuming the coroutine usage is the cause without verifying it.

I'd standardize on a sealed class-based result type for operations that can fail in expected ways, forcing callers to handle both success and failure explicitly rather than relying on exceptions for expected failure paths. I'd reserve actual exceptions for genuinely unexpected, unrecoverable situations, keeping the distinction between expected and unexpected failure clear and consistent across the codebase.

I'd weigh this against how much of the actual business logic is genuinely platform-agnostic versus how much would need platform-specific implementations behind expect and actual declarations anyway. Kotlin Multiplatform pays off well when there's substantial shared logic, but for a thin business logic layer, the added build complexity might not be worth it compared to maintaining separate platform implementations.

I'd check whether long chains of intermediate collection operations are creating unnecessary intermediate collections at each step, since Kotlin's standard collection functions are eager by default. Where the volume of data is large enough to matter, I'd consider using a Sequence instead, which evaluates lazily and can avoid materializing intermediate results.

I'd be deliberate about which classes and functions are genuinely part of the public API versus internal implementation detail, using Kotlin's visibility modifiers strictly rather than defaulting everything to public. I'd also think carefully about default parameter values and function signatures before publishing, since changing them later is a breaking change for consumers in ways that are easy to overlook during initial development.

I'd check whether any suspend function in the chain is catching CancellationException too broadly, like a blanket catch (Exception e) block, since that silently swallows the cancellation signal and breaks structured concurrency's expected behavior. I'd also verify that any long-running computation includes cooperative cancellation checks, like calling ensureActive(), since cancellation in coroutines is cooperative and won't interrupt a tight loop that never checks for it.

I'd watch closely for overuse of the not-null assertion operator, since it's often used as a quick fix to satisfy the compiler rather than genuinely handling the nullability correctly, and push for safe calls or explicit handling instead. I'd also flag platform types coming from Java interop that aren't being deliberately handled, since that's a common place where null safety guarantees quietly leak away.

I'd rely on Kotlin's full interoperability with Java, converting one class or module at a time and verifying behavior with existing tests before moving to the next, rather than attempting a wholesale rewrite. I'd prioritize converting code that would benefit most from Kotlin's safety features first, like classes with a history of null pointer exceptions, to get concrete value from the migration early rather than converting purely for consistency's sake.

I'd use operators like combine or zip to merge multiple Flows into a single stream the UI or business logic layer consumes, keeping each individual Flow focused on a single data source. I'd also be deliberate about which dispatcher each Flow's upstream work runs on, since getting that wrong can either block the wrong thread or introduce unnecessary context switching overhead.

I'd default to synchronous code for logic that's genuinely CPU-bound and doesn't involve waiting on I/O, since coroutines add real complexity that isn't justified without a genuine concurrency or non-blocking need. I'd reserve coroutines for code that specifically benefits from non-blocking I/O or genuine concurrent execution, rather than adopting them reflexively across the whole codebase.

I'd check whether an operator like conflate or a hot Flow implementation like StateFlow is involved, since those intentionally drop intermediate values under backpressure rather than guaranteeing every emission reaches the collector. I'd also verify the collector isn't doing slow work per emission without realizing the upstream Flow's actual buffering and backpressure behavior.

I'd weigh the migration cost against concrete, measurable benefits, like reduced null pointer exception rates or faster development velocity on the parts of the codebase that get touched most often, rather than migrating purely because Kotlin is the newer language. I'd recommend an incremental, interop-based migration prioritized by actual pain points in the existing codebase over a wholesale rewrite, since Kotlin's Java interoperability makes that incremental path genuinely practical.

I'd establish organization-wide conventions around structured concurrency, like banning GlobalScope usage in application code and requiring scopes tied to well-defined lifecycles, enforced through shared linting rules. I'd also build internal training material grounded in real incidents the organization has actually experienced, since abstract coroutine concepts land much better when tied to concrete past mistakes.

I'd evaluate new language features against actual pain points in the codebase rather than adopting them reflexively when a new Kotlin version ships. I'd also stage adoption of experimental or beta features carefully, since building broadly on features that later change or get removed creates real churn for teams depending on them.

I'd frame it around measurable outcomes, like reduced duplicate logic across platform teams or faster time to ship a feature consistently across platforms, rather than technical architecture details. I'd also be upfront about the real learning curve and tooling maturity considerations, since underselling that tends to create friction with leadership partway through the initiative.

I'd mandate use of the standard coroutine testing utilities, like TestDispatcher and runTest, rather than allowing teams to write flaky tests relying on real delays or arbitrary sleep calls. I'd also build shared testing utilities and examples for common patterns, like testing a Flow's emitted sequence, so teams aren't each solving the same testing challenges independently.

I'd require a review process for adopting new dependencies, weighing their Kotlin-first design quality, maintenance activity, and Kotlin Multiplatform compatibility if relevant, since a poorly designed Java-first library can force awkward, non-idiomatic Kotlin code at every call site. I'd also periodically audit existing dependencies, since libraries that lagged behind in adding proper Kotlin support historically have sometimes caught up, changing the calculus for whether to keep an older workaround in place.

I'd track Kotlin's release notes and deprecation timelines actively, budgeting dedicated time each cycle for evaluating and adopting relevant changes rather than letting the codebase drift further from current idiomatic practice over years. A large drift makes eventual version upgrades and onboarding new engineers meaningfully harder, so staying reasonably current is usually cheaper in aggregate than deferring it indefinitely.

I'd combine structured training on Kotlin's core differentiators, like null safety and coroutines, with hands-on mentorship on real migration or greenfield Kotlin work, since abstract language feature knowledge doesn't automatically translate into writing genuinely idiomatic Kotlin. I'd also actively discourage 'Java written in Kotlin syntax' patterns during code review, since that's a common phase engineers pass through without realizing it undermines much of Kotlin's actual value.

I'd weigh this realistically against how unlikely such a migration actually is in practice, given Kotlin's strong JVM ecosystem position and broad industry adoption, rather than treating it as a serious near-term risk. I'd focus governance energy instead on more probable risks, like inconsistent coroutine usage or Kotlin Multiplatform tooling maturity, rather than hedging heavily against an unlikely future migration.

I'd start with a small, well-bounded piece of genuinely shared logic, like core business rules or a networking layer, as a pilot before committing to broader adoption, since Kotlin Multiplatform's tooling and team coordination overhead are real costs that need validating against actual benefit first. I'd also make sure each platform team has a genuine stake in the shared code's direction, since a shared module governed unilaterally by one platform team tends to create friction with the others.

I'd treat shared Kotlin infrastructure, like a common coroutine utilities library or a shared linting configuration, as genuine infrastructure with dedicated ownership, rather than a side project maintained by whichever team happens to have time. Under-resourcing it tends to lead to product teams each solving the same problems independently, which undermines the entire point of having shared tooling in the first place.

I'd converge on a small number of standard patterns for representing success, failure, and loading states, rather than letting every team invent its own slightly different sealed class hierarchy for the same conceptual problem. Consistency here matters because inconsistent error handling patterns make it much harder for engineers to move between teams and immediately understand how a given codebase handles failure.

I'd make the tradeoff visible with data, like the rate of null-safety-related incidents or code review friction tied to non-idiomatic patterns, so it becomes a shared decision with engineering leadership rather than an individual reviewer's frustration. Reserving explicit capacity for addressing idiomatic quality and technical debt, rather than treating it as leftover time, is usually what keeps it from being perpetually deprioritized.

I'd invest early in shared tooling, like a common linting configuration and reusable coroutine utilities, so new teams inherit good defaults rather than each rediscovering the same patterns and pitfalls independently. I'd also build a lightweight community of practice across teams, since sharing what's working, especially around coroutine and Flow usage, tends to surface systemic issues faster than any single team could catch alone.

I'd tie the investment to concrete outcomes leadership already tracks, like reduced null-pointer-related production incidents or faster onboarding for new engineers, using real data from the organization's own history where possible. Framing it around measurable reliability and velocity, rather than language purity for its own sake, tends to land much better with business-focused stakeholders.

I'd anchor the vision to where the business expects to scale, like new platforms that might benefit from Kotlin Multiplatform or growing concurrency demands that call for more disciplined coroutine architecture, rather than chasing every new Kotlin language feature reflexively. I'd also keep the vision revisited regularly, since Kotlin itself evolves quickly enough that a plan set once and never reassessed tends to go stale.

I'd push hard against that expertise living in just a few people's heads, requiring architectural decisions around things like coroutine scope design to be documented and pairing to be a normal part of how critical systems get built. Losing a senior engineer should be a setback, not a crisis, and that only holds if the knowledge was genuinely distributed across the team beforehand.

I'd build the case with concrete evidence, like maintenance cost or how the old patterns block adopting newer structured concurrency capabilities, and pair it with a realistic, staged migration path rather than an abrupt cutoff. I'd also involve the teams most dependent on it in shaping that migration, since a deprecation with no input from affected teams tends to stall or get quietly worked around.

I'd focus on making genuinely idiomatic patterns the path of least resistance, through shared libraries, linting rules, and code review presence across teams, rather than relying on a style guide nobody reads closely. Real influence at this level comes from what you make convenient to do correctly, beyond just what you formally mandate.

I'd keep postmortems focused on systemic gaps, like missing linting coverage for a known risky pattern or inadequate training on structured concurrency, rather than blaming the individual engineer who wrote the code, since a punitive culture just teaches people to hide problems instead of surfacing them. I'd also track whether the resulting fixes, like new lint rules, actually get built and adopted, rather than staying a documented good intention.

I'd stay closely involved in a meaningful slice of real Kotlin code, since that's what keeps my intuition sharp and my recommendations grounded in what's actually happening in production rather than theoretical best practices. The organizational influence work, like shaping shared standards, has to be scoped so it doesn't crowd out that hands-on involvement entirely.

I'd define levels around observable capability, like the complexity of concurrent systems someone can architect independently or their ability to diagnose subtle coroutine cancellation bugs, rather than vague seniority labels. I'd also make sure the framework values deep language and concurrency expertise as a legitimate senior path, not only one that funnels toward general engineering management.

I'd break the initiative into phases that each deliver measurable value along the way, like a specific shared module proving out real cross-platform benefit, so leadership sees real progress rather than betting everything on a distant finish line. I'd also revisit the business case periodically, since a multi-year initiative needs to stay justified as priorities and Kotlin's own ecosystem shift underneath it.

I'd bring concrete data showing the real cost of the current tradeoff, like elevated bug rates in code that still carries Java-style patterns or slower onboarding for engineers unfamiliar with those inconsistencies, since abstract code-quality arguments rarely move a room focused on quarterly goals. I'd also propose a specific, time-boxed remediation plan rather than an open-ended ask, since that's usually easier for leadership to actually commit to.

I'd involve product teams early in shaping new shared conventions and libraries rather than mandating standards designed in isolation, since standards built with real input tend to actually get adopted rather than worked around. Consistently shipping tooling that measurably reduces friction for those teams builds far more trust than documentation or mandates alone.

I'd prioritize making sure the patterns and standards I helped establish keep making sense without needing me to personally sustain them, which means investing in documentation, mentorship, and distributed ownership rather than being the one person who understands the trickiest coroutine architecture decisions. A good sign it worked is that the codebase's Kotlin quality and consistency hold up well after I've moved on to something else.