Android-Interviews drehen sich um Kotlin-Idiome, Coroutines und den Lifecycle der Plattform – die meisten Senior-Fragen wollen im Kern nur wissen, ob dir klar ist, dass dein Prozess jederzeit beendet werden kann. Es folgen die am häufigsten gestellten Fragen, jede mit einer Musterantwort. Senior: Architektur, Trade-offs, Mentoring und Entscheidungsfindung.
Nach der Grenze, die sich gemeinsam ändert, und nach der Build-Zeit. Ein Feature-Modul, das ohne den Rest gebaut und getestet werden kann, zahlt sich in Compile-Geschwindigkeit aus und macht die Abhängigkeitsrichtung explizit. Eine Aufteilung nach Layer – ein Modul aus allen View Models – erzeugt meist Module, die sich immer gemeinsam ändern, also die Kosten ohne den Nutzen.
Mach die lokale Datenbank zur Single Source of Truth und das Netzwerk zum Synchronisierer, damit die UI nie auf Konnektivität wartet. Der schwierige Teil ist dann Konflikte und Reihenfolge: eine Warteschlange ausstehender Operationen, die einen Neustart übersteht, idempotente Requests, damit ein Retry sicher ist, und eine explizite Regel dafür, wer gewinnt, wenn beide Seiten geändert haben. Das nachträglich anzuflanschen bedeutet, den Data Layer neu zu schreiben.
Starte mit der Crash-Gruppierung – welche Geräte und welche Screens, denn schwache Geräte legen offen, was andere tolerieren. Bitmaps sind meist die Antwort: ein in voller Auflösung dekodiertes Bild, das nur als Thumbnail gebraucht wird, kostet jeweils Megabyte. LeakCanary in einem Debug-Build benennt die gehaltenen Objekte, und der Memory Profiler zeigt, ob der Heap wächst und nie zurückgeht.
WorkManager, weil er den Request persistiert und die vom System durchgesetzten Constraints beachtet – Netzwerk, Laden, Doze. Eine Coroutine in einem Scope stirbt mit dem Prozess, und ein Alarm ist kein Scheduler. Die Arbeit selbst muss idempotent sein, weil das System sie wiederholt, und eine nicht-idempotente Aufgabe kann doppelt laufen.
Schrittweise und in beide Richtungen: Compose innerhalb eines Fragments, eine ComposeView in einem bestehenden Layout und der Interop, der es erlaubt, Screen für Screen zu konvertieren. Konvertiere einen Screen, wenn ohnehin daran gearbeitet wird, statt als eigenes Projekt – denn ein Rewrite ohne Produktänderung ist das Erste, was gestrichen wird, sobald sich Prioritäten verschieben.
Business-Logik und State-Reduktion als reine Unit-Tests – sie laufen in Sekunden und finden die echten Defekte. Repository- und Datenbankverhalten mit einer In-Memory-Datenbank, weil ORM-Annahmen genau das sind, was Mocks verdecken. Dann eine Handvoll Instrumentation-Tests über die Flows, die niemals brechen dürfen, im Wissen, dass sie langsam genug sind, dass eine große Suite davon irgendwann nicht mehr ausgeführt wird.
Im echten Interview sprichst du unter Druck. Cam stellt genau diese Fragen, bewertet jede Antwort und zeigt dir genau, was du verbessern musst.
Senior Android (Kotlin)-Interview üben →