Der beste React-Native-Test für die Einstellung: was wirklich funktioniert

Warum Standard-JavaScript-Tests für React Native scheitern

Viele Firmen stellen React-Native-Engineers mit JavaScript-Bewertungen oder Frontend-Tests ein. Das ist falsch. React Native teilt Syntax mit React, aber Constraints, Stolperfallen und Designmuster sind komplett anders.

Eine Bewerberin, die einen Frontend-Coding-Test besteht, kann an React Native scheitern. Nicht weil sie schlecht ist, sondern weil RN andere Trade-offs erzwingt.

Was RN-Hiring anders macht

Das Bridge-Problem

In React Native musst du an die Grenze zwischen JavaScript und nativem Code denken. Web-Entwicklerinnen tun das nie. Eine RN-Engineerin muss verstehen:

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

Diese Lücke ist, wo schlechte Hires herkommen.

Performance ist schwerer

Web-Entwicklerinnen können langsam sein und damit durchkommen. React Native läuft auf Handys mit halb so viel RAM wie ein Laptop. Performance zählt:

• Flat-List-Rendering von 1.000 Items ist ohne Optimierung lahm
• Image-Caching ist kritisch
• Bundle-Größe beeinflusst Startup
• Bridge-Serialisierung ist teuer (zu viele native Calls = Latenz)

Eine brillante Web-Entwicklerin, die nie über Performance nachgedacht hat, schreibt langsames RN.

Testing ist anders

Web: jsdom, Jest, RTL. RN: plattformspezifisches Testing ist schwerer. Viele RN-Engineers testen kaum. Eine Bewertung, die Test-Aptitude ignoriert, verliert Signal.

Ideale RN-Bewertungsstruktur

Phase 1: Screen (30 Minuten live)

Gib ihr eine halbgebaute App mit einem konkreten Bug. Beispiel:

„Diese App zeigt eine paginierte Userliste von einer API. Beim Scrollen lädt sie die nächste Seite. Aber die Liste stottert beim Laden. Finde den Bottleneck und erkläre, wie man es fixt."

Was das prüft

• Kann sie über RN-Performance reasonen?
• Kennt sie FlatList, keyExtractor, Optimierung?
• Versteht sie den Bridge?
• Kann sie ohne Ausführung diagnostizieren?

Eine Web-Entwicklerin schlägt vielleicht Memoization vor. Eine RN-Engineerin weiß, FlatList-Optimierung ist die echte Antwort.

Phase 2: Take-home (90 Minuten)

„Bau eine einfache Notiz-App. Userinnen können Notizen erstellen, bearbeiten und löschen. Persistenz auf dem Gerät. Anforderungen:

• AsyncStorage für Persistenz
• Loading-State beim Laden
• Handhabe vollen Storage
• Navigation zwischen Liste und Detail"

Was das prüft

• Baut sie ein vollständiges Feature?
• Denkt sie an Persistenz?
• Behandelt sie Edge Cases (voller Storage, korrupte Daten)?
• Nutzt sie React Navigation effektiv?
• Ist der Code organisiert und testbar?

Bewertungsrubrik:

• Läuft es? (50 %)
• Anforderungen erfüllt? (30 %)
• Wartbar? (20 %)

Erwarte keine Perfektion. Erwarte funktionierenden, durchdachten Code.

Phase 3: Walk-through (30 Minuten)

Frage:

• „Erklär mir, wie die Notiz gespeichert wird. Flow von Eingabe bis Storage."
• „Was passiert, wenn die Userin die App schließt, während gespeichert wird?"
• „Wie würdest du das testen? Was würdest du testen?"
• „Wenn wir Notes in die Cloud syncen müssten, was würdest du ändern?"

Das zeigt:

• Versteht sie ihren eigenen Code, oder hat sie ihn kopiert?
• Hat sie an Failure-Modes gedacht?
• Kann sie über Architektur-Trade-offs reasonen?

Das Bridge-Problem im Detail

Der wichtigste Hire-Filter. Frage im Walk-through:

„Du musst eine große Datei aufs Gerät speichern. Du schreibst ein natives Modul (Objective-C oder Kotlin), das das effizient macht. Dein JS-Code ruft das Modul auf. Erklär mir, wie du das strukturierst. Was passiert, wenn die Datei zu groß ist? Wie handhabst du Progress?"

