Kotlin 2.3 im Android-Interview: Namensbasierte Destrukturierung, KMP und Interviewfragen 2026

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.

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:

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 {
    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:

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?"

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())
    }
}

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, 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.

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.

import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

// Cold Flow: emits only when collected
fun userUpdates(): Flow<String> = 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<String> = _state.asStateFlow()

    // SharedFlow broadcasts to multiple collectors
    private val _events = MutableSharedFlow<String>()
    val events: SharedFlow<String> = _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:

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<String> = 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:

sealed interface UiState<out T> {
    data object Loading : UiState<Nothing>
    data class Success<T>(val data: T) : UiState<T>
    data class Error(val message: String, val retry: (() -> Unit)? = null) : UiState<Nothing>
}

// Usage in ViewModel
fun loadUsers(): Flow<UiState<List<UserProfile>>> = 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?"

data class Request(
    var url: String = "",
    var method: String = "GET",
    var headers: MutableMap<String, String> = 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.

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