Mock-Interview für Android Developer — mit AI üben

Android-Interviews prüfen zwei Dinge: wie sicher Sie in Kotlin sind und wie sehr Sie tatsächlich mit dem Lifecycle gekämpft haben. Die Kandidaten, die Angebote bekommen, kennen den Unterschied zwischen einer Configuration Change und einem Process Death, können mit Konkretem für oder gegen Jetpack Compose argumentieren und tun nicht so, als wäre der Activity-Stack einfach. Dieser Leitfaden zeigt, wie Sie AI-Mock-Interviews nutzen, um den Android-spezifischen Loop einzuüben, kalibriert auf Kotlin-first-Rollen im Jahr 2026.

Typische Interview-Runden für Android Developer

Der Android-Loop hat 4–5 Runden. Recruiter-Screen, eine Kotlin-Grundlagen-Runde (Data Classes, Sealed Classes, Scope Functions, Generics, Coroutines-Grundlagen), eine praktische Coding-Runde (ein kleines Feature in Compose oder Views bauen), eine Architektur-Runde („entwirf den Offline-Cache für dieses Feature“) und ein Behavioral. Senior-Loops fügen einen Android-Plattform-Deep-Dive hinzu (Process Lifecycle, Background-Work-Limits, Play-Store-Distribution) und ein Architektur-Review vergangener Projekte.

Die Architektur-Runde und die Kotlin-Grundlagen-Runde passen sauber zum AI-Mock-Format — sie sind gesprächslastig. Die Coding-Runde profitiert vom verbalen Durchlauf im Mock plus tatsächlicher Android-Studio-Übung nebenher. Reine UI-Implementierungs-Runden lassen sich schwerer mocken; kombinieren Sie dafür das Mock mit einem Takehome auf einem echten Gerät oder Emulator.

Wichtigste technische Themen

Kotlin-Sicherheit

Der Interviewer setzt Kotlin voraus, nicht Java. Seien Sie bereit: val vs. var mit den richtigen Defaults, Data Classes und welches equals/hashCode sie generieren, Sealed Classes und erschöpfende when-Ausdrücke für State-Modellierung, Scope Functions (let, run, apply, also, with) und wann man welche verwendet, Extension Functions und ihre Dispatch-Regeln, Generics mit Declaration-Site-Varianz (in, out), inline und reified, das Kotlin-Nullability-Modell und Platform Types aus Java-Interop. Eine häufige Falle: erklären, warum eine Java-NPE auch in einer „sicheren“ Kotlin-Codebase auftreten kann.

Coroutines und Flow

Pflicht. Seien Sie bereit: strukturierte Concurrency (Parent-Child-Cancellation), CoroutineScope vs. CoroutineContext, der Unterschied zwischen launch und async, supervisorScope vs. coroutineScope, Exception Handling (CoroutineExceptionHandler, try/catch um await), Flow vs. StateFlow vs. SharedFlow, Hot- vs. Cold-Streams, Backpressure mit Channels und buffer/conflate-Operatoren. Eine beliebte Frage: „der Nutzer navigiert mitten im Fetch weg — beschreib den richtigen Weg, zu canceln und aufzuräumen.“ Starke Antworten verketten Lifecycle-Scopes (lifecycleScope, viewModelScope) und Cancellation-Garantien.

Jetpack Compose

Compose hat sich für neue Projekte durchgesetzt, aber Views leben in 70 % der Production-Codebases. Seien Sie bereit für: das @Composable-Function-Modell und was Recomposition tatsächlich auslöst, State Hoisting und unidirektionaler Datenfluss, remember vs. rememberSaveable, LaunchedEffect vs. DisposableEffect vs. SideEffect, Modifier-Reihenfolge und warum sie wichtig ist, Lazy Lists (LazyColumn-Keys für stabile Identity), CompositionLocal für Ambient Values, Navigation (Navigation Compose vs. Navigation Component für Views). Eine häufige Debugging-Aufgabe: „die Lazy List recomposed zu aggressiv — finde heraus, warum.“

Lifecycle, Process und Configuration Changes

Das ist der Android-geformte Schmerz. Seien Sie bereit: der Activity-Lifecycle (und warum onSaveInstanceState existiert), Fragments und der duale Lifecycle, Configuration Changes vs. Process Death (und warum Ihr In-Memory-State im zweiten Fall verschwindet), die Rolle des ViewModel und was es überlebt und was nicht, lifecycle-aware Components, der Unterschied zwischen Activity-scoped und Fragment-scoped ViewModels. Eine beliebte Falle: „der Nutzer dreht das Gerät dreimal während eines Network Calls — was sollte passieren?“

