Kotlin Backend Developer Top 100 Interview Questions

Cache data that is read often, changes rarely and is expensive to compute or fetch. Use a bounded in-process cache for per-instance speed and a shared cache when every instance must see the same values, and always define expiry and size limits.

Design points:

1. Bounded size with an eviction policy, such as least recently used, so memory cannot grow without limit.
2. Expiry that matches how stale the data may be.
3. Concurrent loading: when many coroutines miss the same key, let one load it while the others wait for the same result, for example by caching a deferred value.
4. Keys that include every input affecting the value, such as tenant and language.
5. Invalidation when the source changes, or short lifetimes when change events are not available.
6. Metrics: hit rate, size and load time.

A simple in-process LRU can be built on a linked hash map in access order, which moves an entry to the end whenever it is read and lets you remove the eldest entry when the size limit is exceeded. It is not thread-safe, so guard it with a lock or use a concurrent cache library in production.

Layer defenses: authenticate every request, authorize every action on every resource, validate input strictly, protect secrets and keep dependencies patched. Frameworks provide the building blocks, but secure defaults must be configured deliberately.

Authentication and authorization:

1. Validate tokens fully: signature, issuer, audience and expiry.
2. Require authentication by default, and mark public routes explicitly.
3. Check ownership in handlers that load resources by ID, so users cannot read each other's data by changing an ID.
4. Use role or permission checks expressed as small, testable functions.

Input and output:

• Validate request models into typed commands, reject unknown fields where appropriate and limit body sizes.
• Use parameterized queries and allowlists for dynamic sorting.
• Return consistent errors without stack traces or internal details.

Transport and platform:

• HTTPS everywhere, strict CORS rules and security headers.
• Rate limits on login and expensive endpoints.

Secrets and dependencies:

• Secrets from the environment or a secret store, never in code or logs.
• Dependency verification and vulnerability scanning in the build, and regular updates of the JVM and libraries.

Read configuration from the environment and configuration files at startup, convert values to typed fields, validate them all and fail fast with every problem listed. The rest of the code receives an immutable configuration data class, never raw strings.

Practices:

1. One typed data class with Duration, Int, Boolean and value class fields, not strings.
2. Defaults for optional settings and clear errors for required ones.
3. Collect all errors before failing, so operators fix everything in one deployment.
4. Testable loading: pass the environment as a map into the loader instead of reading global state.
5. Secrets from the environment or a secret store, never committed, and never printed when logging the configuration.
6. Separate configuration per environment through values, not through different code paths.

Using Duration for timeouts avoids the classic mistake of mixing milliseconds and seconds.

Write structured logs, such as JSON with named fields, through a logging facade, and add distributed tracing so a request can be followed across services. With coroutines, request context must travel in the coroutine context rather than in thread-local storage, because a coroutine can resume on a different thread.

Logging practices:

1. Structured fields, such as orderId and durationMs, rather than values embedded in message text.
2. A request ID and trace ID on every log line, added by middleware.
3. Context propagation with coroutines: use a context element that copies diagnostic context into each thread a coroutine runs on, or the framework's built-in support.
4. Lazy messages: pass lambdas for expensive debug messages, so the string is built only when the level is enabled.
5. No secrets or sensitive personal data in logs.
6. Log exceptions once, at the boundary, with the stack trace.

Tracing practices:

• Create spans for incoming requests, database calls and outgoing HTTP calls.
• Propagate trace headers to downstream services.
• Make sure spans follow coroutines across thread switches, using the tracing library's coroutine integration.

Test behavior through public functions with fast, isolated tests that use fakes for external systems. Kotlin's test libraries and the multiplatform test module provide assertions, while expressive test names and data classes make tests easy to read.

Structure:

1. Arrange: build the object with fakes and inputs.
2. Act: call one function.
3. Assert: compare results, often whole data classes, which gives clear failure messages.

Kotlin-specific tips:

• Readable names: backtick-quoted names, such as `rejects refunds after 30 days`, read like specifications.
• Data class comparisons check every field at once.
• Sealed results are easy to assert with when or type checks.
• Coroutine code runs in runTest with virtual time.
• Parameterized tests cover many inputs for the same rule.

Good habits:

• Inject clocks, ID generators and random sources, so tests are deterministic.
• Test failure paths, including cancellation and timeouts.
• Keep unit tests free of real databases and networks; cover those with integration tests against real engines in containers.
• Avoid mocking data classes or value types; build real instances.

