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 / 10
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 / 10
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 / 10
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 / 10
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.
6 / 10
Code Review Comment: 'This function doesn't seem to handle null values correctly. It could crash if the input is null. Consider adding a check.' What does this comment primarily suggest regarding the shared module code?
This comment highlights a key concern: consistency. The reviewer is advocating for an identical implementation across all platforms, implying that the platform-specific handling of nulls should be addressed separately and ideally mirrored to avoid unexpected behavior. Options A & B are too broad; option D suggests prioritizing less critical issues.
7 / 10
Slack Message: 'Hey @john_doe, just wanted to flag that the generated JSON data from the iOS app is significantly larger than the Android version. We should investigate why.' What's the *most* important next step for investigating this issue in a Kotlin Multiplatform project?
The core of the issue is data transformation. While options A & B are relevant longer-term considerations, option 1 directly addresses the root cause – differences in how the shared module prepares the data before sending it to each platform. Option C and D address symptoms rather than the underlying problem.
8 / 10
PR Description: 'This PR introduces a new shared module for handling user authentication. It includes a common interface and implementations for both Android and iOS.' Which of the following statements best describes a crucial design consideration for this shared module?
A key principle of KMP is *separation of concerns*. Option 1 advocates for tight coupling which defeats the purpose. Option 3 focuses on generality, aligning with KMP's goal. Option D is incorrect as it promotes unnecessary code duplication and a less maintainable architecture.
9 / 10
Standup Update: 'I've been working on integrating the shared module for our location services. I'm currently wrestling with how to efficiently handle timezone conversions across both iOS and Android.' What is a primary architectural consideration when dealing with platform-specific differences in timezones within a KMP project?
Timezone management is notoriously complex. Option 1 promotes a potentially incorrect approach and ignores daylight saving time. While option 3 might seem appealing, it introduces centralized complexity. Option 2 acknowledges the need for platform-specific adaptation – accurately converting to the user's local timezone.
The backend API is returning this JSON response for a product list. Which of the following best describes how a Kotlin Multiplatform developer should *primarily* handle data transformation and mapping within their platform-specific code to access this data?
While using the shared module is beneficial for consistency, the *initial* parsing should happen on each platform. Option 2 introduces unnecessary complexity within the shared module. Option 3 creates an adapter class which is not always necessary and can add overhead, while option D represents a fundamental misunderstanding of KMP's purpose.
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 10 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.