Kotlin Interview Questions: Null Safety, Coroutines, copy()

Most Kotlin interview questions are not really about Kotlin. The first question — what is a data class, what does null safety mean — is a filter. The interview starts when the interviewer asks what happens next. This article is about that second and third question: the follow-up that checks whether you understand null safety across Java interop, structured concurrency and the real cost of copying a data class, or whether you memorised a definition the night before. It is a guide to the follow-up layer of Kotlin interview questions, not a list of trivia.

Why Kotlin Interviews Move Past Definitions Fast

Interviewers assume a candidate for a Kotlin role can define a data class. That answer carries almost no signal, because it is one search away for anyone. What carries signal is what you say in the ten seconds after the definition lands.

Think of a Kotlin topic as three layers:

Definition. What the feature is. One sentence.
Trade-off. What you gain and what you give up by using it here.
Failure mode. What would break in production, and how you would notice.

The follow-up almost always lives in layers two and three. When an interviewer says "and then what?", they are inviting you down a level. Depth does not mean reciting the language specification. It means naming a decision and defending it in plain language.

This is the same skill that shows up in other languages: the ability to explain a trade-off out loud rather than list features. If you have read our Python interview guide on concepts and trade-offs, the shape is familiar. Kotlin just has sharper pressure points, and we will work through the three that come up most.

Null Safety: From "What Is a Nullable Type" to "Why Does This Still Crash"

Answer the definition in one sentence and move on: a nullable type makes the possibility of absence visible in the type system, so the compiler can force you to handle it.

Then get to the interesting part.

Platform types and where the compiler stops helping

Kotlin's null safety is a Kotlin-side guarantee. Java has no such thing. When you call Java code, the compiler cannot know whether a returned reference can be null, so it treats it as a platform type — a type whose nullability is unspecified. You can assign it to a non-null Kotlin type, and the compiler will not stop you at compile time. It treats the value as non-null on trust and inserts an intrinsic null check at the use site, so a null from Java fails at runtime with a NullPointerException rather than at compile time.

That is the honest answer to "does Kotlin eliminate null pointer exceptions?": no, it eliminates the ones the compiler can see. The ones that cross the Java boundary, arrive through reflection, unchecked casts or the !! operator are still yours to handle. Saying that plainly is stronger than claiming the language solved the problem.

Safe call, Elvis, requireNotNull

These three are not interchangeable, and the follow-up is usually "which would you use here?".

Safe call (?.) when absence is a normal, expected case and you want to continue without the value.
Elvis (?:) when absence is expected but you need a sensible fallback, or you want to fail with a clear message.
requireNotNull when absence means the caller broke a contract, and you want that to fail loudly and early rather than silently propagate.

The distinction is about intent, not syntax. Say the intent out loud.

A short spoken example

Suppose you are reading a value from a map. A natural answer sounds like this:

"I'd decide what 'missing' means before I write the lookup. If a missing key is a legitimate state, I'd return null and let the caller decide with a safe call. If the key is always present because we put it there earlier, I'd use requireNotNull with a message, so a broken assumption fails at the point it breaks instead of three functions later."

That answer shows reasoning. It does not require you to remember an API signature.

The trap to avoid

Do not say "Kotlin has no null pointer exceptions." It is the fastest way to lose credibility with an interviewer who has debugged a platform type. Replace it with the nuance: the compiler catches what it can prove, and the boundary with Java is where your discipline takes over.

Immutability and Data Classes: The Copy Question

Kotlin interview questions on immutability are usually about intent, not syntax. Here the follow-up is where the signal is.

val is a design statement

val is not a style preference. It says this reference does not change after construction, which means a reader can stop tracking it, and a reviewer can stop worrying about it. When you say "I'd default to val here because this value is set once and never reassigned", you are describing a design decision, not a formatting rule. var is fine when state genuinely changes; the weak answer is dogma in either direction.

What copy() actually costs

This is the follow-up that separates people who have used data classes from people who have read about them. copy() constructs a new instance. It does not mutate the original. That is the point — and the cost. It is also a shallow copy: nested objects are shared, so copying a data class that holds a mutable list does not give you an independent value.

