Kotlin Backend Developer Top 100 Interview Questions

Most coroutine bugs come from breaking structured concurrency, mixing blocking and suspending code or mishandling cancellation and exceptions.

Common mistakes:

1. Global scope launches: fire-and-forget coroutines that are never cancelled, never awaited and whose failures disappear.
2. runBlocking in request handlers or inside coroutines, which blocks threads and can deadlock.
3. Blocking calls on the default dispatcher, such as synchronous database drivers or Thread.sleep.
4. Swallowing CancellationException with broad catch blocks or runCatching, so cancelled work keeps running.
5. Sequential awaits: async { a() }.await() followed by async { b() }.await(), which runs the calls one after the other.
6. Unbounded concurrency: launching a coroutine per item without limits.
7. Thread-local state: values stored in thread locals are lost when a coroutine resumes on another thread; use coroutine context elements instead.
8. Creating new dispatchers or thread pools per request, which leaks threads.

How to prevent them: code review checklists, static analysis rules for coroutine misuse, tests that check cancellation and a small set of shared helpers for timeouts, retries and blocking calls.

Interview tip: describing a real bug caused by a swallowed cancellation exception is one of the most convincing ways to show hands-on coroutine experience.

Use the coroutines test utilities, which run suspend code in a test scope with virtual time. Delays complete instantly while the scheduler tracks the passage of time, so tests of timeouts, retries and periodic work run in milliseconds and are deterministic.

Key techniques:

1. runTest { ... } runs a test body as a coroutine and fails the test if any child coroutine fails or is left running.
2. Virtual time: delay(10.minutes) inside the test completes immediately; advanceTimeBy and advanceUntilIdle control the scheduler.
3. Inject dispatchers: pass dispatchers into classes instead of hard-coding them, so tests can substitute the test dispatcher.
4. Inject time sources and clocks for code that reads the current time.
5. Test cancellation: cancel the job and assert that cleanup ran and nothing kept working.
6. Test flows by collecting into a list, or with helpers that assert emitted values in order.

Common pitfalls:

• Mixing real threads or real delays into tests, which makes them slow and flaky.
• Forgetting to advance time, so a test waits for a timer that never fires.
• Using runBlocking in tests of time-based code, which waits for real time.

Wrap the callback API with suspendCancellableCoroutine. The block registers callbacks that resume the coroutine with a value or an exception, and an invokeOnCancellation handler cancels the underlying operation if the coroutine is cancelled first.

Steps:

1. Start the operation inside the suspendCancellableCoroutine block.
2. In the success callback, call resume(value).
3. In the failure callback, call resumeWithException(error).
4. Register invokeOnCancellation { operation.cancel() }, so cancelled coroutines do not leave work running.

Rules:

• Resume exactly once; callbacks that can fire several times need guards, or a flow instead.
• Handle late callbacks: after cancellation, a callback may still arrive; it must be ignored safely.
• Use the cancellable variant, not the plain one, so structured cancellation works.

For streams of callbacks, such as listeners that fire repeatedly, use callbackFlow, which registers the listener when collection starts and unregisters it when collection stops.

This pattern lets older asynchronous libraries fit cleanly into coroutine code with timeouts and cancellation.

Loop over attempts, catch only transient failures, wait an exponentially growing delay with random jitter between attempts and rethrow the last failure when attempts run out. In coroutine code, the wait is delay, which suspends instead of blocking; injecting the wait function makes the logic easy to test.

Design points:

1. Retry only transient errors, such as timeouts or 503 responses, using a specific exception type or a predicate.
2. Exponential delay: base × 2^(attempt − 1), capped at a maximum.
3. Jitter: randomize part of each delay, so many instances do not retry at once.
4. Never retry cancellation: rethrow CancellationException immediately in suspending versions.
5. Respect the overall deadline: retries must fit inside the caller's timeout.
6. Idempotency: retry only operations that are safe to repeat, or use idempotency keys.

Using Duration from the standard library keeps units explicit and avoids mixing milliseconds and seconds.

Kotlin uses the JVM's threads and memory model. Without synchronization, a change made by one thread may not be visible to another, and compound operations such as count++ are not atomic, so two threads can lose each other's updates.

Tools for thread safety:

• synchronized(lock) { ... }: mutual exclusion and visibility for a block; keep it short.
• @Volatile: makes reads and writes of a single field visible across threads, but does not make compound updates atomic.
• Atomic types: lock-free counters and references for single values.
• Immutable objects shared after construction, which need no synchronization.
• Concurrent collections from the platform for shared maps and queues.

