Bester React Native Test für Recruiting: Was wirklich funktioniert

Warum Standard-JavaScript-Tests bei React Native scheitern

Viele Unternehmen stellen React Native-Ingenieure ein, indem sie JavaScript-Assessments oder Frontend-Developer-Tests verwenden. Das ist falsch. React Native teilt die Syntax mit React, aber die Constraints, Fallstricke und Design-Muster sind völlig anders.

Ein Kandidat, der einen Frontend-Coding-Test besteht, könnte bei React Native scheitern. Nicht, weil er schlecht ist, sondern weil React Native andere Trade-offs erzwingt.

Was React Native Recruiting unterschiedlich macht

Das Bridge-Problem

In React Native müssen Sie über die Grenze zwischen JavaScript und nativem Code nachdenken. Web-Entwickler tun das nie. Ein React Native-Ingenieur muss verstehen:

• Wie man native Module von JavaScript aus aufruft
• Was passiert, wenn man den Main Thread blockiert (sofortiger App-Freeze)
• Wie Layout anders funktioniert (kein CSS, anderes Box-Modell)
• Debugging über zwei Runtimes hinweg (Chrome DevTools für JS, Xcode/Android Studio für nativen Code)

Diese Lücke zwischen JavaScript und nativem Code ist der Ursprung schlechter Einstellungen.

Performance ist schwieriger

Web-Entwickler können langsam sein und kommen damit davon. React Native läuft auf Handys mit der Hälfte des Speichers eines Laptops. Performance ist wichtig:

• Das Rendering einer FlatList mit 1000 Elementen ist ohne Optimierung langsam
• Image-Caching ist entscheidend
• Die Bundle-Größe beeinflusst die Startup-Zeit
• Bridge-Serialisierung ist teuer (zu viele Native Calls = Latenz)

Ein brillanter Web-Entwickler, der nie über Performance nachgedacht hat, wird langsames React Native schreiben.

Testen ist anders

Web: Tests mit jsdom, Jest, React Testing Library. React Native: Plattformspezifisches Testen ist schwieriger. Viele React Native-Ingenieure testen kaum. Ein Assessment, das Testing-Fähigkeit nicht testet, verpasst ein wichtiges Signal.

Die ideale React Native-Assessment-Struktur

Phase 1: Screening (30 Minuten live)

Geben Sie ihnen eine halb fertige App mit einem spezifischen Bug. Beispiel:

"Diese App zeigt eine paginierte Benutzerliste von einer API. Wenn Sie nach unten scrollen, ruft sie die nächste Seite ab. Aber die Liste ruckelt (verliert Frames) beim Laden. Finden Sie den Engpass und erklären Sie, wie man ihn beheben würde."

Was das testet

• Können sie über React Native Performance nachdenken?
• Kennen sie FlatList, keyExtractor und Optimierung?
• Verstehen sie die Bridge und warum nativer Code wichtig ist?
• Können sie das Problem diagnostizieren, ohne den Code auszuführen?

Ein Web-Entwickler könnte Memoization vorschlagen. Ein React Native-Ingenieur weiß, dass FlatList-Optimierung die echte Antwort ist.

Phase 2: Take-Home (90 Minuten)

"Bauen Sie eine einfache Notiz-App. Benutzer können Notizen erstellen, bearbeiten und löschen. Notizen werden im Gerätespeicher gespeichert. Anforderungen:

• Verwenden Sie AsyncStorage für die Persistierung
• Zeigen Sie einen Loading-Status an, während Notizen geladen werden
• Behandeln Sie den Fall, dass der Speicher voll ist
• Navigation zwischen Listen- und Detail-Screens"

Was das testet

• Können sie ein vollständiges Feature bauen?
• Denken sie über Persistierung nach?
• Behandeln sie Edge Cases (voller Speicher, beschädigte Daten)?
• Können sie React Navigation effektiv nutzen?
• Ist der Code organisiert und testbar?

Bewertungsrichtlinie:

• Funktioniert es? (50%)
• Werden die Anforderungen erfüllt? (30%)
• Ist es wartbar? (20%)

Erwarten Sie nicht Perfektion. Erwarten Sie funktionierenden, durchdachten Code.

Phase 3: Walk-Through (30 Minuten)

Fragen Sie:

• "Gehen Sie mich durch, wie die Notiz gespeichert wird. Wie verläuft der Flow von der Benutzereingabe zum Speicher?"
• "Was passiert, wenn der Benutzer die App schließt, während eine Notiz gespeichert wird?"
• "Wie würden Sie das testen? Was würden Sie testen?"
• "Wenn wir Notizen in die Cloud synchronisieren müssten, was würde sich ändern?"

Das zeigt:

• Verstehen sie ihren eigenen Code oder haben sie ihn kopiert?
• Haben sie über Fehlerszenarios nachgedacht?
• Können sie über Architektur-Trade-offs nachdenken?

Das Bridge-Problem im Detail

Das ist der wichtigste Einstellungsfilter. Stellen Sie diese Frage im Walk-Through:

"Sie müssen eine große Datei auf dem Gerät speichern. Sie schreiben ein natives Modul (Objective-C oder Kotlin), das dies effizient erledigt. Ihr JavaScript-Code ruft dieses Modul auf. Gehen Sie mich durch, wie Sie das strukturieren würden. Was passiert, wenn die Datei zu groß ist? Wie behandeln Sie den Fortschritt?"

