Mobile Developer Test: Beispielfragen und Best Practices

Warum Beispielfragen wichtig sind

Die meisten Mobile-Developer-Bewertungen sind falsch konstruiert. Sie lehnen sich entweder zu sehr auf Trivia an (was ist die Lifecycle-Methoden-Name in Android 11?) oder sie sind so offen, dass sie unter ihrem eigenen Gewicht zusammenbrechen. Die richtigen Beispielfragen liegen in der Mitte: spezifisch genug, um bewertet zu werden, breit genug, um Urteil zu offenbaren.

Wenn du eine Mobile-Bewertung von Grund auf aufbaust, zu wissen, welche Arten von Fragen funktionieren, ist die halbe Schlacht. Hier sind die Muster, die tatsächlich Arbeitsleistung vorhersagen.

iOS-spezifische Fragen

1. View Controller Lifecycle mit Status

"Ein Login-Bildschirm wird geladen. Beim ersten Rendern ruft er die Auth-Sitzung aus dem Keychain ab. Wenn die Sitzung ungültig ist, aktualisiert er das Token vom Server. Schreib den Code für viewDidLoad und viewWillAppear, die dies ohne doppelte API-Aufrufe handhaben."

Dies testet: Verständnis des ViewController-Lifecycles, State-Management, Netzwerk und defensive Programmierung. Es ist nicht Trivia. Ein Junior schreibt es anders als ein Senior, und beide Versionen sind erlernbar.

2. Speicherleck in Delegation

"Hier ist ein View Controller, der eine starke Referenz zu einem Delegate hält. Der Delegate (ein Manager-Objekt) hält eine starke Referenz zurück zum View Controller. Schreib einen Test, der diesen Retain Cycle erkennt."

Dies geht über statisches Wissen hinaus. Es erfordert, das Problem zu verstehen, einen Test zu entwerfen und es zu beheben. Echte Arbeit.

3. SwiftUI + async-await Navigation

"Du hast einen Navigation-Stack. Wenn ein Button getippt wird, musst du Daten abrufen, einen Loading-Status anzeigen, dann zu einem Detail-Bildschirm navigieren. Schreib den Code mit async-await und @State."

Das ist aktuell. Es eliminiert Kandidaten, die nicht mitgehalten haben, und priorisiert Menschen, die moderne Concurrency-Muster verstehen.

Android-spezifische Fragen

1. Fragment Lifecycle mit gespeichertem Status

"Ein Fragment zeigt eine Liste von Elementen. Die Liste wird aus dem Netz abgerufen. Wenn der Benutzer das Gerät dreht, sollte die Liste ohne Neukauf anhalten. Schreib den Code mit ViewModel und SavedInstanceState."

Tests: Lifecycle, State-Persistenz und moderne Architektur-Muster. Nicht trivial, nicht unmöglich.

2. Dependency Injection in Tests

"Du hast ein Repository, das von einem API-Service abhängt. Schreib den Test-Setup-Code, der den Service mockt und sicherstellt, dass das Repository einen 500-Fehler richtig handhabt."

Dies offenbart, ob sie Testbarkeit zur Design-Zeit bedenken.

3. Benutzerdefinierte Berechtigungen mit Callback

"Fordere Kamera-Berechtigung zur Runtime an. Wenn verweigert, zeig einen Dialog, der erklärt, warum. Wenn gewährt, öffne die Kamera. Schreib den Code."

Praktisch, modernes Android. Nicht über das Auswendiglernen von API-Namen.

React Native (Cross-Platform)

1. Navigation State Leak

"Du hast zwei Screens in einem Navigation-Stack. Screen A ruft Daten ab, wenn es mounted. Wenn der Benutzer zu Screen B und zurück zu A navigiert, sollten die Daten wiederabgerufen werden, nicht gecacht. Schreib den Code mit React Navigation und Hooks."

Dies testet State-Lifecycle-Verständnis und eine häufige Bug-Quelle.

2. Leistung: FlatList mit Bildern

"Du hast eine FlatList, die 1000 Bild-Elemente rendert. Sie ist langsam. Schreib den Code, der das behebt (keyExtractor, getItemLayout oder Bild-Größe)."

Praktisches Debugging. Der Kandidat kennt das Problem entweder oder nicht.

3. Bridge zu Native Module

"Du musst eine native Funktion von JavaScript aufrufen. Schreib den Bridge-Code für iOS oder Android, einschließlich Fehlerbehandlung."

Dies testet, ob sie die Grenze verstehen und über sie arbeiten können.

Allgemeine Mobile Fragen (alle Plattformen)

1. API-Versionierungs-Kompromiss

"Deine API hat ein Response-Schema geändert. Alte Clients sind immer noch in der Wildnis. Schreib den Code im Mobile-Client, der beide Versionen handhabt."

Tests: Pragmatismus, defensive Programmierung und Backward-Compatibility-Denken.

2. Offline-First State Sync

"Der Benutzer bearbeitet ein Element offline. Wie stellst du diese Bearbeitung in die Warteschlange und synchronisierst sie, wenn die Verbindung zurückkommt? Schreib den Pseudocode."

Das ist Architektur-Ebene. Die Antwort offenbart Design-Reife.

3. App-Startup-Leistung

"Deine App braucht 4 Sekunden zum Starten. Was sind drei Dinge, die du überprüfen würdest und warum? Schreib den Code für eines von ihnen."

Offen genug, um Denken zu offenbaren. Spezifisch genug, um es zu erden.

Wie man diese Fragen bewertet

Bewerte nicht auf Politur. Bewerte auf:

• Funktioniert es? Führt der Code das aus, was gefragt wurde?
• Würdest du es bereitstellen? Gibt es unbehandelte Edge Cases?
• Können sie es erklären? Bei einem Durchgang, können sie ihre Entscheidungen begründen?

Für Mobile-Arbeit speziell, eine Live-Coding-Interview mit diesen Arten von Fragen offenbart mehr als nur Artefakt, weil der Kandidat die Tools und seine eigene Unsicherheit in Echtzeit navigieren muss.

Was zu vermeiden ist

Frage nicht:

• "Was ist der Unterschied zwischen Strong und Weak References?" (Trivia)
• "Implementiere eine ganze Chat-App" (zu breit, unbewertet)
• "Was macht dieses undeutliches Flag?" (bedeutungslos)

Frage stattdessen:

• Probleme mit klaren Erfolgs-Kriterien
• Probleme, die Urteil zeigen (Kompromisse, nicht nur Korrektheit)
• Probleme, die wie Arbeit aussehen

Diese Beispielfragen verankern deine Bewertung im Job. Beginne mit ihnen, füge deine eigenen Domain-spezifischen Varianten hinzu und validiere die Bewertung, sobald du live bist.

Nächste Schritte

Wenn du Mobile Developer im großen Maßstab bewertest, einen konsistenten Satz von Beispielen über dein Team verteilt, verhindert Drift. Nutze diese als Template, passe für deinen Stack an und iteriere basierend auf dem, was du von eingestellten Kandidaten lernst.