# Kotlin 2.3 im Android-Interview: Namensbasierte Destrukturierung, KMP und Interviewfragen 2026 > Kotlin 2.3 Interviewfragen zu namensbasierter Destrukturierung, Kotlin Multiplatform, Kontextparametern, Coroutines und Flow. Vorbereitung auf Android-Entwickler-Interviews 2026 mit praxisnahen Codebeispielen. - Published: 2026-05-06 - Updated: 2026-05-06 - Author: SharpSkill - Tags: kotlin, android, interview, kmp, kotlin-multiplatform, coroutines - Reading time: 5 min --- Kotlin 2.3 Interviewfragen gehören 2026 zu den meistgesuchten Themen für Android-Entwicklerstellen. Mit namensbasierter Destrukturierung, stabilisierten Kontextparametern und einem ausgereiften Kotlin-Multiplatform-Ökosystem erwarten Interviewer von Bewerbern fundierte Kenntnisse dieser Neuerungen. > **Was sich in Kotlin 2.3 geändert hat** > > Kotlin 2.3.20, veröffentlicht im März 2026, führt namensbasierte Destrukturierungsdeklarationen, Änderungen bei der Überladungsauflösung für Kontextparameter und verbesserte KMP-Interoperabilität mit C und TypeScript ein. Diese Features tauchen regelmäßig in Senior-Android-Interviews auf. ## Namensbasierte Destrukturierung: Die häufigste Kotlin-2.3-Interviewfrage Vor Kotlin 2.3 basierten Destrukturierungsdeklarationen auf positionsbasierten `componentN()`-Funktionen. Das führte zu einem bekannten Problem: Wurde die Reihenfolge der Properties in einer Data Class geändert, brachen bestehende Destrukturierungsstellen lautlos zusammen. Die klassische Interviewfrage präsentiert genau dieses Szenario: ```kotlin // User.kt data class User(val username: String, val email: String) fun main() { val user = User("alice", "alice@example.com") // Position-based: order matters, not names val (email, username) = user println(email) // Prints "alice" -- wrong! println(username) // Prints "alice@example.com" -- wrong! } ``` Kotlin 2.3.20 löst dieses Problem mit namensbasierter Destrukturierung. Drei Compiler-Modi steuern das Verhalten: ```kotlin // build.gradle.kts kotlin { compilerOptions { // Mode 1: Explicit syntax only freeCompilerArgs.add("-Xname-based-destructuring=only-syntax") // Mode 2: Warns on name mismatch // freeCompilerArgs.add("-Xname-based-destructuring=name-mismatch") // Mode 3: Full name-based by default // freeCompilerArgs.add("-Xname-based-destructuring=complete") } } ``` Im `complete`-Modus verwenden runde Klammern namensbasiertes Matching, während eckige Klammern das positionsbasierte Verhalten beibehalten: ```kotlin // NameBasedDestructuring.kt data class User(val username: String, val email: String) fun main() { val user = User("alice", "alice@example.com") // Name-based: matches by property name val (email, username) = user println(email) // "alice@example.com" -- correct println(username) // "alice" -- correct // Position-based: square brackets preserve old behavior val [first, second] = user println(first) // "alice" (component1) println(second) // "alice@example.com" (component2) } ``` Eine überzeugende Antwort im Interview erklärt alle drei Modi und benennt die passenden Einsatzszenarien: `only-syntax` für schrittweise Migration, `name-mismatch` zum Aufspüren von Fehlern in bestehendem Code und `complete` für neue Projekte. ## Kotlin-Multiplatform-Interviewfragen für Android-Entwickler KMP hat die experimentelle Phase hinter sich gelassen. Google unterstützt es offiziell für die gemeinsame Nutzung von Geschäftslogik zwischen Android und iOS, und die meisten neuen plattformübergreifenden Projekte setzen standardmäßig auf eine Shared-Core-Architektur. Eine typische Interviewfrage lautet: "Wie würden Sie ein KMP-Modul für gemeinsames Networking strukturieren?" ```kotlin // shared/src/commonMain/kotlin/com/app/network/ApiClient.kt import io.ktor.client.* import io.ktor.client.request.* import io.ktor.client.statement.* import kotlinx.serialization.Serializable import kotlinx.serialization.json.Json @Serializable data class UserProfile( val id: String, val displayName: String, val avatarUrl: String? ) // Expect/actual pattern for platform-specific HTTP engine expect fun createHttpClient(): HttpClient class ApiClient { private val client = createHttpClient() private val json = Json { ignoreUnknownKeys = true } // Suspend function shared across Android and iOS suspend fun fetchProfile(userId: String): UserProfile { val response = client.get("https://api.example.com/users/$userId") return json.decodeFromString(response.bodyAsText()) } } ``` ```kotlin // shared/src/androidMain/kotlin/com/app/network/HttpClient.android.kt import io.ktor.client.* import io.ktor.client.engine.okhttp.* // Android uses OkHttp engine actual fun createHttpClient(): HttpClient = HttpClient(OkHttp) { engine { config { retryOnConnectionFailure(true) } } } ``` Interviewer bewerten, ob der Bewerber den Expect/Actual-Mechanismus, plattformspezifische Abhängigkeiten und die Grenze zwischen geteiltem und plattformspezifischem Code versteht. Eine weitere häufige Frage betrifft [Swift Export](https://kotlinlang.org/docs/whatsnew2320.html), das sich 2026 erheblich weiterentwickelt hat. Kotlin-Suspend-Funktionen werden jetzt direkt auf Swift async/await abgebildet, und Sealed Classes entsprechen Swift Enums mit assoziierten Werten. ## Kontextparameter und Änderungen bei der Überladungsauflösung Kontextparameter ersetzen die veraltete Context-Receivers-API. Kotlin 2.3.20 führte eine Breaking Change bei der Überladungsauflösung ein: Deklarationen mit Kontextparametern werden nicht mehr als spezifischer behandelt als solche ohne. ```kotlin // ContextParameters.kt class Logger { fun info(msg: String) = println("INFO: $msg") } class TransactionScope { fun execute(block: () -> Unit) = block() } // Function with context parameter context(logger: Logger) fun saveUser(id: Int) { logger.info("Saving user $id") } // Overload without context -- now ambiguous in 2.3.20 fun saveUser(id: Int) { println("Saving user $id (no logger)") } fun main() { val logger = Logger() // This now produces an ambiguity error in Kotlin 2.3.20 // context(logger) { saveUser(1) } // Fix: rename or qualify the context-aware variant } ``` Interviewer nutzen dieses Thema, um das Bewusstsein für Breaking Changes und Migrationsstrategien zu prüfen. Die zentrale Erkenntnis: Sich auf die implizite Auflösung von Kontextparametern zu verlassen, um nicht-kontextuelle Überladungen zu überlagern, funktioniert nicht mehr. ## Coroutines und Flow: Weiterhin das Top-Thema im Android-Interview Trotz der neuen Features in Kotlin 2.3 bleiben Coroutines und Flow der am häufigsten geprüfte Bereich. Interviewfragen untersuchen typischerweise den Unterschied zwischen Cold und Hot Flows, Structured Concurrency und Cancellation. ```kotlin // FlowComparison.kt import kotlinx.coroutines.* import kotlinx.coroutines.flow.* // Cold Flow: emits only when collected fun userUpdates(): Flow = flow { println("Flow started") // Runs per collector emit("User logged in") delay(1000) emit("User updated profile") } // Hot Flow: emits independently of collectors class UserRepository { // StateFlow holds the latest value private val _state = MutableStateFlow("idle") val state: StateFlow = _state.asStateFlow() // SharedFlow broadcasts to multiple collectors private val _events = MutableSharedFlow() val events: SharedFlow = _events.asSharedFlow() suspend fun login() { _state.value = "loading" delay(500) _state.value = "authenticated" _events.emit("login_success") } } ``` Eine Folgefrage betrifft oft das sichere Sammeln von Flows in Android: ```kotlin // UserViewModel.kt import androidx.lifecycle.ViewModel import androidx.lifecycle.viewModelScope import kotlinx.coroutines.flow.* import kotlinx.coroutines.launch class UserViewModel(private val repo: UserRepository) : ViewModel() { // Expose state to Compose UI val uiState: StateFlow = repo.state .stateIn( scope = viewModelScope, started = SharingStarted.WhileSubscribed(5000), initialValue = "idle" ) init { // Collect events safely within ViewModel scope viewModelScope.launch { repo.events.collect { event -> // Handle one-time events println("Event received: $event") } } } } ``` Die `WhileSubscribed(5000)`-Strategie hält den Upstream 5 Sekunden nach dem Verschwinden des letzten Subscribers aktiv und verhindert so unnötige Neustarts bei Konfigurationsänderungen wie Bildschirmrotation. ## Sealed Classes und exhaustive When-Ausdrücke: Pattern Matching im Interview Sealed Classes tauchen in nahezu jedem Android-Interview auf. Die Frage fordert Bewerber typischerweise auf, einen UI-State zu modellieren: ```kotlin // UiState.kt sealed interface UiState { data object Loading : UiState data class Success(val data: T) : UiState data class Error(val message: String, val retry: (() -> Unit)? = null) : UiState } // Usage in ViewModel fun loadUsers(): Flow>> = flow { emit(UiState.Loading) try { val users = apiClient.fetchUsers() emit(UiState.Success(users)) } catch (e: Exception) { emit(UiState.Error( message = e.localizedMessage ?: "Unknown error", retry = { /* trigger reload */ } )) } } ``` In Kotlin sind `when`-Ausdrücke über Sealed Types zur Kompilierzeit exhaustiv. Das Hinzufügen eines neuen Subtyps erzwingt dessen Behandlung an allen Stellen, was eine ganze Kategorie von Laufzeitfehlern eliminiert. Interviewer prüfen gezielt, ob der Bewerber `sealed interface` (nicht `sealed class`) für dieses Pattern verwendet, da Interfaces flexiblere Hierarchien ermöglichen. ## Kotlin/Wasm und plattformübergreifende Kompilierungsziele Kotlin/Wasm hat den Beta-Status erreicht und bietet nahezu native Performance in Browsern. Obwohl es für Android-Entwickler noch kein tägliches Thema ist, wird bei Unternehmen mit Web- und Mobilprodukten danach gefragt. Wichtige Fakten für das Interview: - Kotlin 2.3.20 lieferte eine 4,6-fach schnellere String-Interpolation in Wasm durch JS-String-Builtins - Binärgrößen wurden um etwa 5 % reduziert - Clean Builds laufen 65 % schneller, inkrementelle Builds 21 % schneller - Die `@nativeInvoke`-Annotation ermöglicht es Kotlin-Objekten, als JavaScript-Funktionen zu agieren Kotlin/JS erhielt zudem die Fähigkeit, Kotlin-Interfaces aus TypeScript zu implementieren, was eine bisherige Einschränkung beseitigt. In Kombination mit SWC-Unterstützung für die Transpilation deckt Kotlin jetzt Android, iOS (über KMP), Web (über Wasm/JS) und serverseitige Ziele aus einer einzigen Codebasis ab. ## Scope Functions: Ein unterschätzter Filter im Interview Scope Functions (`let`, `run`, `with`, `apply`, `also`) wirken einfach, unterscheiden aber erfahrene Kotlin-Entwickler. Die Interviewfrage lautet meist: "Wann verwenden Sie `let` im Vergleich zu `apply`?" ```kotlin // ScopeFunctions.kt data class Request( var url: String = "", var method: String = "GET", var headers: MutableMap = mutableMapOf(), var body: String? = null ) fun buildRequest(): Request { // apply: configure an object, returns the object return Request().apply { url = "https://api.example.com/users" method = "POST" headers["Content-Type"] = "application/json" body = "{\"name\": \"Alice\"}" } } fun processNullable(input: String?) { // let: transform nullable, returns lambda result val length = input?.let { value -> println("Processing: $value") value.trim().length } ?: 0 // also: side effects, returns the original object input?.also { println("Logging input: $it") } // run: execute a block with receiver, returns lambda result val result = input?.run { // 'this' is the string uppercase().take(10) } } ``` Das Entscheidungsschema: `apply` für Objektkonfiguration (gibt den Empfänger zurück), `let` für null-sichere Transformationen (gibt das Lambda-Ergebnis zurück), `also` für Seiteneffekte (gibt den Empfänger zurück), `run` für die Berechnung eines Ergebnisses mit Empfängerkontext. ## Null Safety und die Gefahr des Double-Bang-Operators Null Safety bleibt ein fundamentales Interviewthema. Die Frage "Warum ist `!!` gefährlich?" prüft, ob ein Bewerber das Typsystem von Kotlin wirklich versteht. ```kotlin // NullSafety.kt fun findUser(id: String): User? { // Returns null if user not found return database.queryUser(id) } // Bad: !! defeats the purpose of null safety fun riskyApproach(id: String) { val user = findUser(id)!! // NullPointerException if null println(user.username) } // Good: handle null explicitly fun safeApproach(id: String) { val user = findUser(id) ?: run { println("User not found") return } println(user.username) } // Good: provide default with Elvis operator fun displayName(id: String): String { return findUser(id)?.username ?: "Anonymous" } ``` Eine vollständige Antwort erwähnt, dass `!!` nur in Testcode oder an Plattform-Interop-Grenzen erscheinen sollte, wo Null tatsächlich unmöglich ist. ## Fazit - Namensbasierte Destrukturierung in Kotlin 2.3.20 eliminiert positionsabhängige Fehler. Alle drei Compiler-Modi sollten bekannt sein: `only-syntax`, `name-mismatch`, `complete` - KMP ist 2026 produktionsstabil. Fragen zu Expect/Actual, Shared-Module-Architektur und Swift-Export-Interop sind zu erwarten - Kontextparameter haben Context Receivers ersetzt. Die Änderung der Überladungsauflösung in 2.3.20 ist eine beliebte Fangfrage - Coroutines und Flow dominieren Android-Interviews. `StateFlow` vs. `SharedFlow`, `WhileSubscribed` und Structured Concurrency müssen beherrscht werden - Sealed Interfaces modellieren UI-State mit Compile-Time-Exhaustivität. `sealed interface` ist gegenüber `sealed class` zu bevorzugen - Scope Functions erfordern ein klares Entscheidungsschema: Empfänger vs. Argument, Rückgabewert vs. Empfänger - Null Safety ist nicht verhandelbar. Es muss klar begründet werden können, warum `!!` das Typsystem unterminiert, und Alternativen müssen demonstriert werden können --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/de/blog/android/kotlin-2-3-interview-questions