Kotlin Backend Developer Top 100 Interview Questions

Kotlin strings are immutable sequences of characters with built-in templates: "$name has ${items.size} items" inserts values directly. Raw strings, written with triple quotes, keep line breaks and backslashes as written, which suits SQL, JSON and regular expressions.

Useful features:

• Templates: $variable and ${expression}.
• Raw strings: """...""", often with trimIndent() or trimMargin() to remove leading indentation.
• buildString: builds a string efficiently with a StringBuilder receiver.
• Text helpers: split, lines, substringBefore, removePrefix, padStart and toIntOrNull.
• Regular expressions: Regex with find, matches and replace.

Practical cautions:

1. Never build SQL by inserting values into templates; use parameters instead.
2. Case conversion and comparison for identifiers should be locale-independent: lowercase() and uppercase() already use invariant rules.
3. Character counts: length counts UTF-16 code units, so some characters, such as many emoji, count as two.
4. Repeated concatenation in loops creates many intermediate strings; use buildString or joinToString.

== checks structural equality by calling equals, and it is null-safe: a == b is false when only one side is null, without throwing. === checks referential equality: whether both references point to the same object.

Behavior by kind of class:

• Regular classes inherit equals from Any, which compares references, so two instances with the same data are not equal.
• Data classes generate equals and hashCode from their constructor properties, giving value equality.
• Value classes compare their wrapped values.

Rules for custom equality:

1. Override equals and hashCode together, using the same properties, so hash-based collections work.
2. Base equality on properties that do not change while the object is stored in a set or used as a map key.
3. Be careful with arrays: arrays compare by reference; use contentEquals or lists instead.
4. Floating-point fields can make equality fragile because of rounding.

In entities with identity, such as database records, equality is often based on the ID, while data classes for values compare every property; choose deliberately for each type.

Kotlin has four visibility levels: public, the default, visible everywhere; internal, visible only within the same module; protected, visible to subclasses; and private, visible only inside the containing class or file. A module is a set of files compiled together, such as one build subproject.

Using internal for architecture:

• Split a service into modules, such as orders, payments and api, and mark implementation classes internal, so other modules can depend only on public interfaces.
• The compiler enforces these boundaries, which keeps a modular codebase from degrading over time.

Private at file level: top-level functions and classes marked private are visible only in their file, useful for helpers that should not be reused elsewhere.

Good practices:

1. Minimize public surface: make things internal or private unless other modules genuinely need them.
2. Explicit API mode for library modules makes the compiler require visibility modifiers and return types on public declarations, preventing accidental exposure.
3. Test visibility: tests in the same module can see internal members, so you rarely need to make things public just for testing.

Kotlin compiles to JVM bytecode and can call any library written for the JVM directly, and those libraries can call Kotlin code. This lets teams adopt Kotlin gradually and use the large existing ecosystem, but a few differences need care.

Things to know when calling existing libraries:

1. Platform types: values from code without nullability annotations have unknown nullability, shown as String!. Kotlin lets you treat them as nullable or not, and a wrong guess causes a null pointer exception at run time; declare the type explicitly at the boundary.
2. Collections: read-only Kotlin collections are passed as normal mutable collections, so library code could modify them.
3. Checked exceptions from libraries are not enforced by Kotlin, so remember to handle documented failures.
4. Getters and setters appear as Kotlin properties.

Things to know when exposing Kotlin to other JVM code:

• @JvmStatic makes companion functions callable as static methods.
• @JvmOverloads generates overloads for default arguments.
• @JvmField exposes a property as a plain field.
• @Throws declares exceptions for callers that expect checked exceptions.

Gradual adoption: convert one file or module at a time, starting with tests or new code.

Idiomatic Kotlin is concise but clear: immutable data, explicit types at boundaries, the type system used to rule out invalid states and expressive standard functions used where they help readability.

Core habits:

1. val by default, read-only collections in signatures and data classes for data.
2. Null safety at boundaries: convert external input into non-null domain types early.
3. Sealed hierarchies and when for outcomes and states, with exhaustive handling.
4. Value classes for identifiers and validated primitives.
5. Constructor injection and small interfaces, instead of singletons with hidden state.
6. Structured concurrency with coroutines, never unscoped background work.
7. Expressions over statements: if, when and try return values.
8. Named arguments and defaults instead of many overloads or builder classes.
9. Standard library first: buildList, groupBy, require and check before custom utilities.

What to avoid:

• !! scattered through code.
• Deeply nested scope functions and clever one-liners.
• Extension functions on very general types without a clear purpose.
• lateinit for values that could be constructor parameters.

Interview tip: showing how a sealed result type replaced a set of nullable fields and flags in real code is a convincing way to demonstrate idiomatic Kotlin.

A coroutine is a computation that can suspend, freeing its thread while it waits, and resume later, possibly on another thread. Many thousands of coroutines can share a small pool of threads, which makes asynchronous code efficient while it still reads like ordinary sequential code.

What this means for backend code:

1. Waiting is cheap: a request handler can suspend while a database or API call is in progress, and the thread serves other requests meanwhile.
2. Suspension needs suspending APIs: a blocking call inside a coroutine still blocks the thread, so blocking work must move to a dispatcher meant for it.
3. Structure matters: coroutines run inside scopes that control their lifetime, cancellation and error handling.

The language provides suspend functions and the low-level machinery; the official coroutines library adds builders such as launch and async, dispatchers, flows and channels.

The compiler transforms each suspend function into a state machine. It adds a hidden continuation parameter, an object that knows how to resume the function, and splits the function at each suspension point. When a call suspends, the function returns a special marker to its caller, and the thread is free; later, something calls resume on the continuation, and execution continues from the saved state.

Key ideas:

• Continuation passing: every suspend call receives the continuation of its caller, linking the chain of suspended functions.
• No thread is held while suspended, only the small state objects.
• Resumption happens wherever the code that completes the operation decides, usually on a thread chosen by the coroutine's dispatcher.
• suspend alone does not make code asynchronous: a suspend function that never calls another suspending operation runs straight through like normal code.

Practical consequences:

1. Suspend functions can only be called from other suspend functions or coroutine builders.
2. Stack traces across suspension points can look unusual, since the call stack is rebuilt on resumption.
3. Low-level primitives, such as suspendCoroutine, connect callback-based code to suspend functions.

Structured concurrency means every coroutine runs inside a scope, and a scope does not finish until all of its child coroutines have finished. Coroutines form a tree, so cancellation flows down to children and failures flow up to parents, and no coroutine can outlive the work that started it.

flowchart TD
  A["Request scope"] --> B["Load profile"]
  A --> C["Load orders"]
  A --> D["Load recommendations"]
  C --> E["Load order items"]
  F["Client disconnects"] -.->|"Cancels the whole tree"| A

Guarantees it gives:

1. No leaks: when a request finishes or is cancelled, every coroutine it started is finished or cancelled too.
2. Errors are not lost: a failing child cancels its siblings and reports the error to the parent, which rethrows it.
3. Clear lifetimes: the code that starts concurrent work also waits for it, visible in one block.

How to apply it:

• Use coroutineScope { ... } inside suspend functions to start parallel work that must complete before the function returns.
• Tie long-lived background work to an application-level scope that is cancelled on shutdown.
• Avoid unscoped global coroutines, which break all of these guarantees.

Both start a new coroutine inside a scope. launch is for work whose result you do not need; it returns a Job for waiting or cancelling. async is for work that produces a value; it returns a Deferred<T>, and await() suspends until the value is ready.

Running work in parallel:

1. Inside coroutineScope, start each independent call with async.
2. Call await on each to collect the results.
3. Total time is roughly that of the slowest call, not the sum.

Common mistakes:

• Calling await immediately after each async, which makes the calls sequential again.
• Using async without ever awaiting, hiding results and making failures surprising.
• Starting coroutines outside a scope, such as in a global scope, so they are not cancelled with the request.

A dispatcher decides which thread or thread pool runs a coroutine. Choosing the right one keeps CPU work, blocking input and output and event loops from interfering with each other.

Switching dispatchers: withContext(Dispatchers.IO) { ... } runs a block on another dispatcher and returns its result, then resumes on the original one.

Good practices:

1. Non-blocking code needs no switching: suspending HTTP or database clients work on any dispatcher.
2. Wrap blocking calls in withContext(Dispatchers.IO) at the lowest level, inside the repository or client, so callers never have to remember.
3. Do not block Default threads, which would slow every coroutine sharing them.
4. Use limited views rather than creating new thread pools, so threads are shared efficiently.

Cancelling a coroutine sets its job to the cancelling state and cancels its children. The coroutine stops only when it reaches a suspension point that checks for cancellation, such as delay, a channel operation or most suspending library calls, which then throw a CancellationException. Code that never suspends or checks keeps running.