So the follow-up is: when does that matter?

In a tight loop over a large collection, allocating a new object per element adds work the garbage collector has to clean up later.
For a small configuration object updated once per request, the cost is irrelevant and the clarity is worth more.

The honest answer names both sides and frames the default as a choice: "My default is to copy for small objects, because the clarity is usually worth more than the allocation; if this were in a hot loop over thousands of items, I'd look at whether I can restructure rather than copy per item."

Equality in a Set

Data classes generate equals and hashCode from the properties in the primary constructor. That is why a data class works as a map key or a set element and a regular class often does not: without those overrides you get referential equality, and two objects with identical contents are treated as different.

The follow-up: what happens if a property used in hashCode changes after the object is in a set? The hash changes, and lookups can miss. That is why values used as keys should be immutable. It connects straight back to the val discussion, which is a good thing to point out.

Talking about mutable state without preaching

If asked how you handle mutable state in a codebase, avoid the sermon. A practical answer: keep mutation local to one place, expose read-only views outward, and prefer returning a new value over changing a shared one. Then admit the exception — sometimes a mutable buffer is the right tool, and you would say so in review rather than pretend otherwise.

Coroutines: Answering "What Happens If This Cancels?"

Coroutine questions are where Kotlin interview questions get most interesting, because the follow-ups are about behaviour under pressure rather than syntax.

The mental model, in plain terms

A suspend function can pause without blocking the thread it runs on. When it suspends, the thread is released back to its pool so it can pick up other work, and the coroutine resumes later on a thread chosen by its dispatcher. It also explains why cancellation has to be cooperative: the runtime cannot safely stop a coroutine that is sitting in the middle of ordinary code, so it marks the coroutine as cancelled and waits for it to reach a point where it can notice.

Structured concurrency is the answer to most follow-ups

Structured concurrency means a coroutine is tied to a scope. When the scope ends, its children end with it. That single idea answers a surprising number of probing questions, because it explains why coroutines are not leaked the way raw threads often are.

Scope, job, dispatcher

Keep these three separate in your head and in your answer:

Scope defines the lifetime and the boundary of cancellation.
Job is the handle to a running coroutine and its children; it is what you cancel.
Dispatcher decides which thread or pool the work runs on.

A clean answer names which one you are changing and why. "I'd move this to a dispatcher suited to blocking work" is better than "I'd add a dispatcher."

The classic follow-up

What happens to a launched coroutine when its parent scope is cancelled? The cancellation propagates down to the children. If you launched inside a scope that is now cancelled, that work is cancelled too. The exception is work started in a separate scope or in GlobalScope, which sits outside the structured hierarchy; that is usually a deliberate, justified decision, and it means you take on a clear owner for cancelling that work yourself.

Cancellation is cooperative

This is the part people miss. Cancellation does not forcibly stop your code. It sets a flag, and your code has to reach a point where it checks. A tight loop with no suspension point and no cancellation check will keep running, which is why long loops should call ensureActive or another cancellation check, or suspend — for example with yield — so the coroutine can notice. ensureActive throws a CancellationException, which is what unwinds the coroutine; yield suspends and gives the runtime a chance to notice.

Say it in trade-off terms rather than buzzwords: cooperative cancellation keeps coroutines cheap, and the price is that you have to give the runtime a chance to notice. The failure mode to name is a job that never reaches a cancellation check: it keeps holding its resources and its thread time after the scope around it has ended, which is exactly the leak structured concurrency is meant to prevent. If you find yourself stacking terms like "structured", "reactive" and "non-blocking" into one sentence, stop and name one trade-off instead.

Collections, Sequences and the Performance Follow-Up

A common shape for Kotlin interview questions on collections is "which would you use here, and why?". For collections versus sequences, the honest answer starts with "it depends".

Eager list operations build an intermediate list at each step. A sequence chains the operations and applies them per element, which can avoid those intermediate allocations. That matters more as the collection gets larger and the chain gets longer. For a list of twenty items with one map, the difference is not worth a discussion.