Architektur und Modularisierung

MVVM mit einem Repository-Pattern ist die kanonische Antwort; die Frage ist, was als Nächstes kommt. Seien Sie bereit: MVI für State-Machine-lastige Features, Clean Architecture, um Domain vom Framework zu trennen, Modularisierung (Feature-Module vs. Layer-Module, Dynamic Feature Delivery), Dependency Injection mit Hilt oder Koin, wie eine „Single Activity, Multiple Fragments“-Architektur aussieht und wann man diese Regel bricht. Seien Sie bereit, eine Wahl in einer echten Codebase zu verteidigen.

Background-Work und Plattform-Einschränkungen

Senior-Loops graben sich ein in WorkManager (und die JobScheduler/AlarmManager-Schichten darunter), Doze Mode und App Standby, die Änderungen bei den Background-Execution-Limits ab O, Foreground Services und welche Notifications erforderlich sind, Push Notifications über Firebase Cloud Messaging, die Unterscheidung zwischen Data-only- und Notification-Message und wie man einen Process Kill mitten im Sync handhabt. Diese zu kennen, trennt einen Senior von einem Mid.

Häufige Szenario-Fragen

• „Entwirf Offline-Sync für eine Notizen-App. Room vs. raw SQLite, Konfliktauflösung, WorkManager-Scheduling.“
• „Deine LazyColumn recomposed zu oft. Führe mich durch die Diagnose.“ (Stabile Keys, immutabler State, Lambda Capture.)
• „Die App stürzt auf Samsung ab, aber nicht auf Pixel. Wie untersuchst du das?“ (OEM-Modifikationen, Manifest-Permissions, herstellerspezifische Background-Killer.)
• „Implementiere parallele Bild-Downloads mit einem Concurrency-Limit mit Coroutines.“
• „Das Team will von Views zu Compose migrieren. Roadmap?“ (ComposeView in XML, geteilte ViewModels, Rollout pro Screen, Regressionstests.)

Behavioral-Schwerpunkte — worauf Hiring Manager achten

Android-Hiring-Manager prüfen auf drei Eigenschaften. Erstens: OEM-Realismus — die Android-Welt ist nicht ein einziger Pixel-förmiger Happy Path. Starke Kandidaten haben auf Samsung, Xiaomi, Huawei ausgeliefert und haben Geschichten über herstellerspezifische Bugs. Zweitens: Play-Store-Disziplin — Sie haben eine Ablehnung gemeistert, einen Play-Protect-Fehlalarm, eine Staged-Rollout-Regression. Drittens: Achtsamkeit gegenüber App-Größe und Akku — Android-Nutzer sind preissensibler als iOS, und eine 100-MB-App oder ein 4 % Background-Akku-Verbrauch kostet Sie Installs. Erwarten Sie Fragen, die auf eine davon abzielen.

Wie Sie AI-Mock-Übungen für diese Rolle nutzen

Stellen Sie die Interview-Art auf „Tech Screening“ und wählen Sie Android als Plattform. Die AI gewichtet die Fragen in Richtung Kotlin, Coroutines, Compose und Lifecycle. Fügen Sie die Stellenanzeige ein, wenn Sie eine haben — Jetpack-Compose-only-Rollen stellen ganz andere Fragen als Codebases, die noch Views verwenden.

Für Architektur-Übung führen Sie „System Design“-Sessions mit Android-spezifischen Aufgaben durch: Offline-first-App mit WorkManager-Sync, Echtzeit-Chat mit Firebase, Payment-Flow mit Biometric Auth, Multi-Process-Service-Architektur. Die AI bohrt bei den Lifecycle-Fallen nach, die es im Web nicht gibt.

Ein Drill, der sich auszahlt: Nehmen Sie ein Compose-Feature, das Sie ausgeliefert haben, und lassen Sie die AI ein Recomposition-Interview führen. „Was löst hier Recomposition aus? Was, wenn ich diesen State ändere? Warum verursacht diese Lambda-Capture eine Recomposition?“ Das Mock findet die Lücken in Ihrem mentalen Modell von Compose, und das sind meist genau die Lücken, die Interviewer finden.

Häufig gestellte Fragen