Die Antwort zeigt, ob sie versteht:

• Native-Modul-Struktur
• Bridge-Serialisierungslimits
• Async-Patterns über zwei Runtimes
• Fehlerbehandlung im Cross-Language-Code

Eine Web-Entwicklerin denkt darüber nicht nach. Eine RN-Engineerin schon.

Test-Disziplin

RN-Engineers, die nicht testen können, sind ein Hiring-Risiko. Ihr Code ist schwer zu refactorieren. Frage:

„Wie würdest du einen Test für die Notiz-Speicher-Logik schreiben? Was würdest du testen? Was ist schwer zu testen?"

Gute Antwort: Tests würden verifizieren, dass AsyncStorage aufgerufen wird, Fehler behandelt sind, UI sich updated. Schwer: echtes Geräte-Storage-Verhalten.

Schwache Antwort: „Jest-Tests? Ich mocke alles und prüfe, dass Funktionen aufgerufen werden."

Warnsignale in RN-Bewertungen

Zu viel nativer Code

Falls die Bewertung Kotlin oder Swift verlangt, prüfst du Plattformexpertise, nicht RN-Engineering. RN-Engineers sollten native Module nutzen können, nicht zwingend schreiben.

Zu viel Web-ähnliches

„Bau ein vollständiges OAuth-Auth-System" prüft keine RN-Skills. Es prüft, ob sie OAuth gemacht hat.

Fehlende Edge Cases

Eine Bewertung ohne Offline-Support, Persistenz oder Permission-Handling ist unvollständig.

Keine Performance-Constraints

„Bau eine App" ohne Performance-Überlegung ist zu einfach.

Lösungen vergleichen

Zwei Lösungen können funktionieren. Wie unterscheidest du?

Bewerberin A:

• FlatList mit keyExtractor
• AsyncStorage in Service-Layer gewrappt
• Behandelt Fehler (Storage voll, Permission denied)
• Keine Tests
• Code organisiert, aber defensiv

Bewerberin B:

• FlatList korrekt
• AsyncStorage mit Wrapper für JSON-Serialisierung
• Behandelt Fehler und Edge Cases
• Mit Tests (Jest + Mock-AsyncStorage)
• Code ist sauber, klein, testbar

B ist besser. Nicht weil die App funktioniert (beide tun das), sondern weil sie über Wartbarkeit und Tests nachgedacht hat.

RN bewerten mit React-Web-Hintergrund

Wenn die Bewerberin starkes React, aber keine RN-Erfahrung hat, passe Erwartungen an:

• Syntax und Component-Thinking übertragen sich sofort
• State-Management-Patterns übertragen sich
• Test-Patterns übertragen sich meist

Aber sie wird kämpfen mit:

• Navigation (React Router ≠ React Navigation)
• Performance-Tuning
• Native-Modul-Integration
• Denken in Geräte-Speicher-Constraints

Die Bewertung sollte den vollen Stack testen, aber sei sanfter mit der Lernkurve.

Implementierung

Wenn du Mobile-Entwicklerinnen im Maßstab bewertest, bedenke: RN hat andere Tools und Trade-offs als natives iOS oder Android. Mische Bewertungen nicht. RN-Engineers brauchen ihren eigenen Pipeline.

Drei Phasen (Live-Screen, Take-home, Walk-through) brauchen ~2,5 Stunden Bewerberinnenzeit und 1,5 Stunden Interviewerzeit. Passend für Mid-Level.

Für Senior RN: zusätzlich 30 Minuten Architekturgespräch: „Du baust eine App, die Daten von einer API holt, lokal cached und offline syncht. Wie strukturierst du das? Welche Libs?"

Häufige Fehler

• Teste keine Web-Frameworks (React DOM, Next.js)
• Verlange keine spezifische State-Management-Lib
• Mach die Bewertung nicht über CSS oder Styling
• Setze nicht voraus, dass sie alle Plattformen (Android, iOS, Web) genutzt hat

Fokussiere auf:

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

Nutze diesen Rahmen, um Testergebnisse fair zu interpretieren.