Beste React Native-test voor werving: Wat werkelijk werkt

Waarom standaard JavaScript-tests falen voor React Native

Veel bedrijven huren React Native-ingenieurs in met JavaScript-beoordelingen of frontend-ontwikkelaartests. Dit is verkeerd. React Native deelt syntaxis met React maar de beperkingen, valkuilen en ontwerppatronen zijn geheel anders.

Een kandidaat die een frontend-coderingstest haalt kan falen bij React Native. Niet omdat zij slecht zijn, maar omdat React Native andere afwegingen forceert.

Wat React Native-werving anders maakt

Het brugprobleem

In React Native moet je denken over de grens tussen JavaScript en native code. Webontwikkelaars doen dat nooit. Een React Native-ingenieur moet begrijpen:

• Hoe native modules vanuit JavaScript aan te roepen
• Wat gebeurt als je de main thread blokkeert (directe app-bevriezing)
• Hoe lay-out anders werkt (geen CSS, ander box model)
• Debuggen over twee runtimes (Chrome DevTools voor JS, Xcode/Android Studio voor native)

Deze kloof tussen JavaScript en native is waar slechte werving vandaan komt.

Prestaties zijn moeilijker

Webontwikkelaars kunnen traag zijn en ermee weggaan. React Native werkt op telefoons met half het geheugen van een laptop. Prestaties tellen:

• Flat list rendering van 1000 items is traag zonder optimalisatie
• Afbeeldingscaching is kritiek
• Bundel grootte beïnvloedt opstarttijd
• Brugseralisatie is duur (te veel native oproepen = latentie)

Een briljante webontwikkelaar die nooit over prestaties heeft nagedacht zal langzaam React Native schrijven.

Testen is anders

Web: test met jsdom, Jest, React Testing Library. React Native: platform-specifiek testen is moeilijker. Veel React Native-ingenieurs testen nauwelijks. Een beoordeling die testneiging niet test mist signaal.

De ideale React Native-beoordelingsstructuur

Fase 1: Screen (30 minuten live)

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

'Deze app toont een gepagineerde lijst gebruikers vanuit een API. Wanneer je naar beneden scrollt, haalt het de volgende pagina. Maar de lijst stottert (frames vallen weg) bij laden. Vind de bottleneck en leg uit hoe je dit fix.'

Wat dit test

• Kunnen zij over React Native prestaties redeneren?
• Kennen zij FlatList, keyExtractor en optimalisatie?
• Begrijpen zij de brug en waarom native code telt?
• Kunnen zij diagnose stellen zonder de code uit te voeren?

Een webontwikkelaar zou memoization voorstellen. Een React Native-ingenieur weet dat FlatList-optimalisatie het werkelijke antwoord is.

Fase 2: Take-home (90 minuten)

'Bouw een eenvoudige notitie-app. Gebruikers kunnen notities maken, bewerken en verwijderen. Notities blijven op apparaatopslag. Vereisten:

• Gebruik AsyncStorage voor persistentie
• Toon een laadstaat terwijl notities worden geladen
• Behandel het geval waarin opslag vol is
• Navigatie tussen lijst- en detailschermen'

Wat dit test

• Kunnen zij een compleet feature bouwen?
• Denken zij aan persistentie?
• Behandelen zij grensgevallen (volle opslag, beschadigde gegevens)?
• Kunnen zij React Navigation effectief gebruiken?
• Is de code georganiseerd en testbaar?

Beoordelingsrubric:

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

Verwacht geen perfectie. Verwacht werkende, doordachte code.

Fase 3: Walk-through (30 minuten)

Vraag:

• 'Loop me door hoe de notitie wordt opgeslagen. Wat is de flow van gebruikersinvoer naar opslag?'
• 'Wat gebeurt 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 zouden synchroniseren, wat zou je veranderen?'

Dit onthult:

• Begrijpen zij hun eigen code of hebben zij het gekopieerd?
• Hebben zij over mislukkingsmodi nagedacht?
• Kunnen zij over architectuurafwegingen redeneren?

Het brugprobleem diepgaand