Define small interfaces for external dependencies, then write simple fake classes in tests that record calls and return chosen results. Kotlin makes fakes short: an interface with one method can be implemented by a lambda, and data classes make recorded calls easy to compare.

Kinds of test doubles:

• Fakes: working in-memory implementations, such as a repository backed by a map.
• Stubs: fixed answers or failures, to drive specific paths.
• Spies: record calls for later checks.

Guidelines:

1. Fake what you do not own: payment gateways, email services, clocks and remote APIs.
2. Check outcomes rather than every interaction, so refactoring does not break tests.
3. Share fakes across tests to keep them consistent.
4. Mocking libraries are useful for large interfaces and for final classes, but hand-written fakes are often clearer.
5. Run contract tests against both the fake and the real implementation, so they behave the same.

Most Kotlin web frameworks provide an in-memory test host: the application starts with test configuration, and tests send requests through a client without opening real network ports. The whole pipeline runs, including routing, serialization, validation, authentication and error handling.

Setting it up:

1. Start the application module with test settings and fake external dependencies.
2. Send requests with the test client, including headers and JSON bodies.
3. Assert on status codes, headers and decoded response bodies, comparing to data classes.

What to cover:

• Success paths for each endpoint.
• Validation errors with field messages.
• Authentication failures, missing permissions and access to other users' resources.
• Error mapping, such as 404 and 409 for domain failures, and a generic 500 without internal details.
• Serialization details, such as naming, null handling and unknown fields.

Database-backed tests: run them against the real database engine in a container, and reset data between tests.

Keep them fast: share one application instance per test class where possible, and run independent tests in parallel.

Store and exchange instants in UTC, use the platform's modern immutable date and time types and convert to a user's zone only for display. Keep calendar dates, such as birthdays, separate from instants, such as when an order was placed.

Types to use for each purpose:

• Instants for timestamps in databases, logs and APIs.
• Local dates for calendar dates without a time.
• Zoned date-times when local rules matter, such as scheduling a meeting in a specific city.
• Duration from the Kotlin standard library for amounts of time in code, such as timeouts.

Good practices:

1. Inject a clock, so code reading "now" is testable.
2. Use standard date-time strings in APIs, such as 2026-03-01T09:30:00Z.
3. Convert time zones by zone ID, which handles daylight saving rules, not by fixed offsets.
4. Be careful with "add one day" across daylight saving changes: adding 24 hours and adding a calendar day can differ.
5. Multiplatform code can use a date-time library that works on every Kotlin target.

Recurring local events, such as "every day at 9 in the user's zone", should be stored as a local time plus a zone, and converted to instants when each occurrence is scheduled.

Never use Double for money: binary floating point cannot represent most decimal fractions exactly, so errors accumulate. Use integer amounts in the smallest currency unit, wrapped in a value class, or the platform's arbitrary-precision decimal type with explicit rounding.

A money type should:

1. Store minor units as a Long, such as paise or cents, with the currency.
2. Refuse to mix currencies in arithmetic.
3. Round explicitly, in one place, for operations such as tax and discounts.
4. Allocate remainders when splitting, so the parts always add up to the total.
5. Format only for display, with the right locale.

Storage and APIs: store integers or exact decimal columns in the database; in JSON, send minor units as integers or decimal amounts as strings, so clients do not lose precision.

Value classes give a distinct type for money with almost no runtime cost, and operator functions make arithmetic read naturally.

Build the service with a reproducible build, produce a self-contained artifact, such as an executable archive with all dependencies or a distribution folder, and package it into a container image that layers dependencies separately from application code.

Build practices:

1. Pin the Kotlin version, the JVM version and dependency versions, and enable dependency verification or lock files.
2. Use build caching and incremental compilation to keep builds fast.
3. Run tests, static analysis and formatting checks as part of the build.
4. Embed the version and commit identifier in the artifact for diagnostics.

Container practices:

• Layered images: dependencies change rarely, so put them in a lower layer and the application classes on top, which makes rebuilds and pulls fast.
• A slim JVM runtime image, or a custom minimal runtime containing only the modules the service needs.
• Non-root user and a read-only file system where possible.
• Memory settings relative to the container limit, rather than fixed heap sizes.
• Health checks and graceful shutdown handling.

Optional native compilation produces a fast-starting executable without a JVM, at the cost of longer builds and restrictions on reflection.

Measure where startup time and memory go, then remove unnecessary work at startup, reduce reflection and consider ahead-of-time techniques when fast startup really matters, such as for autoscaling or scale-to-zero workloads.

