Beste React Native-test voor werving: wat echt werkt

Waarom standaard JavaScript-tests falen voor React Native

Veel bedrijven React Native-engineers aannemen met behulp van JavaScript-assessments of frontend-developer-tests. Dit is fout. React Native deelt de syntaxis met React, maar de beperkingen, valkuilen en ontwerppatronen zijn volledig anders.

Een kandidaat die een frontend-coderingstest haalt, kan bij React Native falen. Niet omdat ze slecht zijn, maar omdat React Native andere compromissen afdwingt.

Wat maakt werving voor React Native anders

Het bridge-probleem

Bij React Native moet je nadenken over de grens tussen JavaScript en native code. Webontwikkelaars doen dit nooit. Een React Native-engineer moet begrijpen:

• Hoe je native modules vanuit JavaScript aanroept
• Wat er gebeurt als je de main thread blokkeert (direct app freeze)
• Hoe layout anders werkt (geen CSS, ander boxmodel)
• Debuggen over twee runtimes (Chrome DevTools voor JS, Xcode/Android Studio voor native)

Deze kloof tussen JavaScript en native is waar slechte aannames vandaan komen.

Prestaties zijn moeilijker

Webontwikkelaars kunnen traag zijn en er mee wegkomen. React Native draait op telefoons met de helft van het geheugen van een laptop. Prestaties zijn van belang:

• Een FlatList met 1000 items renderen is traag zonder optimalisatie
• Image caching is essentieel
• Bundle size beïnvloedt opstarttijd
• Bridge serialisatie is kostbaar (teveel native calls = latency)

Een briljante webontwikkelaar die nooit over prestaties heeft nagedacht, schrijft trage React Native-code.

Testen is anders

Web: testen met jsdom, Jest, React Testing Library. React Native: platform-specifiek testen is moeilijker. Veel React Native-engineers testen amper. Een assessment dat niet test of iemand kan testen, mist signalen.

De ideale React Native-assessmentstructuur

Fase 1: Screening (30 minuten live)

Geef hen een half-afgebouwde app met een specifieke bug. Voorbeeld:

"Deze app toont een gepagineerde lijst met gebruikers van een API. Wanneer je naar de onderkant scrollt, haalt hij de volgende pagina op. Maar de lijst stottert (frames vallen weg) bij het laden. Vind het knelpunt en leg uit hoe je dit kunt oplossen."

Wat dit test

• Kunnen ze redeneren over React Native-prestaties?
• Kennen ze FlatList, keyExtractor en optimalisatie?
• Begrijpen ze de bridge en waarom native code er toe doet?
• Kunnen ze diagnosticeren zonder de code uit te voeren?

Een webontwikkelaar stelt misschien memoization voor. Een React Native-engineer weet dat FlatList-optimalisatie het echte antwoord is.

Fase 2: Take-home (90 minuten)

"Bouw een eenvoudige notities-app. Gebruikers kunnen notities maken, bewerken en verwijderen. Notities blijven op het apparaat opgeslagen. Vereisten:

• Gebruik AsyncStorage voor persistentie
• Toon een laadtoestand terwijl notities worden geladen
• Verwerk het geval waarin opslag vol is
• Navigatie tussen de lijstweergave en detailweergave"

Wat dit test

• Kunnen ze een compleet feature bouwen?
• Denken ze aan persistentie?
• Verwerken ze randgevallen (opslag vol, beschadigde gegevens)?
• Kunnen ze React Navigation effectief gebruiken?
• Is de code georganiseerd en testbaar?

Beoordelingsrubric:

• Werkt het? (50%)
• Zijn de vereisten vervuld? (30%)
• Is het onderhoudbaar? (20%)

Verwacht niet naar perfectie. Verwacht werkende, doordachte code.

Fase 3: Doorloop (30 minuten)

Vraag:

• "Loop me door hoe de notitie wordt opgeslagen. Wat is de stroom van gebruikersinvoer naar opslag?"
• "Wat gebeurt er als de gebruiker de app sluit terwijl een notitie wordt opgeslagen?"
• "Hoe zou je dit testen? Wat zou je testen?"
• "Als we notities naar de cloud moesten synchroniseren, wat zou je veranderen?"

Dit onthult:

• Begrijpen ze hun eigen code of hebben ze het gekopieerd?
• Hebben ze over foutmodi nagedacht?
• Kunnen ze redeneren over architectuurcompromissen?

Het bridge-probleem in detail

Dit is het belangrijkste wervingsfilter. Stel deze vraag in de doorloop:

"Je moet een groot bestand op het apparaat opslaan. Je schrijft een native module (Objective-C of Kotlin) die dit efficiënt doet. Je JavaScript-code roept deze module aan. Loop me door hoe je dit zou structureren. Wat gebeurt er als het bestand te groot is? Hoe verwerk je voortgang?"

