Android Developer Vorstellungsgespräch: Fragen & Antworten (mit Musterantworten)

Musterantwort

Ich setze auf eine klare Schichtentrennung nach Clean Architecture mit Presentation-, Domain- und Data-Layer. In der Praxis nutze ich MVVM mit ViewModels, die UI-State über StateFlow exponieren, und kapsle Geschäftslogik in Use Cases. Abhängigkeiten injiziere ich mit Hilt, sodass ich Repositories in Unit-Tests problemlos durch Fakes ersetzen kann. Diese Trennung hat in meinem letzten Projekt die Testabdeckung der Domain-Schicht auf über 80 Prozent gebracht.

Musterantwort

In einer Liste mit Bildern hatten wir spürbares Ruckeln beim Scrollen. Mit dem Android Profiler habe ich Jank auf dem Main-Thread durch synchrone Bilddekodierung identifiziert. Ich habe das Laden auf Coil mit Caching umgestellt und die RecyclerView durch DiffUtil mit stabilen IDs optimiert. Danach lag die Frame-Rate stabil bei 60 fps statt vorher rund 40.

Musterantwort

Ich verfolge die offiziellen Android-Developers-Blogs und die Release Notes von Jetpack-Bibliotheken. Außerdem schaue ich ausgewählte Sessions der Google I/O und teste neue APIs in kleinen Sandbox-Projekten. Zuletzt habe ich mich intensiv mit Jetpack Compose und der Migration von XML-Layouts beschäftigt. So kann ich Empfehlungen fundiert statt nach Bauchgefühl aussprechen.

Musterantwort

Ich versuche zuerst, die zugrunde liegenden Anforderungen und Bedenken sachlich zu verstehen, statt auf meiner Lösung zu beharren. In einer Diskussion über RxJava versus Coroutines habe ich beide Ansätze an einem Prototyp gegenübergestellt und die Ergebnisse im Team präsentiert. Wir haben uns dann gemeinsam für Coroutines entschieden, weil sie besser zur restlichen Codebasis passten. Der faktenbasierte Vergleich hat die Diskussion sachlich gehalten.

Musterantwort

Mich reizt, dass Ihre App im Bereich Mobile Banking eine große Nutzerbasis hat und damit hohe Ansprüche an Stabilität und Sicherheit stellt. Ich habe gesehen, dass Sie früh auf Jetpack Compose gesetzt haben, was zu meinem Schwerpunkt der letzten zwei Jahre passt. Ich möchte zu einem Produkt beitragen, das täglich von vielen Menschen genutzt wird. Außerdem schätze ich Ihren öffentlich dokumentierten Fokus auf Code-Qualität und Reviews.

launch startet eine Coroutine, die kein Ergebnis zurückgibt und ein Job-Objekt liefert, ideal für Fire-and-forget-Aufgaben. async startet eine Coroutine, die ein Deferred zurückgibt, dessen Ergebnis man mit await abruft. async eignet sich, wenn man parallele Berechnungen anstoßen und deren Resultate später zusammenführen will.

Bei einer Rotation wird die Activity standardmäßig zerstört und neu erstellt, wobei onPause, onStop und onDestroy sowie anschließend onCreate erneut durchlaufen werden. Transienter UI-State sollte im ViewModel oder über onSaveInstanceState gehalten werden, da das ViewModel die Konfigurationsänderung überlebt. So vermeidet man Datenverlust beim Drehen des Geräts.

Compose ist ein deklaratives UI-Toolkit, bei dem die Oberfläche als Funktion des Zustands beschrieben wird und bei Zustandsänderungen automatisch rekomponiert. Das klassische View-System ist imperativ und erfordert manuelles Aktualisieren einzelner Views. Compose reduziert Boilerplate, verbessert die Wiederverwendbarkeit und integriert State-Handling direkt über remember und State-Objekte.

Ich vermeide es, einen Activity-Context in langlebigen Objekten oder statischen Feldern zu halten, und nutze stattdessen den Application-Context, wenn keine UI-Bindung nötig ist. Listener und Callbacks registriere ich im Lifecycle-konformen Bereich ab und nutze WeakReferences, wo sinnvoll. Mit LeakCanary überprüfe ich verdächtige Stellen während der Entwicklung.

WorkManager ist die empfohlene API für aufschiebbare, garantierte Hintergrundarbeit, etwa das Hochladen von Logs oder regelmäßige Synchronisation. Er respektiert Systembeschränkungen wie Doze-Modus und Battery-Optimierungen und führt Aufgaben auch nach einem Neustart aus. Man definiert Constraints wie Netzwerkverfügbarkeit und WorkManager wählt den passenden Ausführungszeitpunkt.

In einer Produktionsversion stieg die Crash-Rate nach einem Release plötzlich auf fünf Prozent (Situation). Meine Aufgabe war es, die Ursache schnell zu finden und einen Hotfix bereitzustellen (Task). Ich habe über Firebase Crashlytics einen NullPointerException in einem neuen Deeplink-Pfad lokalisiert, einen Guard eingebaut und einen Staged Rollout gestartet (Action). Die Crash-Rate fiel innerhalb eines Tages unter 0,2 Prozent und wir haben anschließend einen Pre-Release-Check für Deeplinks etabliert (Result).

Vor einem wichtigen Messetermin fehlte eine Offline-Funktion in der App (Situation). Ich sollte sie in zwei Wochen lauffähig liefern (Task). Ich habe den Umfang auf das Kernszenario reduziert, eine Room-Datenbank für lokales Caching eingeführt und täglich kurze Abstimmungen mit dem Product Owner gehalten (Action). Die Funktion war pünktlich zur Messe stabil verfügbar und wurde später schrittweise erweitert (Result).

Ein Kollege bemängelte meine Verschachtelung von Coroutines als schwer lesbar (Situation). Ich wollte zunächst meine Lösung verteidigen, sollte aber offen prüfen, ob die Kritik berechtigt war (Task). Ich habe den Code mit der vorgeschlagenen Flow-Variante verglichen und gemerkt, dass diese tatsächlich testbarer war (Action). Ich habe die Änderung übernommen und seitdem nutze ich diesen Stil als Standard, was Reviews schneller macht (Result).

Ein neuer Kollege hatte Schwierigkeiten mit dem Dependency-Injection-Setup über Hilt (Situation). Ich sollte ihn einarbeiten, ohne ihm die Aufgabe abzunehmen (Task). Ich habe in einer Pair-Programming-Session die Module gemeinsam mit ihm aufgebaut und ihm anschließend eine kurze Notiz mit den Kernkonzepten gegeben (Action). Er konnte die folgenden Features eigenständig umsetzen und das Team profitierte von der Dokumentation (Result).