Making code cancellable:

1. Long CPU loops should call ensureActive() or yield() periodically.
2. Blocking calls do not respond to cancellation; use interruptible variants or non-blocking APIs.
3. Clean up in finally: the cancellation exception unwinds normally, so finally blocks run.
4. Suspending cleanup inside finally needs withContext(NonCancellable), since the coroutine is already cancelled.

Never swallow cancellation:

• Catching Exception or Throwable, or using runCatching, also catches CancellationException; if you do not rethrow it, the coroutine keeps running after being cancelled, and structured concurrency breaks.
• Catch specific exception types, or rethrow CancellationException explicitly.

Why it is cooperative: stopping code at an arbitrary point could leave data structures, locks and connections in a broken state; cooperative cancellation stops only at safe points.

Wrap the work in withTimeout(duration) { ... }, which cancels the block when the time runs out and throws a timeout exception, or in withTimeoutOrNull, which returns null instead. Because timeouts use cancellation, the work inside must be cancellable to stop on time.

Choosing between them:

• withTimeout when exceeding the limit is an error that should propagate, such as a request budget.
• withTimeoutOrNull when a fallback is acceptable, such as returning cached data if a recommendation call is slow.

Designing timeouts:

1. Budget per request: an overall timeout for the handler, with smaller timeouts for each dependency inside it.
2. Base values on measured latency, such as a little above the 99th percentile of each dependency.
3. Combine with client timeouts: network clients should have their own connect and read timeouts as a safety net.
4. Handle partial results: decide what to return when an optional part times out.

A subtle point: the timeout exception is a kind of cancellation exception. Catch it right around the withTimeout call when you want a fallback, rather than letting it escape into code that treats it as ordinary cancellation of the outer scope.

In a regular scope, a child coroutine that fails cancels its parent, and the parent cancels all its other children, then rethrows the failure. This "one fails, all fail" behavior suits work where every part is required. A supervisor scope changes the rule: a failing child does not affect its siblings or its parent.

flowchart TD
  A["coroutineScope"] --> B["Child 1 fails"]
  A --> C["Child 2 is cancelled"]
  B -.->|"Failure propagates up"| A
  D["supervisorScope"] --> E["Child 1 fails and reports its error"]
  D --> F["Child 2 keeps running"]

When to use each:

• coroutineScope: loading data that a response needs entirely, where one failure means the whole request fails.
• supervisorScope or a SupervisorJob: independent tasks, such as sending several notifications, or a long-lived scope running many unrelated jobs.

Handling failures:

1. async failures are rethrown by await; wrap await in try/catch for a fallback.
2. launch failures in a supervisor go to a CoroutineExceptionHandler, which should log them.
3. Never let failures disappear: every top-level scope needs a handler or explicit error handling.

Inside coroutineScope, start each independent call with async, then await all of them. The calls run concurrently, the total time is roughly the slowest call and, if any required call fails, the others are cancelled automatically.

A typical pattern for an aggregation endpoint:

1. Start required calls, such as profile and orders, with async.
2. Start optional calls, such as recommendations, with async wrapped in a timeout and a fallback.
3. Await the results and build the response.

Handling optional parts:

• Wrap the optional call in withTimeoutOrNull and a try/catch for specific exceptions, returning an empty section on failure, so it never fails the whole response.
• Or run optional work in a supervisorScope, so its failure stays isolated.

Practical details:

1. Pass the request's context, so cancellation and tracing information flow to every call.
2. Limit fan-out for large lists of IDs, using a semaphore or batching, so you do not send hundreds of calls at once.
3. Do not share mutable state between the concurrent calls; combine results after awaiting.

Interview tip: interviewers often ask what happens when one of the parallel calls fails; explaining that a regular scope cancels the siblings, and showing how you isolate optional calls, is the answer they look for.

Starting a coroutine per item is cheap, but the resources behind them, such as database connections or a partner's rate limit, are not. Limit how many operations run at once with a semaphore, a limited-parallelism dispatcher or a fixed number of worker coroutines reading from a channel.

Options:

1. Semaphore(n) with withPermit { ... }: at most n coroutines run the protected block at once; others suspend without blocking threads.
2. limitedParallelism(n) on a dispatcher: at most n coroutines run on it at the same time, useful for blocking clients.
3. Worker pool: n coroutines consume work from a channel, which also gives backpressure through the channel's capacity.
4. Batching: group items and send one request per batch when the downstream API supports it.

