Home / Blog / Kotlin Coding Interview Checklist

Kotlin Coding Interview Checklist

Published 2026-10-12 · Luna Interview

Kotlin is a strong live-interview language: null safety reduces certain bugs, the standard library is expressive, and the code stays readable for interviewers coming from Java. The risk is spending the round on clever idioms instead of a correct algorithm. Use this Kotlin coding interview checklist to stay fast, clear, and boring in the right ways.

Confirm the pad’s Kotlin version and whether you can run code. If execution is limited, prefer simple loops you can dry-run by hand over long fluent chains.

Pre-round language checklist

• [ ] Mutable vs read-only collections: mutableListOf / mutableMapOf when you update
• [ ] Null model: ?., ?:, and when a type should be non-null
• [ ] data class for small bundles of return values
• [ ] compareBy / sortedBy for custom sorts
• [ ] Queue via ArrayDeque for BFS
• [ ] Heap via PriorityQueue when top-k appears
• [ ] Prefer indexed loops when you need indices; withIndex() when you want both

Opening talk track

“I’ll use Kotlin with mutable maps for counts and an ArrayDeque for BFS. I’ll keep nulls out of the core path and use non-null types after validation.”

That sets expectations if the interviewer mostly reads Java.

Collections that save minutes

Example counting:

val counts = mutableMapOf<Char, Int>()
for (c in s) {
    counts[c] = counts.getOrDefault(c, 0) + 1
}

If you reach for groupingBy { it }.eachCount(), say the complexity and be ready to expand it into an explicit loop if the interviewer wants to see mechanics.

Null safety without ceremony

• Validate inputs once at the edge; keep the algorithm on non-null types.
• Avoid !! unless you can justify a proven invariant in one sentence.
• For map lookups, prefer getOrDefault / getOrPut over nullable dances.

Talk track:

“After the empty check, indices are in range, so I’ll use non-null list access and skip !!.”

Sequences vs lists

asSequence() can be elegant and also hide multiple passes. In interviews:

• Default to eager lists/loops for clarity.
• Use sequences when you explicitly want lazy pipelines and you can explain when terminal operations run.

Interviewers usually prefer a transparent O(n) loop over a clever chain they have to reverse-engineer.

Mutability and aliases

Kotlin’s read-only interfaces are not deep immutability. If you return a list that must not change, copy when needed and say so:

“I’ll return result.toList() so the caller doesn’t share my mutable buffer.”

Idioms worth having cold

// Deque BFS
val q = ArrayDeque<Int>()
q.addLast(start)
while (q.isNotEmpty()) {
    val x = q.removeFirst()
    // ...
}

// Custom sort
indices.sortedWith(compareBy({ height[it] }, { it }))

// Frequency then filter
counts.filter { it.value == 1 }.keys

Know when sorted() allocates a new list versus sorting a mutable list in place with sort().

Freeze recovery checklist

• [ ] Narrate the stuck point
• [ ] Write a clear nested-loop brute force
• [ ] Mark complexity honestly
• [ ] Replace the hot spot with a map/heap/two pointers
• [ ] Re-compile mentally after each small change

Visible progress beats redesigning the whole file in silence.

End-of-round pre-submit checklist

• [ ] Types and returns match
• [ ] Edges: empty, single, duplicates, null inputs if allowed
• [ ] No debug prints left
• [ ] Helpers named clearly
• [ ] Complexity stated
• [ ] Tiny example dry-run completed aloud
• [ ] Unicode vs ASCII clarified for string problems

Java interop on the pad

Some environments expose Java types. Be ready to:

• Prefer Kotlin listOf / mutableListOf in new code you write
• Convert with .toMutableList() when an API returns a Java List
• Remember Java HashMap allows null keys/values differently—stay in Kotlin maps when you control the code

Talk track:

“I’ll stay on Kotlin collections so nullability stays in the type system; I’ll convert at the boundary if the pad hands me Java lists.”

Scope functions without cleverness

let, also, apply, run can compress code and also hide control flow. In interviews, use at most one obvious let for null checks. Prefer explicit locals for algorithm steps so the interviewer can follow.

When the pad cannot run code

Dry-run harder:

1. Pick a 4–5 element example
2. Track map/queue contents after each iteration aloud
3. Check empty and single-element mentally
4. Only then claim you are done

Compiling in your head is part of the skill when execution is missing.

Soft practice note

If you want a Chrome side panel for calm narration and freeze recovery while you rehearse Kotlin pads, Luna Interview supports that practice loop. Use it to build composure—never as a substitute for knowing the language or for anything that violates interview rules.

Practice plan

Run the checklist until it is muscle memory: clarify, choose collections, implement, dry-run, state complexity.

Rehearse with an AI interview copilot, then browse commonly reported interview questions.