Dit is het meest belangrijke wervingfilter. Stel deze vraag in de walk-through:

'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 als het bestand te groot is? Hoe handle je vooruitgang?'

Het antwoord onthult of zij begrijpen:

• Native modulestructuur
• Brugseralisatielimieten
• Async-patronen over twee runtimes
• Foutafhandeling in cross-language code

Een webontwikkelaar denkt hier niet aan. Een React Native-ingenieur wel.

Testtechn

React Native-ingenieurs die niet kunnen testen zijn een wervingsrisico. Zij schrijven code die moeilijk is om uit te breiden. Voeg dit toe aan de beoordeling:

'Hoe zou je een test schrijven voor de note-save logica? Wat zou je testen? Wat is moeilijk te testen?'

Goed antwoord: Tests zouden verifiëren dat AsyncStorage wordt aangeroepen, dat fouten worden behandeld, dat de UI updates. Moeilijk deel: het werkelijke opslag op het apparaat testen.

Zwak antwoord: 'Jest tests? Ik mock alles gewoon en check of functies worden aangeroepen.'

Rode vlaggen in React Native-beoordelingen

Te veel native code

Als de beoordeling vereist dat je Kotlin of Swift schrijft, test je platform expertise, niet React Native-engineering. React Native-ingenieurs zouden native modules moeten kunnen gebruiken, niet noodzakelijk schrijven.

Te veel web-achtige features

'Bouw een volledig authenticatiesysteem met OAuth' test geen React Native-vaardigheden. Het test of zij OAuth eerder hebben gedaan.

Ontbrekende grensgevallen

Een beoordeling die offline-ondersteuning, gegevenspersistentie of permission-handling negeert is onvolledig.

Geen prestatiebeperkingen

'Maak een app' zonder prestatiebeschouwing is te gemakkelijk.

Kandidaatoplossingen vergelijken

Twee oplossingen kunnen beide werken. Hoe onderscheid je?

Kandidaat A:

• Gebruikt FlatList met keyExtractor
• AsyncStorage verpakt in een service laag
• Behandelt fouten (opslag vol, toestemming geweigerd)
• Geen tests geschreven
• Code is georganiseerd maar defensief

Kandidaat B:

• Gebruikt FlatList correct
• AsyncStorage met een wrapper die JSON-seralisatie afhandelt
• Behandelt fouten en grensgevallen
• Omvat tests (Jest + mock AsyncStorage)
• Code is schoon, klein en testbaar

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

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 overdragers onmiddellijk
• Staat management (Redux, Zustand) patronen overdragen
• Testpatronen (Jest, mocking) grotendeels overdragen

Maar zij zullen moeite hebben met:

• Navigatie (React Router verschilt van React Navigation)
• Prestatie tuning
• Native moduleintegratie
• Denken in termen van geheugen apparaatbeperkingen

De beoordeling moet nog steeds de volledige stack testen, maar je kunt milder zijn op de leercurve en focus op kernredeneervaardigheden die zullen overdragen.

De beoordeling implementeren

Als je mobiele ontwikkelaars beoordeelt op schaal, overweeg dat React Native verschillende tools en afwegingen heeft dan native iOS of Android. Mix niet de beoordelingen. React Native-ingenieurs hebben hun eigen pijplijn nodig.

De drie fasen (live screen, take-home, walk-through) nemen ongeveer 2,5 uur kandidaattijd en 1,5 uur interviewertijd in beslag. Dit is geschikt voor een mid-level rol.

Voor senior React Native-ingenieurs, voeg een 30-minuten architectuurdiscussie toe: 'Je bouwt een app die gegevens van een API haalt, cacht het lokaal, en synchroniseert offline. Hoe structureer je dit? Welke bibliotheken zou je gebruiken?'

Veelvoorkomende fouten om te voorkomen

• Test niet webframeworks (React DOM, Next.js, enz.)
• Vereis geen kennis van een specifieke state management bibliotheek
• Maak de beoordeling niet over CSS of styling
• Ga niet ervan uit dat zij elk platform hebben gebruikt (Android, iOS, Web)

Focus wel op:

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

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