Improvements on the standard JVM:

1. Avoid heavy reflection at startup by using compile-time serialization and dependency injection that resolves at build time.
2. Defer expensive initialization, such as warming caches, until after the service reports ready, if acceptable.
3. Class data sharing and startup snapshots reduce class loading time.
4. Right-size thread pools and caches, which affect baseline memory.
5. Tune the heap relative to the container, and choose a collector suited to the heap size.

Measure time to first successful request and steady-state memory under realistic load before and after each change.

Size each pool from the work it does and the resource it protects. The number of operations in progress equals throughput times the time each operation takes, so a pool needs at least that many slots, plus headroom, but never more than the downstream resource can handle.

Different pools, different rules:

• CPU-bound work, such as Dispatchers.Default: about one thread per core; more threads only add switching.
• Blocking calls, such as a blocking database driver: enough threads to cover concurrent calls, capped by the connection pool.
• Database connection pools: limited by the database's connection capacity divided across all instances.
• Suspending, non-blocking calls need few threads; concurrency is limited by connection pools and semaphores instead.

Practical steps:

1. Measure throughput and latency per operation under load.
2. Compute needed concurrency, add headroom for spikes and cap it by downstream limits.
3. Align limits: a parallelism limit on blocking database work should equal the connection pool size, so threads never wait for connections.
4. Monitor pool usage, wait time and timeouts.

On a termination signal, stop accepting new requests, let in-flight requests and background coroutines finish within a time limit, then close resources such as connection pools and flush logs and metrics. Structured concurrency makes this clean: cancelling the application scope cancels every background coroutine, and their finally blocks run cleanup.

sequenceDiagram
  participant P as Platform
  participant A as Application
  participant S as HTTP server
  participant B as Background scope
  P->>A: Termination signal
  A->>A: Fail readiness, wait briefly for load balancers
  A->>S: Stop accepting, finish in-flight requests within a grace period
  A->>B: Cancel scope and wait for children
  B-->>A: Finished, cleanup done in finally blocks
  A->>A: Close pools, flush telemetry
  A-->>P: Exit

Implementation details:

1. Grace period: shorter than the platform's kill timeout, so the process exits on its own.
2. Background work: consumers stop taking new messages, finish or release current ones and commit offsets or acknowledgements.
3. Suspending cleanup runs in withContext(NonCancellable) inside finally.
4. Order: stop inputs first, then workers, then shared resources such as databases.
5. Test it by sending termination signals under load and checking that no requests fail.

Use a suspending HTTP client configured once per downstream service, with timeouts, connection pooling, limited retries and clear error handling, and wrap each service behind a small client class with typed results.

flowchart LR
  A["Service code"] --> B["Typed client for the pricing service"]
  B --> C["Timeout per call"]
  C --> D["Retry transient failures with backoff"]
  D --> E["Concurrency limit and circuit breaker"]
  E --> F["Pooled HTTP connection"]
  F --> G["Pricing service"]

Rules:

1. Timeouts everywhere: connect, request and overall, within the caller's own deadline.
2. Retries only for safe operations and transient errors, with backoff and jitter, never retrying cancellation.
3. Circuit breaking: stop calling a failing dependency for a while and return a fallback, so failures do not cascade.
4. Concurrency limits per dependency, with a semaphore.
5. Typed errors: map responses to sealed results, such as NotFound or Unavailable, so callers handle each case.
6. Propagate context: trace headers and request deadlines.
7. Reuse clients: creating a client per call wastes connections and threads.

Test clients against a local fake server that can return errors, slow responses and malformed bodies.

Design types so invalid combinations of data cannot be constructed. Instead of one class with many nullable fields and flags, model each valid state as its own type with exactly the fields it needs, and make transitions functions that only accept the right starting state.

Techniques:

1. Sealed hierarchies for states: a Shipped order always has a tracking code; a Pending order cannot have one.
2. Value classes for validated primitives: an Email can only be created through a parser that validates it.
3. Non-null types for required data, so missing values are impossible after validation.
4. Private constructors with factories that enforce rules, such as a positive quantity.
5. Transition functions that return the next state and reject invalid moves.

Benefits:

• Whole categories of checks disappear from business code, because the compiler guarantees them.
• Reviews focus on transitions instead of scattered if checks.
• Adding a state forces every when over the states to handle it.

Balance: keep persistence and API models flexible where needed, and convert into strict domain types at the boundary.