The failure mode worth naming is memory: on a large input, a long chain of eager operations keeps a full intermediate list alive at every step, so peak memory can climb well beyond the size of the input itself. That is the case where a sequence earns its place.

The strong move is to say what you would measure rather than invent a number:

"I'd start with a list because it's simpler to read. If this ran over a large input or the chain grew, I'd compare the two, and I'd measure allocation and total time on realistic data rather than guess."

That answer is honest, and it tells the interviewer you know where the cost comes from.

Handling "I Don't Know" and "I'd Check the Docs" Gracefully

A confident "I don't know, but here's how I'd find out" beats a bluff every time. Interviewers usually know when an answer is being invented, and a bluff costs more than a gap.

A repeatable structure for the moment:

Name the gap. "I haven't used that API directly."
Reason from what you do know. "Based on how the rest of the library behaves, I'd expect it to…"
Say how you would verify. "I'd check the documentation and write a small test to confirm the behaviour."
Move on. Do not spiral.

When the interviewer keeps pushing, slow down rather than speed up. A calm "let me think about that for a second" is respected. Panic is what makes an answer collapse, not the missing fact.

Practising the Follow-Up, Not Just the First Answer

Most practice stops after answer one. That is why the follow-up feels like a surprise even when the topic is familiar — and it is the part of Kotlin interview questions that most candidates never rehearse.

A method that works:

Write your own follow-ups. For each concept, ask yourself "and then what?" three times. For null safety: what is a nullable type, where does the compiler stop helping, and what would you do at that boundary?
Answer out loud. Reading is not rehearsal. Speaking exposes the gaps.
Record yourself. Listen for filler, hedging, and trade-offs you dropped halfway through.
Practise pushback. A study partner who keeps asking "why?" is more useful than a list of questions.
Keep a one-page trade-off sheet per topic. Definition, trade-off, failure mode. Not a wall of definitions.

A Short Practice Routine for the Week Before

When you plan the final week of Kotlin interview questions practice, work in layers rather than volume.

Days one to three: pick three concepts — null safety, coroutines, data classes. For each, write the definition, the trade-off and the failure mode on one page.
Days four to five: rehearse each out loud in under ninety seconds. Time it. If you run long, you are reciting rather than reasoning.
Day six: review only what you stumbled on. Do not restart from the top.
Day seven: rest. Confidence comes from repetition across the week, not from a final cram.

The takeaway: prepare the second and third question, not just the first. A definition proves you read; a trade-off proves you think. If you want to see the same approach applied to another topic, our blog has more on preparing for technical interviews.

Frequently asked questions

How deep do Kotlin interview questions usually go for a mid-level role?

Typically, the first question is a definition and the next two are about trade-offs and failure modes. For a mid-level role, expect to explain null safety across the Java boundary, describe how structured concurrency ties a coroutine to its scope, and say when copying a data class is cheap and when it is not. You do not need to know internal implementation details.

Do I need to memorise the Kotlin standard library to pass a technical interview?

No. Interviewers care more about whether you can reason about behaviour than whether you can recall a function name. If a specific API escapes you, say what you would expect it to do, how you would verify it, and move on. That is a stronger signal than a memorised signature you cannot explain.

What should I say if I don't know the answer to a Kotlin follow-up question?

Name the gap, reason from what you do know, and say how you would find out. Something like: I haven't used that directly, but based on how the rest of the library behaves I'd expect it to work this way, and I'd confirm it with a small test. Then stop talking and let the interviewer respond.

Is it better to give a short answer or a long one in a Kotlin interview?

Short for the definition, longer for the trade-off. One sentence for what a feature is, then a focused explanation of when you would use it and what it costs. A long answer that never names a trade-off reads as padding, and it uses up time you may need later.

How do I practise Kotlin follow-up questions on my own?

Write your own follow-ups for each concept by asking and then what three times, answer them out loud, and record yourself to catch filler and dropped trade-offs. Keep a one-page sheet per topic covering the definition, the trade-off and the failure mode, and rehearse each in under ninety seconds.

Rehearse the second and third question out loud, not just the first.