Het antwoord onthult of ze begrijpen:

• Native module structuur
• Bridge serialisatielimieten
• Async-patronen over twee runtimes
• Foutafhandeling in cross-language code

Een webontwikkelaar denkt hier niet over na. Een React Native-engineer wel.

Testdiscipline

React Native-engineers die niet kunnen testen, zijn een wervingsrisico. Ze schrijven code die moeilijk is om te refactoriseren. Voeg dit toe aan de assessment:

"Hoe zou je een test schrijven voor de notitie-opslaglogica? Wat zou je testen? Wat is moeilijk te testen?"

Goed antwoord: Tests zouden verifiëren dat AsyncStorage wordt aangeroepen, dat fouten worden afgehandeld, dat de UI wordt bijgewerkt. Moeilijk deel: testen van het werkelijke apparaatopslaggedrag.

Zwak antwoord: "Jest tests? Ik mock alles en controleer of functies worden aangeroepen."

Rode vlaggen in React Native-assessments

Te veel native code

Als de assessment Kotlin of Swift schrijven vereist, test je platform-expertise, niet React Native-engineering. React Native-engineers moeten native modules kunnen gebruiken, maar hoeven ze niet per se zelf te schrijven.

Te veel webachtige features

"Bouw een volledig authenticatiesysteem met OAuth" test niet React Native-vaardigheden. Het test of ze OAuth eerder hebben gedaan.

Ontbrekende randgevallen

Een assessment die offline ondersteuning, datapersistentie of machtigingsafhandeling negeert, is onvolledig.

Geen prestatiebeperkingen

"Maak een app" zonder prestatieoverweging is te gemakkelijk.

Oplossingen van kandidaten vergelijken

Twee oplossingen zouden beide kunnen werken. Hoe onderscheid je ze?

Kandidaat A:

• Gebruikt FlatList met keyExtractor
• AsyncStorage omwikkeld in een servicelaag
• Verwerkt fouten (opslag vol, toestemming geweigerd)
• Geen tests geschreven
• Code is georganiseerd maar defensief

Kandidaat B:

• Gebruikt FlatList correct
• AsyncStorage met een wrapper die JSON-serialisatie verwerkt
• Verwerkt fouten en randgevallen
• Bevat tests (Jest + mock AsyncStorage)
• Code is schoon, klein en testbaar

Kandidaat B is beter. Niet omdat de app werkt (beide werken), maar omdat ze hebben nagedacht over onderhoudbaarheid en testen.

React Native beoordelen met React web-achtergrond

Als de kandidaat sterke React-achtergrond maar geen React Native-ervaring heeft, pas verwachtingen aan:

• Syntaxis en componentdenken dragen onmiddellijk over
• State management patronen (Redux, Zustand) dragen over
• Testpatronen (Jest, mocking) dragen grotendeels over

Maar ze zullen worstelen met:

• Navigatie (React Router verschilt van React Navigation)
• Prestatieafstemming
• Native module-integratie
• Denken in termen van geheugenbeperking van apparaten

De assessment moet nog steeds de volledige stack testen, maar je kunt milder zijn voor de leercurve en je concentreren op kerndenkvaardigheidswaarden die zullen overhevelen.

De assessment implementeren

Als je mobiele ontwikkelaars beoordeelt op schaal, houd er rekening mee dat React Native andere tools en compromissen heeft dan native iOS of Android. Meng de assessments niet. React Native-engineers hebben hun eigen pipeline nodig.

De drie fasen (live screening, take-home, doorloop) nemen ongeveer 2,5 uur kandidaattijd en 1,5 uur interviewer-tijd in beslag. Dit is geschikt voor een mid-level rol.

Voor senior React Native-engineers voeg je een 30-minuten architectuurdiscussie toe: "Je bouwt een app die gegevens van een API ophaalt, deze lokaal cacht en synchroniseert wanneer offline. Hoe structureer je dit? Welke bibliotheken zou je gebruiken?"

Veelgemaakte fouten om te vermijden

• Test geen webframeworks (React DOM, Next.js, enz.)
• Vereisen geen kennis van een specifieke state management-bibliotheek
• Maak de assessment niet over CSS of styling
• Veronderstel niet dat ze elk platform hebben gebruikt (Android, iOS, Web)

Concentreer je op:

• React-basisprincipes
• JavaScript-basisprincipes
• React Native-specifieke patronen (FlatList, AsyncStorage, Navigation, Bridge)
• Apparaatbeperkingen en prestatiedenken

Gebruik dit framework om testresultaten eerlijk te interpreteren en consistent over kandidaten heen.