Migliore test React Native per l'assunzione: cosa funziona davvero

Perché i test JavaScript standard falliscono per React Native

Molte aziende assumono ingegneri React Native utilizzando assessment JavaScript o test per sviluppatori frontend. Questo è sbagliato. React Native condivide la sintassi con React, ma i vincoli, i tranelli e i pattern di design sono completamente diversi.

Un candidato che supera un test di codifica frontend potrebbe fallire con React Native. Non perché sia scarso, ma perché React Native impone trade-off diversi.

Cosa rende diversa l'assunzione di React Native

Il problema del bridge

In React Native, devi pensare al confine tra JavaScript e il codice nativo. Gli sviluppatori web non lo fanno mai. Un ingegnere React Native deve comprendere:

• Come chiamare moduli nativi da JavaScript
• Cosa succede quando blocchi il thread principale (blocco istantaneo dell'app)
• Come il layout funziona diversamente (senza CSS, modello di box diverso)
• Debug su due runtime (Chrome DevTools per JS, Xcode/Android Studio per il nativo)

Questo divario tra JavaScript e il codice nativo è dove provengono le assunzioni sbagliate.

Le prestazioni sono più difficili

Gli sviluppatori web possono essere lenti e farla franca. React Native gira su telefoni con metà della memoria di un laptop. Le prestazioni contano:

• Il rendering di una flat list con 1000 elementi è lento senza ottimizzazione
• Il caching delle immagini è critico
• La dimensione del bundle influisce sul tempo di avvio
• La serializzazione del bridge è costosa (troppe chiamate native = latenza)

Un brillante sviluppatore web che non ha mai pensato alle prestazioni scriverà React Native lento.

I test sono diversi

Web: test con jsdom, Jest, React Testing Library. React Native: i test specifici della piattaforma sono più difficili. Molti ingegneri React Native testano a malapena. Un assessment che non testa le capacità di test perde segnali importanti.

La struttura ideale di un assessment React Native

Fase 1: Screening (30 minuti in diretta)

Dai loro un'app semi-costruita con un bug specifico. Esempio:

"Questa app visualizza un elenco paginato di utenti da un'API. Quando scorri fino al fondo, recupera la pagina successiva. Ma l'elenco balbetta (perde fotogrammi) durante il caricamento. Trova il collo di bottiglia e spiega come risolverlo."

Cosa testa questo

• Riescono a ragionare sulle prestazioni di React Native?
• Conoscono FlatList, keyExtractor e l'ottimizzazione?
• Comprendono il bridge e perché il codice nativo conta?
• Riescono a diagnosticare senza eseguire il codice?

Uno sviluppatore web potrebbe suggerire la memoization. Un ingegnere React Native sa che l'ottimizzazione di FlatList è la vera risposta.

Fase 2: Take-home (90 minuti)

"Crea una semplice app di note. Gli utenti possono creare, modificare ed eliminare note. Le note persistono nell'archiviazione del dispositivo. Requisiti:

• Usa AsyncStorage per la persistenza
• Mostra uno stato di caricamento mentre le note vengono caricate
• Gestisci il caso in cui l'archiviazione sia piena
• Navigazione tra le schermate dell'elenco e dei dettagli"

Cosa testa questo

• Riescono a creare una funzionalità completa?
• Pensano alla persistenza?
• Gestiscono i casi limite (archiviazione piena, dati corrotti)?
• Usano efficacemente React Navigation?
• Il codice è organizzato e testabile?

Rubrica di valutazione:

• Funziona? (50%)
• I requisiti sono soddisfatti? (30%)
• È mantenibile? (20%)

Non aspettare la perfezione. Aspettati codice funzionante e ponderato.

Fase 3: Walk-through (30 minuti)

Chiedi:

• "Descrivimi come la nota viene salvata. Qual è il flusso dall'input dell'utente all'archiviazione?"
• "Cosa succede se l'utente chiude l'app mentre una nota viene salvata?"
• "Come la testeresti? Cosa testeresti?"
• "Se dovessimo sincronizzare le note nel cloud, cosa cambieresti?"

Questo rivela:

• Comprendono il loro codice o l'hanno copiato?
• Hanno pensato ai modalità di guasto?
• Riescono a ragionare sugli trade-off dell'architettura?

Il problema del bridge in profondità

Questo è il filtro di assunzione più importante. Fai questa domanda durante il walk-through:

"Devi salvare un file di grandi dimensioni sul dispositivo. Scrivi un modulo nativo (Objective-C o Kotlin) che lo fa in modo efficiente. Il tuo codice JavaScript chiama questo modulo. Descrivimi come lo struttureresti. Cosa succede se il file è troppo grande? Come gestisci i progressi?"

La risposta rivela se comprendono:

• La struttura del modulo nativo
• I limiti di serializzazione del bridge
• I pattern asincroni tra due runtime
• La gestione degli errori nel codice multilingua

Uno sviluppatore web non pensa a questo. Un ingegnere React Native sì.

Disciplina dei test

Gli ingegneri React Native che non riescono a testare sono un rischio di assunzione. Scrivono codice difficile da refactor. Aggiungi questo all'assessment:

"Come scriveresti un test per la logica di salvataggio della nota? Cosa testeresti? Cosa è difficile da testare?"

Buona risposta: I test verificherebbero che AsyncStorage viene chiamato, che gli errori vengono gestiti, che l'interfaccia utente si aggiorna. La parte difficile: testare il comportamento effettivo dell'archiviazione del dispositivo.

Risposta debole: "Jest test? Semplicemente mock tutto e controllo che le funzioni siano chiamate."

Bandiere rosse negli assessment React Native

Troppo codice nativo

Se l'assessment richiede la scrittura di Kotlin o Swift, stai testando l'expertise della piattaforma, non l'ingegneria React Native. Gli ingegneri React Native dovrebbero essere in grado di usare moduli nativi, non necessariamente scriverli.

Troppe funzionalità simili al web

"Crea un sistema di autenticazione completo con OAuth" non testa le competenze React Native. Testa se hanno fatto OAuth prima.

Mancanza di casi limite

Un assessment che ignora il supporto offline, la persistenza dei dati o la gestione delle autorizzazioni è incompleto.

Nessun vincolo di prestazione

"Crea un'app" senza considerare le prestazioni è troppo facile.

Confronto delle soluzioni dei candidati

Due soluzioni potrebbero funzionare entrambe. Come le distingui?

Candidato A:

• Usa FlatList con keyExtractor
• AsyncStorage avvolto in un livello di servizio
• Gestisce gli errori (archiviazione piena, autorizzazione negata)
• Nessun test scritto
• Il codice è organizzato ma difensivo

Candidato B:

• Usa FlatList correttamente
• AsyncStorage con un wrapper che gestisce la serializzazione JSON
• Gestisce gli errori e i casi limite
• Include test (Jest + mock AsyncStorage)
• Il codice è pulito, compatto e testabile

Il candidato B è migliore. Non perché l'app funziona (entrambe funzionano), ma perché hanno pensato alla mantenibilità e ai test.

Valutazione di React Native con background React web

Se il candidato ha un forte background React ma nessuna esperienza React Native, adatta le aspettative:

• La sintassi e il pensiero dei componenti si trasferiscono immediatamente
• I pattern di gestione dello stato (Redux, Zustand) si trasferiscono
• I pattern di test (Jest, mocking) si trasferiscono per lo più

Ma avranno difficoltà con:

• La navigazione (React Router è diverso da React Navigation)
• L'ottimizzazione delle prestazioni
• L'integrazione dei moduli nativi
• Pensare in termini di vincoli di memoria del dispositivo

L'assessment dovrebbe comunque testare lo stack completo, ma puoi essere più indulgente sulla curva di apprendimento e concentrarti sulle competenze di ragionamento di base che si trasferiscono.

Implementazione dell'assessment

Se stai valutando sviluppatori mobile su larga scala, considera che React Native ha strumenti e trade-off diversi rispetto a iOS o Android nativi. Non mescolare gli assessment. Gli ingegneri React Native hanno bisogno della loro pipeline.

Le tre fasi (screening in diretta, take-home, walk-through) richiedono circa 2,5 ore di tempo del candidato e 1,5 ore di tempo dell'intervistatore. Questo è appropriato per un ruolo di livello intermedio.

Per ingegneri React Native senior, aggiungi una discussione sull'architettura di 30 minuti: "Stai costruendo un'app che recupera dati da un'API, li memorizza nella cache localmente e sincronizza quando offline. Come la strutturi? Quali librerie useresti?"

Errori comuni da evitare

• Non testare framework web (React DOM, Next.js, ecc.)
• Non richiedere la conoscenza di una libreria di gestione dello stato specifica
• Non rendere l'assessment riguardante CSS o styling
• Non assumere che abbiano usato ogni piattaforma (Android, iOS, Web)

Concentrati su:

• Fondamenti di React
• Fondamenti di JavaScript
• Pattern specifici di React Native (FlatList, AsyncStorage, Navigation, Bridge)
• Vincoli del dispositivo e pensiero delle prestazioni

Usa questo framework per interpretare i risultati dei test in modo equo e coerente tra i candidati.