A blocking call is probably running on a dispatcher meant for non-blocking or CPU work, usually the default dispatcher. Its few threads are stuck waiting, so every coroutine scheduled on them waits too, and latency climbs even though the processor is mostly idle.

How to confirm:

1. Thread dumps show default dispatcher threads blocked in input and output, such as a synchronous database driver, a blocking HTTP client or Thread.sleep.
2. Coroutine dumps show many coroutines suspended waiting to be dispatched.
3. Latency correlates with traffic while processor use stays moderate.

Fixes:

• Wrap blocking calls in withContext(Dispatchers.IO), with a limited-parallelism view sized to the resource, such as the connection pool.
• Replace blocking clients with suspending ones where possible.
• Remove runBlocking from request paths.
• Add a guard: debug tooling that detects blocking calls on dispatcher threads in tests and staging.

Besides ordinary leaks, such as unbounded caches, coroutine code has its own ways to hold memory: coroutines that never finish, buffers that grow without limit and replay caches that keep old values.

Coroutine-related causes:

1. Leaked coroutines: work launched in an application-wide scope that waits forever, such as on a channel nobody sends to, keeping its captured data alive.
2. Unlimited channels: a producer faster than its consumer fills an unlimited buffer.
3. Large replay caches on shared flows, holding many big events for late subscribers.
4. Collectors that never stop, started per request but tied to a long-lived scope.
5. Captured request data in long-lived lambdas, such as callbacks registered with a global registry.

How to investigate:

• Dump active coroutines with debugging tools and look for counts that grow.
• Compare heap dumps and follow retention paths from coroutine continuation objects.
• Check every launch that does not use the request's scope.

Fixes: structured concurrency for per-request work, bounded channels with explicit overflow behavior, small replay values and timeouts on waits.

Cancellation in coroutines is cooperative, so work continues when the code cannot observe the cancellation or actively suppresses it. The most common causes are swallowed cancellation exceptions, blocking calls and work started outside the request's scope.

Typical causes:

1. Swallowed cancellation: catch (e: Exception) or runCatching around suspending calls catches the cancellation exception; if it is not rethrown, the coroutine continues as if nothing happened.
2. Blocking or CPU loops that never reach a suspension point or check isActive.
3. Unscoped launches: coroutines started in a global or application scope do not belong to the request, so cancelling the request does not reach them.
4. NonCancellable used too broadly, instead of only for short cleanup.
5. Callback wrappers that do not cancel the underlying operation when the coroutine is cancelled.

Fixes:

• Catch specific exceptions, or rethrow cancellation explicitly in generic handlers.
• Add ensureActive() in long loops, and use interruptible or suspending APIs.
• Start child work in coroutineScope within the request.
• Register cancellation handlers in callback wrappers.

Test it: cancel a running operation in a test and assert that no further side effects happen.

Kotlin's null safety is checked at compile time, but some values bypass the checks at run time. The usual sources are platform types from JVM libraries, uninitialized lateinit properties, explicit !! assertions and deserialization or reflection that creates objects without running the normal constructor checks.

Where to look:

1. Platform types: a library method without nullability annotations returns null, and the value is assigned to a non-null Kotlin type, which throws at that point.
2. !! on a value the developer assumed could not be null.
3. lateinit properties read before initialization, which throw a specific uninitialized-property exception.
4. Deserialization that bypasses constructors and leaves non-null fields null.
5. Initialization order: calling an overridable method from a base class constructor, which reads a subclass property before it is set.

Prevention:

• Declare explicit Kotlin types at interop boundaries, choosing nullable types when unsure.
• Search for and justify every !!.
• Prefer constructor parameters over lateinit.
• Configure serialization to respect nullability, and validate input into domain types.

Most message brokers deliver at least once: after a crash, a timeout or a rebalance, a message can be delivered again. The consumer must therefore be idempotent, recording each processed message ID and skipping messages it has already handled.

Making a consumer idempotent:

1. Use a stable message ID, set by the producer, not generated on receipt.
2. Record processed IDs in the same database transaction as the business change, with a unique constraint, so the check and the write are atomic.
3. Acknowledge after processing succeeds and commits.
4. Design operations to be naturally idempotent where possible, such as setting a status rather than incrementing a counter.
5. Expire old IDs after a period longer than the broker's maximum redelivery window.

Related issues:

• Ordering: if messages can arrive out of order, compare versions or timestamps before applying updates.
• Poison messages: messages that always fail should go to a dead-letter queue after a few attempts.
• Partial side effects: external calls, such as emails, need their own idempotency keys.