In coroutine code: prefer Mutex, atomic values or confinement, because synchronized blocks the thread and cannot contain suspension points.

Good practices:

1. Document which lock protects which data.
2. Avoid holding locks during input and output.
3. Acquire several locks in one fixed order.
4. Test concurrent code under load, since races rarely appear in simple tests.

Kotlin services run on the JVM's garbage-collected heap. Allocation is very fast, but collections consume processor time and, depending on the collector, can pause application threads. Heap sizing and allocation habits therefore affect latency and cost.

What to configure:

1. Heap size relative to the container: set the maximum heap as a percentage of the container's memory, leaving room for threads, metaspace, direct buffers and native libraries.
2. Collector choice: the default general-purpose collector balances throughput and pauses well for most services; low-pause collectors suit large heaps with strict latency targets, at some throughput cost.
3. Garbage collection logging, enabled in production, so pauses and frequency can be analyzed.

Reducing pressure from Kotlin code:

• Avoid creating large intermediate collections in hot paths; use sequences or loops.
• Watch boxing of primitive values in generic collections, such as List<Int>; primitive arrays avoid it.
• Value classes avoid wrapper allocations in many cases.
• Be careful with lambdas that capture variables in hot loops, unless the higher-order function is inline.

Measure first: look at allocation rates, pause times and heap after collection before tuning, and change one setting at a time.

The JVM has rich built-in diagnostics. Start with metrics to locate the problem, then use the right profile: processor, allocation, lock contention or heap contents.

Tools and signals:

1. Runtime metrics: processor use, heap and garbage collection, thread counts and pool usage, exported continuously.
2. Built-in flight recording: a low-overhead recorder in the JVM that captures processor samples, allocations, locks, input and output and garbage collection events, suitable for production.
3. Sampling profilers that produce flame graphs of where processor time goes.
4. Thread dumps to find blocked or stuck threads, including coroutine dispatcher threads blocked by mistake.
5. Heap dumps to find what holds memory.
6. Coroutine debugging: debug probes and agents that list active coroutines and their suspension points.

A typical workflow:

• Reproduce the problem under realistic load.
• Record for a few minutes, then examine the hottest methods, the largest allocators and the longest waits.
• Fix the biggest cost and measure again with the same load.

Remember warm-up: the just-in-time compiler optimizes hot code after it runs for a while, so measure after a warm-up period.

Confirm that the heap after garbage collection keeps growing under steady traffic, take heap dumps at two points in time and compare which objects increase and what keeps them reachable.

1. Confirm the trend: old-generation usage after collections rising over hours, eventually leading to out-of-memory errors or constant collections.
2. Capture heap dumps, ideally automatically when an out-of-memory error occurs, plus a manual one earlier for comparison.
3. Compare dominant objects: look at the largest retained sizes and the types whose counts grow.
4. Follow paths to roots to find the long-lived structure that holds them.

Common causes in Kotlin services:

• Unbounded caches in object singletons or companion objects.
• Collections in long-lived scopes, such as maps of sessions that are never cleaned up.
• Coroutine leaks: coroutines launched in an application scope that never finish, each holding its captured data.
• Listeners and callbacks registered but never removed.
• Large buffers held by flows with big replay caches.
• Thread locals in thread pools, which keep values alive as long as the thread.

After the fix, confirm the heap levels off under the same load, and alert on heap growth after collection.

Virtual threads are lightweight threads provided by the JVM: blocking calls on them park the virtual thread instead of blocking an operating system thread. They make blocking-style code scale, much as coroutines make suspending code scale, but the two models offer different features.

Choosing:

1. Coroutine-based frameworks and libraries: coroutines give the richest, safest concurrency model in Kotlin.
2. Large codebases built on blocking libraries: virtual threads can raise concurrency with few code changes.
3. Both together: coroutines can run on a dispatcher backed by virtual threads, which helps when wrapping many blocking calls.

Whichever model you use, limits on connections and downstream calls still apply; cheap threads do not make databases faster.

Use the standard library's kotlin.time API: Duration for amounts of time, TimeSource and time marks for measuring elapsed time and an injected clock or time source wherever code depends on the current time. Tests then control time precisely instead of waiting.

Key types:

• Duration: typed amounts, such as 15.minutes, with arithmetic and readable printing, which prevents unit mix-ups.
• TimeSource.Monotonic: a clock for measuring elapsed time that never jumps backwards.
• measureTime { ... } and measureTimedValue { ... } for timing blocks.
• TestTimeSource: a time source tests can move forward manually.

Design guidelines:

