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

Musterantwort

Ich halte den Hauptthread frei und verlagere aufwendige Arbeit wie Netzwerkzugriffe und Berechnungen in den Hintergrund. Listen und Bilder optimiere ich durch Wiederverwendung von Ansichten und Lazy Loading, um Speicher und Ruckler zu vermeiden. Mit den Profiling-Werkzeugen der Plattform messe ich gezielt Engpässe. Performance teste ich auch auf schwächeren Geräten, nicht nur auf High-End-Hardware.

Musterantwort

Ich setze auf flexible, responsive Layouts statt fester Pixelwerte, damit sich die Oberfläche an verschiedene Größen anpasst. Ressourcen wie Bilder lege ich in mehreren Auflösungen an. Ich teste auf einer Auswahl realer Geräte und Emulatoren, um Probleme früh zu erkennen. Auch unterschiedliche Betriebssystemversionen behalte ich dabei im Blick.

Musterantwort

Ich gehe davon aus, dass die Verbindung jederzeit abbrechen kann, und gestalte die App entsprechend robust. Daten cache ich lokal, damit Nutzer auch offline sinnvoll arbeiten können. Aktionen, die das Netz brauchen, stelle ich in eine Warteschlange und synchronisiere sie, sobald wieder Verbindung besteht. Dem Nutzer gebe ich klares Feedback über den Verbindungsstatus.

Musterantwort

Ich vermeide unnötige Bibliotheken und komprimiere Ressourcen, um die App schlank zu halten. Hintergrundaktivität und Standortabfragen reduziere ich auf das Nötige, da sie stark am Akku zehren. Netzwerkaufrufe bündle ich, statt sie ständig einzeln auszulösen. Mit den Energieprofilen der Plattform prüfe ich, wo die App unnötig Strom verbraucht.

Musterantwort

Eine App stürzte auf bestimmten Geräten häufig ab und hatte schlechte Bewertungen. Ich habe über ein Crash-Reporting-Tool die häufigsten Abstürze identifiziert und priorisiert behoben. Außerdem habe ich die Ladezeiten durch besseres Caching deutlich verkürzt. Die Absturzrate sank stark und die Bewertungen verbesserten sich merklich.

Der Lebenszyklus beschreibt die Zustände, die eine App oder ein Screen durchläuft, etwa Erstellen, Anzeigen, Pausieren und Beenden. Das richtige Verhalten in den jeweiligen Phasen, etwa das Speichern von Zustand, ist entscheidend, um Datenverlust und Fehler zu vermeiden.

Native Entwicklung nutzt die Sprachen und Werkzeuge einer Plattform und bietet beste Performance und Zugriff auf alle Funktionen. Plattformübergreifende Frameworks wie React Native oder Flutter teilen Code zwischen iOS und Android, was Aufwand spart, aber gewisse Kompromisse bedeuten kann.

Ich trenne UI-Zustand von Geschäftslogik und nutze ein etabliertes Architekturmuster wie MVVM. Geteilten Zustand bündle ich an einer klaren Stelle und sorge dafür, dass die Oberfläche reaktiv auf Änderungen reagiert, statt Daten an mehreren Stellen zu duplizieren.

Ich frage Berechtigungen erst dann an, wenn sie für eine konkrete Funktion gebraucht werden, und erkläre dem Nutzer den Grund. Die App muss auch dann sinnvoll funktionieren, wenn eine Berechtigung verweigert wird, und darf nicht abstürzen.

Sensible Daten wie Tokens speichere ich im sicheren Speicher der Plattform, etwa Keychain oder Keystore, statt im Klartext. Die Kommunikation mit dem Server verschlüssele ich konsequent über HTTPS und vermeide es, mehr Daten als nötig lokal abzulegen.

Nutzer eines bestimmten Herstellers meldeten häufige Abstürze. Über Crash-Reports habe ich das Problem auf eine plattformspezifische Eigenheit eingegrenzt. Ich habe einen gezielten Fix entwickelt und auf dem betroffenen Gerätetyp getestet. Nach dem Update verschwanden die Abstürze.

Ein Release wurde wegen einer Richtlinienverletzung abgelehnt. Ich habe die Begründung des Stores genau gelesen und die beanstandete Stelle angepasst. Anschließend habe ich die App mit einer klaren Erklärung erneut eingereicht. Die nächste Version wurde ohne Probleme freigegeben.

Eine App fühlte sich beim Scrollen langer Listen träge an. Ich habe mit dem Profiler die Ursache in teuren Operationen auf dem Hauptthread gefunden. Ich habe diese ausgelagert und die Listendarstellung optimiert. Das Scrollen lief danach spürbar flüssiger.

Für ein neues Projekt stand die Wahl zwischen nativer und plattformübergreifender Entwicklung an. Ich habe Anforderungen, Budget und Teamkenntnisse abgewogen und mich für ein plattformübergreifendes Framework entschieden, da die App keine tiefen nativen Funktionen brauchte. So konnten wir schneller auf beiden Plattformen liefern. Die Entscheidung erwies sich als wirtschaftlich richtig.