5 exercises — practice structuring strong English answers for Kotlin Multiplatform interviews: architecture, expect/actual, iOS interop, and trade-offs.
How to structure KMP interview answers
Architecture questions: shared module boundaries → what belongs in shared vs. platform-specific → dependency injection across platforms
expect/actual questions: define the mechanism → give an example → explain when to use it vs. a common module
iOS interop questions: Kotlin → Objective-C → Swift exposure → SKIE library for improved Swift API
Trade-off questions: KMP vs. Flutter vs. React Native — be specific about UI, ecosystem, and team skill alignment
The interviewer asks: "Explain the expect/actual mechanism in Kotlin Multiplatform." Which answer is clearest?
Option B is strongest: it reframes expect/actual as compile-time dependency injection (the key conceptual insight), gives a concrete code example (currentTimestampMs), distinguishes when to use expect/actual from when to prefer a multiplatform library (most candidates miss this), recommends DI injection as an alternative for class dependencies, and names SKIE as the solution for Swift API ergonomics. KMP vocabulary:commonMain — the source set containing shared Kotlin code. androidMain / iosMain — platform-specific source sets. expect — a contract declaration with no implementation. actual — the platform-specific implementation of an expect declaration. Kotlin/Native — the KMP compiler target for iOS/macOS. SKIE (Swift Kotlin Interface Enhancer) — a Kotlin plugin that generates idiomatic Swift extensions for Kotlin/Native APIs. kotlinx-datetime — the official multiplatform datetime library. Options C and D are accurate but lack the DI injection alternative and the concrete code example.
2 / 5
The interviewer asks: "What code should vs. should not be in the shared module?" Which answer has the clearest boundaries?
Option B is strongest: it states the governing principle before listing examples, provides the grey zone analysis of ViewModels (a real architectural debate in KMP teams), names the specific multiplatform ViewModel library as the solution to iOS coroutine scope management, and names the red flag (Android SDK imported in commonMain) with the specific consequence (build error on iOS). KMP shared module vocabulary:commonMain — the shared source set visible to all KMP targets. StateFlow — a Kotlin coroutines construct for observable state; works in commonMain. Ktor — the official Kotlin multiplatform HTTP client. SQLDelight — a multiplatform SQL database library generating type-safe Kotlin from SQL. Dependency scoping — ensuring platform-specific dependencies are only available in their target source set. Options C and D are accurate but lack the ViewModel grey zone discussion and the build error consequence of wrong scoping.
3 / 5
The interviewer asks: "What limitations exist in KMP that don't exist in Flutter?" Which answer is most balanced?
Option B is strongest: it acknowledges that Compose Multiplatform adds shared UI to KMP (not a binary limitation), explains the trade-off accurately (Canvas-based CMP vs. native UIKit), names the specific iOS friction points with the root cause for each (Kotlin/Native slow builds, Obj-C bridge generics erasure, ARC vs. GC), and frames the ecosystem gap concretely. KMP vs. Flutter vocabulary:Compose Multiplatform (CMP) — the separate Kotlin multiplatform UI framework based on Jetpack Compose. Kotlin/Native — the compiler for KMP iOS/macOS targets; does not use JVM. ARC (Automatic Reference Counting) — iOS memory management; Kotlin/Native must interop with it. SKIE — Swift API enhancement plugin for KMP. CocoaPods — the iOS dependency manager used to integrate KMP frameworks. Options C and D are accurate but lack the Compose Multiplatform nuance (Canvas vs. native) and the ARC explanation.
4 / 5
The interviewer asks: "How do you expose KMP code to Swift?" Which answer is most practical?
Option B is strongest: it names all four layers with specific details for each, explains what IS and IS NOT directly exposed through the bridge (the generics erasure and coroutine gap are the critical knowledge gaps), presents three concrete options for coroutine exposure in order of preference, and recommends KMMBridge/Touchlab templates as the practical starting point. KMP-to-Swift vocabulary:XCFramework — a binary framework format that bundles slices for multiple architectures. Kotlin/Native compiler — generates Objective-C headers for Kotlin declarations. Generics erasure — Kotlin type parameters are lost in the Obj-C bridge. SKIE — generates idiomatic Swift extensions: suspend → async/await, Flow → AsyncSequence. AsyncSequence — Swift's asynchronous sequence protocol. KMMBridge — tooling for publishing KMP frameworks as versioned Swift Packages. Options C and D are accurate but lack the three-option coroutine exposure progression and the KMMBridge tooling recommendation.
5 / 5
The interviewer asks: "How do you handle dependency injection across platforms in KMP?" Which answer is most architectural?
Option B is strongest: it names three concrete DI options with a rationale for each, distinguishes Koin's service locator pattern from true compile-time DI (a nuanced distinction many candidates miss), explains KSP as the mechanism enabling Kotlin Inject to work in KMP, names the "ports and adapters" architectural pattern as the governing principle, and names the common mistake with the reason it's harmful. KMP DI vocabulary:Koin — a lightweight Kotlin DI framework using a service locator pattern. Service locator — a runtime pattern where dependencies are looked up from a registry. Kotlin Inject — a compile-time DI framework for Kotlin Multiplatform. KSP (Kotlin Symbol Processing) — Kotlin's annotation processing API; used by compile-time frameworks. Ports and adapters (hexagonal architecture) — the pattern of defining interfaces in the domain layer and implementing them in adapters at the platform layer. Options C and D are accurate but lack the service locator vs. true DI distinction and the hexagonal architecture naming.
What does "Kotlin Multiplatform Developer Interview Questions — IT English Practice — IT English Practice" cover?
Practice answering Kotlin Multiplatform (KMP) interview questions in English: expect/actual mechanism, shared module design, Swift interop, and KMP vs. Flutter comparisons.
How many questions are in this interview set?
This set has 5 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.