5 exercises — choose the best-structured answer to common Kotlin Developer interview questions. Focus on precise vocabulary, correct use of technical terms, and demonstrating real experience.
Structure for Kotlin interview answers
Name the coroutine builder: launch vs async — state the return type (Job vs Deferred) and use case
Explain scope hierarchy: describe how CoroutineScope ties lifetime and propagates cancellation
Address structured concurrency: mention the "no coroutine outlives its scope" guarantee and why it matters
Mention dispatcher types: IO for blocking I/O, Default for CPU, Main for UI — with a real example
0 / 5 completed
1 / 5
The interviewer asks: "How do Kotlin coroutines differ from threads, and what is structured concurrency?" Which answer best explains Kotlin's concurrency model?
Option B is strongest: it explains the compile-time mechanism (state machines), names structured concurrency and its specific guarantee (no coroutine outlives its scope), distinguishes launch vs async precisely (Job vs Deferred), lists all three standard Dispatchers with correct use cases, and mentions exception propagation through the hierarchy — a common interview follow-up. Key structure: suspend functions as state machines → CoroutineScope lifetime → structured concurrency guarantee → launch/async distinction → Dispatchers → exception hierarchy. Option C is accurate but does not explain the state machine compilation or exception propagation. Option D focuses on Android memory leaks but does not explain Dispatchers or the launch/async distinction.
2 / 5
The interviewer asks: "What are sealed classes in Kotlin, and how do they differ from enums?" Which answer best explains sealed class use cases?
Option B is strongest: it gives the precise compile-time constraint (all subclasses in the same compilation unit), explains exhaustive when as a compiler guarantee (not just a convenience), clearly states the enum difference (same shape vs different state per case), provides two concrete use cases with specific field types, and introduces sealed interfaces as a Kotlin 1.5+ extension with the reason it exists (multiple hierarchy membership). Key structure: compile-time closed hierarchy → exhaustive when guarantee → vs enum (shape vs state) → concrete examples with field types → sealed interfaces for multiple hierarchies. Option C is accurate but does not explain the exhaustive when as a compiler safety feature and conflates "same package" (Java) with "same compilation unit" (Kotlin). Option D explains the enum difference but misses sealed interfaces and the compilation-unit constraint.
3 / 5
The interviewer asks: "How do extension functions work in Kotlin, and what are the pitfalls?" Which answer best covers both mechanics and edge cases?
Option B is strongest: it explains the compilation mechanism (static function with receiver), gives the critical dispatch rule with a concrete scenario (base-class variable doesn't call subclass extension), explains the platform type pitfall (unique to Kotlin-Java interop and commonly missed), gives examples of both good and bad uses with reasoning. Key structure: compiles to static function → no private access, no override → statically resolved (member wins) → platform type null-safety risk → nullable receiver extensions → good vs bad uses. Option C covers static resolution correctly but does not explain platform types or the member-wins conflict rule. Option D mentions the static dispatch and nullable extensions but misses platform types and the member conflict precedence rule.
4 / 5
The interviewer asks: "How does Kotlin's null safety system work, and when is it appropriate to use the !! operator?" Which answer best explains null safety discipline?
Option B is strongest: it gives the type system mechanics precisely, explains all four key patterns (safe call, Elvis, smart casts, !!), gives the only legitimate use case for !! with a concrete example, names the specific exception thrown (KotlinNullPointerException, distinct from Java NPE), identifies !! overuse as a code smell, offers two alternatives (requireNotNull with message, restructuring), and introduces lateinit var as the correct solution for DI fields — a real Android/Spring interview topic. Key structure: type system encoding → safe call + Elvis + smart casts → !! only for compiler-opaque certainty → KotlinNPE vs NPE → alternatives to !! → lateinit for DI. Option C is accurate but does not mention the specific exception type, requireNotNull, or lateinit. Option D recommends avoiding !! in production without explaining the one legitimate use case.
5 / 5
The interviewer asks: "What is Kotlin Multiplatform, and how does it differ from cross-platform frameworks like Flutter?" Which answer best explains KMP's architecture?
Option B is strongest: it precisely explains the expect/actual mechanism as a contract/implementation split, lists concrete shared-module libraries (Ktor, SQLDelight) giving real technology depth, explains the iOS compilation output specifically (XCFramework), makes the Flutter comparison at the architectural level (rendering engine vs logic only), and mentions Compose Multiplatform as the emerging shared-UI path — showing awareness of the roadmap. Key structure: expect/actual contract pattern → what lives in shared module (with concrete libs) → iOS compilation target → vs Flutter: rendering engine vs native UI → KMM subset + Compose Multiplatform direction. Option C is accurate but does not explain what XCFramework is or mention Compose Multiplatform. Option D explains the trade-off well but does not name specific shared-module libraries or the iOS output format.