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.