Die Antwort zeigt, ob sie verstehen:

• Native Module-Struktur
• Bridge-Serialisierungsgrenzen
• Async-Muster über zwei Runtimes hinweg
• Fehlerbehandlung in sprachübergreifendem Code

Ein Web-Entwickler denkt nicht über das nach. Ein React Native-Ingenieur tut es.

Testing-Disziplin

React Native-Ingenieure, die nicht testen können, sind ein Einstellungsrisiko. Sie schreiben Code, der schwer zu überarbeiten ist. Fügen Sie dem Assessment folgendes hinzu:

"Wie würden Sie einen Test für die Note-Saving-Logik schreiben? Was würden Sie testen? Was ist schwer zu testen?"

Gute Antwort: Tests würden überprüfen, dass AsyncStorage aufgerufen wird, dass Fehler behandelt werden, dass die UI aktualisiert wird. Schwieriger Teil: das tatsächliche Gerätespeicherverhalten testen.

Schwache Antwort: "Jest Tests? Ich mache einfach überall Mocks und überprüfe, dass Funktionen aufgerufen werden."

Rote Flaggen bei React Native-Assessments

Zu viel nativer Code

Wenn das Assessment erfordert, Kotlin oder Swift zu schreiben, testen Sie Platform-Expertise, nicht React Native Engineering. React Native-Ingenieure sollten native Module verwenden können, nicht unbedingt schreiben.

Zu viele Web-ähnliche Funktionen

"Bauen Sie ein vollständiges Authentifizierungssystem mit OAuth" testet nicht React Native-Fähigkeiten. Es testet, ob sie OAuth schon mal gemacht haben.

Fehlende Edge Cases

Ein Assessment, das Offline-Support, Datenpersistierung oder Berechtigungsbehandlung ignoriert, ist unvollständig.

Keine Performance-Constraints

"Bauen Sie eine App" ohne Performance-Überlegung ist zu einfach.

Lösungen von Kandidaten vergleichen

Zwei Lösungen könnten beide funktionieren. Wie unterscheiden Sie sie?

Kandidat A:

• Verwendet FlatList mit keyExtractor
• AsyncStorage in einen Service Layer verpackt
• Behandelt Fehler (Speicher voll, Berechtigung verweigert)
• Keine Tests geschrieben
• Code ist organisiert, aber defensiv

Kandidat B:

• Verwendet FlatList korrekt
• AsyncStorage mit einem Wrapper, der JSON-Serialisierung handhabt
• Behandelt Fehler und Edge Cases
• Enthält Tests (Jest + Mock AsyncStorage)
• Code ist sauber, klein und testbar

Kandidat B ist besser. Nicht weil die App funktioniert (beide funktionieren), sondern weil er über Wartbarkeit und Testen nachgedacht hat.

React Native mit React-Web-Hintergrund bewerten

Wenn der Kandidat einen starken React-Hintergrund, aber keine React Native-Erfahrung hat, passen Sie die Erwartungen an:

• Syntax und Component-Denken übertragen sich sofort
• State-Management-Muster (Redux, Zustand) übertragen sich
• Testing-Muster (Jest, Mocking) übertragen sich größtenteils

Aber sie werden kämpfen mit:

• Navigation (React Router ist anders als React Navigation)
• Performance-Optimierung
• Native Module-Integration
• Denken in Begriffen von Geräte-Memory-Constraints

Das Assessment sollte immer noch den gesamten Stack testen, aber Sie können gentler bei der Lernkurve sein und sich auf Core-Reasoning-Fähigkeiten konzentrieren, die sich übertragen werden.

Das Assessment implementieren

Wenn Sie mobile Entwickler bewerten im großen Maßstab, beachten Sie, dass React Native andere Tools und Trade-offs hat als natives iOS oder Android. Vermischen Sie die Assessments nicht. React Native-Ingenieure brauchen ihre eigene Pipeline.

Die drei Phasen (Live Screen, Take-Home, Walk-Through) brauchen etwa 2,5 Stunden Kandidatenzeit und 1,5 Stunden Interviewer-Zeit. Das ist angemessen für eine Mid-Level-Rolle.

Für Senior React Native-Ingenieure fügen Sie eine 30-Minuten-Architektur-Diskussion hinzu: "Sie bauen eine App, die Daten von einer API abruft, sie lokal zwischenspeichert und synchronisiert, wenn offline. Wie strukturieren Sie das? Welche Bibliotheken würden Sie verwenden?"

Häufige Fehler, die Sie vermeiden sollten

• Testen Sie nicht Web-Frameworks (React DOM, Next.js, usw.)
• Fordern Sie nicht Wissen über eine spezifische State-Management-Bibliothek
• Machen Sie das Assessment nicht zu einer Frage von CSS oder Styling
• Nehmen Sie nicht an, dass sie jede Platform benutzt haben (Android, iOS, Web)

Konzentrieren Sie sich stattdessen auf:

• React-Grundlagen
• JavaScript-Grundlagen
• React Native-spezifische Muster (FlatList, AsyncStorage, Navigation, Bridge)
• Geräte-Constraints und Performance-Denken

Nutzen Sie dieses Framework, um Test-Ergebnisse fair und konsistent über Kandidaten hinweg zu interpretieren.