Choosing the limit:

• Base it on the bottleneck, such as the connection pool size or the partner's documented limits.
• Make it configurable, and measure waiting time as a metric.
• Combine it with timeouts, so waiting for a permit cannot last forever.

Avoid: unbounded map { async { ... } } over thousands of items, which overwhelms dependencies and can exhaust memory.

A Flow is an asynchronous stream of values produced over time and consumed with collect. Flows support operators such as map, filter, buffer and debounce, and they respect cancellation and structured concurrency.

Backend uses:

1. Streaming large query results or paginated API data without loading everything.
2. Processing messages from a queue with operators for batching and rate limiting.
3. Broadcasting internal events, such as configuration changes.

Key rules: flows are sequential by default; use buffer or flatMapMerge for concurrency. Exceptions are handled with catch and retry operators, and flowOn changes the dispatcher for upstream operators.

A channel is a coroutine-safe queue: one or more coroutines send values, and others receive them. Unlike a flow, a channel is a hot communication primitive; each value is received by exactly one consumer, which makes channels a good fit for distributing work.

flowchart LR
  A["Producer coroutine"] -->|"send"| B["Channel with capacity 100"]
  B -->|"receive"| C["Worker 1"]
  B -->|"receive"| D["Worker 2"]
  B -->|"receive"| E["Worker 3"]

Capacity choices:

• Rendezvous, the default with no buffer: send suspends until a receiver takes the value.
• Buffered: a fixed capacity; send suspends only when the buffer is full, giving backpressure.
• Conflated: keeps only the latest value, dropping older ones, suited to state updates.
• Unlimited: never suspends senders, which risks running out of memory; avoid in services.

Good practices:

1. Close the channel when production ends, so consumers iterating with for (item in channel) finish.
2. Use a fixed number of consumers for a worker pool.
3. Prefer flows for streams with operators and a single consumer; use channels for fan-out of work and coordination between coroutines.

Coroutines on multithreaded dispatchers can run in parallel, so shared mutable state needs the same care as with threads. The best option is to avoid sharing; otherwise, use a coroutine-friendly lock, atomic values or confine the state to a single coroutine.

Guidelines:

1. Prefer immutable data and return new values, which removes the need for locks.
2. Never use thread-blocking locks around suspending calls; a blocked thread cannot run other coroutines.
3. Keep critical sections short, without network calls inside them.
4. Remember that Mutex is not reentrant: locking it again from inside the same block deadlocks.
5. Single-threaded confinement, with a dispatcher limited to one thread, is simple for low-contention state.

Coroutines share a small number of threads. A blocking call, such as a synchronous database driver, Thread.sleep or reading a file, holds its thread for the whole wait, so other coroutines scheduled on that thread cannot run. Under load, a few blocking calls on the default dispatcher can stall the whole service.

How to call blocking APIs:

1. Wrap them in withContext(Dispatchers.IO) { ... }, which runs them on a pool designed for blocking work.
2. Limit parallelism for a specific blocking resource with Dispatchers.IO.limitedParallelism(n), matching its own capacity, such as a connection pool of 10.
3. Prefer non-blocking libraries with suspending APIs where they exist.
4. Replace Thread.sleep with delay, which suspends instead of blocking.

How to find blocking calls:

• Thread dumps showing default dispatcher threads stuck in input and output.
• Latency that rises sharply under load while processor use stays moderate.
• Debug tools that detect blocking calls on threads that should not block.

Never call runBlocking inside a request handler or another coroutine; it blocks the current thread until the inner work finishes, defeating the purpose of coroutines and risking deadlocks.

The standard library's sequence { ... } builder creates a lazy sequence from a block that calls yield(value) to produce each element. The block suspends at every yield and resumes only when the consumer asks for the next element, using the same suspension machinery as coroutines, but synchronously on the caller's thread.

Why it is useful:

• Generating data on demand, such as pages of results, IDs or retry delays.
• Infinite sequences that stop when the consumer stops, such as generateSequence or a while (true) loop with yield.
• Readable stateful iteration: local variables in the block keep their values between elements, without writing an iterator class.

Related functions: yieldAll produces all elements of another sequence or collection, and iterator { ... } builds an iterator the same way.

Limits:

1. The block can call only yield and yieldAll as suspending functions; it cannot call other suspend functions, such as network calls. For asynchronous streams, use flows.
2. Each iteration of the sequence runs the block again from the start.