1. Inject time into classes that check expiry, rate limits or timeouts.
2. Use monotonic time for durations and wall-clock time only for timestamps shown to users or stored.
3. Store timestamps in UTC, and convert to time zones only for display.
4. In coroutine tests, virtual time from the test scheduler controls delay and timeouts.

The server accepts the connection and hands the request to the application's pipeline. Interceptors or middleware run first, then routing selects a handler, the request body is deserialized into Kotlin types, the handler runs, usually as a coroutine, and the result is serialized into the response.

flowchart LR
  A["Server accepts request"] --> B["Plugins or middleware: logging, auth, errors"]
  B --> C["Routing to a handler"]
  C --> D["Deserialize and validate body"]
  D --> E["Handler coroutine calls services"]
  E --> F["Serialize result"]
  F --> G["Response sent"]

What developers should know:

1. Handlers run concurrently, so shared services must be safe to use from many coroutines at once.
2. Each request has a coroutine scope that is cancelled when the client disconnects or the request times out; pass that context down instead of starting unscoped work.
3. Blocking calls inside handlers tie up server threads; use suspending clients or move blocking work to a suitable dispatcher.
4. Error handling belongs in one place, mapping exceptions and failure results to consistent responses.
5. Serialization settings, such as how unknown fields and nulls are handled, are part of the API contract.

The same flow applies across Kotlin web frameworks; only the names of the components differ.

Separate the raw request shape from the validated domain command. The request model mirrors the JSON and allows missing or invalid values; a validation step converts it into a command with non-null, checked values, or into a list of errors. Business code only ever sees the validated type.

Why two types:

• The JSON may be missing fields or contain wrong values, so the raw model uses nullable types.
• The domain command uses non-null types and value classes, so invalid data cannot reach the service.

Validation practices:

1. Collect every error, not just the first, so clients can fix everything in one round trip.
2. Normalize values while validating, such as trimming whitespace and lowercasing emails.
3. Return a sealed result of valid or invalid, rather than throwing for expected failures.
4. Map invalid results to status 400 or 422 with field-level messages in one error format.
5. Keep rules close to the domain, such as quantity limits, so they are reused by every entry point.

Represent expected business failures as values in a sealed hierarchy, returned alongside success, and keep exceptions for unexpected problems. Callers must handle each outcome, the compiler checks that when covers every case and the API layer maps each failure to the right HTTP status.

Typical design:

1. A sealed error type per area, such as OrderError with NotFound, OutOfStock and PaymentDeclined, each carrying useful data.
2. A result type that holds either a value or an error, using the standard Result for exceptions or your own sealed Outcome for typed errors.
3. Exhaustive mapping at the boundary from each error case to a status code and an error body.

Benefits:

• Failure cases are visible in function signatures.
• Adding a new error case forces every handler to deal with it.
• Tests check failures as ordinary return values.

Keep exceptions for: infrastructure failures, bugs and situations the caller cannot handle, caught by a central handler that logs them and returns 500.

Avoid: returning null for several different failure reasons, which loses information about what went wrong.

Kotlin services usually serialize JSON either with a compiler plugin that generates serializers at build time from annotated classes, or with reflection-based libraries from the wider JVM ecosystem plus a Kotlin support module. Both work well when configured to respect Kotlin's null safety and default values.

Settings that matter for APIs:

1. Unknown fields: decide whether to ignore them, which helps compatibility, or reject them, which catches client mistakes.
2. Missing fields: non-null properties without defaults should fail deserialization with a clear error.
3. Explicit nulls and defaults: decide whether defaults are written to the output.
4. Naming strategy: camel case or snake case, applied consistently.
5. Polymorphism: sealed hierarchies need a type discriminator field.

Separate API models from domain types, so internal refactoring does not change the JSON contract.

Organize code into modules by business capability, keep the domain free of framework and database code and let a thin application module wire everything together. Kotlin's internal visibility lets the compiler enforce these boundaries across modules.

flowchart TD
  A["app module: configuration, routing, wiring"] --> B["orders module: domain and use cases"]
  A --> C["billing module: domain and use cases"]
  B --> D["orders infrastructure: database and clients"]
  C --> E["billing infrastructure: payment gateway client"]
  B --> F["shared kernel: value classes such as Money"]
  C --> F

Principles:

1. Feature modules contain their domain model, use cases and the interfaces they need.
2. Infrastructure modules implement those interfaces with database and network code.
3. The app module maps HTTP requests to use cases and creates the object graph.
4. internal by default for implementation classes, so other modules depend only on public interfaces.
5. A small shared kernel for truly common types, kept stable and minimal.

Signs a split is needed: slow builds from one huge module, unrelated features changing the same files and tests that need the whole application to run. Splitting into modules speeds up incremental builds and clarifies ownership.

Pass dependencies through constructors, typed as small interfaces where substitution matters, and create the object graph in one place at startup. Kotlin's concise constructors and default arguments make manual injection pleasant, and dependency injection libraries add automatic wiring for large applications.

Constructor injection in practice:

• class OrderService(private val orders: OrderRepository, private val clock: Clock) declares and stores dependencies in one line.
• fun interface declarations make single-method dependencies, such as clocks or ID generators, easy to supply with a lambda.
• Default arguments can provide production implementations while tests pass fakes, though explicit wiring is usually clearer.

Good practices:

1. Wire in one composition root, such as the application's startup module.
2. Avoid singletons with hidden state declared as object; inject instances instead.
3. Avoid service locator calls inside business code.
4. Keep constructors cheap, with no network calls, so object creation is fast and predictable.

When a library helps: many modules and services, scoped lifetimes such as per-request objects, or framework integration. Choose one that resolves dependencies at compile time or startup and reports missing bindings clearly.

Choose an approach based on how much control over SQL you need and how complex the domain is. All approaches run on a pooled connection, use parameters for every value and, in coroutine code, either use a non-blocking driver or wrap blocking calls in a dispatcher meant for them.

Practices for any approach:

1. Connection pool sizing matched to the database's limits and the service's concurrency.
2. Blocking drivers wrapped in withContext(Dispatchers.IO), ideally with a parallelism limit equal to the pool size.
3. Parameters for all values, and allowlists for dynamic column names.
4. Explicit transactions around related changes.
5. Migrations versioned and applied automatically.
6. Integration tests against the real database engine.

Map database rows to domain types in the data access layer, so the rest of the code never handles raw rows.

Wrap related operations in a transaction helper that begins the transaction, runs a block, commits if it succeeds and rolls back if anything throws. Higher-order functions make this pattern safe and reusable: transaction { ... } guarantees cleanup however the block exits.

sequenceDiagram
  participant S as Service
  participant T as Transaction helper
  participant D as Database
  S->>T: transaction with a block
  T->>D: Begin
  T->>T: Run the block on the same connection
  alt Block succeeds
    T->>D: Commit
  else Block throws
    T->>D: Roll back and rethrow
  end
  T-->>S: Result or exception

Rules:

1. Same connection: every statement in the block must use the transaction's connection, usually passed through the helper's receiver or context.
2. Keep transactions short: no network calls or slow work inside.
3. Coroutines: a transaction is tied to one connection, so do not start parallel coroutines that use it; keep its work sequential.
4. Cancellation: a cancelled coroutine must still roll back; the helper should catch everything, including cancellation, roll back and rethrow.
5. Retries: retry the whole block on deadlocks or serialization failures, with idempotent logic.
6. Side effects after commit: publish events or send emails only after the commit succeeds, or use an outbox table.

An N+1 problem happens when code loads a list, then queries again for each item, such as loading each order's customer separately. The number of queries grows with the list, and so does latency.

How to find it:

1. Log or count queries per request, and look for repeated queries that differ only by ID.
2. Look for repository calls inside map, forEach or loops.
3. Watch for lazy relationships in mappers that load data on property access.

Fixes:

• Batch lookups: collect the IDs, load them with one WHERE id IN (...) query, then associate results by ID with associateBy.
• Joins for small related data needed with every row.
• Projections: select exactly the columns a response needs.
• Data loaders in aggregation layers, which batch requests made during one execution step.

Design repositories for batching: offer findByIds(ids) alongside findById(id), so the efficient path is the obvious one.

Use keyset pagination for large or frequently changing data: sort by a unique, indexed key and return a cursor that marks where the next page starts. The database can jump straight to the next page with an index, instead of skipping rows as offset pagination does.

The query shape: SELECT ... WHERE id < :cursor ORDER BY id DESC LIMIT :limit + 1. Fetching one extra row tells you whether another page exists, without a separate count query.

Design details:

1. Opaque cursors: return an encoded string rather than raw values, so the format can change without breaking clients.
2. Tie-breakers: when sorting by a non-unique field, such as creation time, include the ID too, as in (created_at, id).
3. Page size limits: validate the requested size against a maximum.
4. Stable filters: a cursor should be used only with the same filters; reject mismatches.

When offset pagination is fine: small tables and admin screens where users jump to page numbers.