Il miglior test React Native per la selezione: cosa funziona davvero

Perché i test JavaScript standard falliscono per React Native

Molte aziende assumono engineer React Native usando valutazioni JavaScript o test per sviluppatori frontend. È sbagliato. React Native condivide la sintassi con React, ma vincoli, trabocchetti e pattern di design sono completamente diversi.

Una candidata che supera un test di coding frontend potrebbe fallire su React Native. Non perché è scarsa, ma perché RN impone trade-off diversi.

Cosa rende diversa l'assunzione RN

Il problema del bridge

In React Native, devi pensare al confine tra JavaScript e codice nativo. Le sviluppatrici web non lo fanno mai. Un'engineer RN deve capire:

• Come chiamare moduli nativi da JavaScript
• Cosa succede quando blocchi il main thread (freeze istantaneo dell'app)
• Come funziona il layout diversamente (niente CSS, modello box differente)
• Debugging su due runtime (Chrome DevTools per JS, Xcode/Android Studio per nativo)

Questa lacuna tra JavaScript e nativo è da dove vengono i cattivi assunti.

La performance è più dura

Le sviluppatrici web possono essere lente e cavarsela. RN gira su smartphone con metà della memoria di un laptop. La performance conta:

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

Una brillante sviluppatrice web che non ha mai pensato alla performance scriverà RN lento.

Il testing è diverso

Web: testa con jsdom, Jest, React Testing Library. RN: il testing platform-specific è più difficile. Molti engineer RN testano poco. Una valutazione che non testa l'attitudine al testing perde segnale.

La struttura ideale di valutazione RN

Fase 1: screening (30 minuti live)

Dalle un'app costruita a metà con un bug specifico. Esempio:

«Questa app mostra una lista paginata di utenti da un'API. Quando scrolli in fondo, prende la pagina successiva. Ma la lista balbetta (scarta frame) durante il caricamento. Trova il collo di bottiglia e spiega come lo risolveresti.»

Cosa testa

• Sa ragionare sulla performance di RN?
• Conosce FlatList, keyExtractor e l'ottimizzazione?
• Capisce il bridge?
• Sa diagnosticare senza eseguire il codice?

Una sviluppatrice web potrebbe suggerire memoization. Un'engineer RN sa che la vera risposta è l'ottimizzazione di FlatList.

Fase 2: take-home (90 minuti)

«Costruisci una semplice app per le note. Le utenti possono creare, modificare ed eliminare note. Le note persistono sullo storage del device. Requisiti:

• Usa AsyncStorage per la persistenza
• Mostra uno stato di caricamento mentre le note vengono caricate
• Gestisci il caso in cui lo storage è pieno
• Navigazione tra la lista e le schermate di dettaglio»

Cosa testa

• Sa costruire una feature completa?
• Pensa alla persistenza?
• Gestisce i casi limite (storage pieno, dati corrotti)?
• Sa usare React Navigation efficacemente?
• Il codice è organizzato e testabile?

Rubrica:

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

Non aspettarti perfezione. Aspettati codice funzionante e ponderato.

Fase 3: walk-through (30 minuti)

Chiedi:

• «Spiegami come la nota viene salvata. Qual è il flusso dall'input dell'utente allo storage?»
• «Cosa succede se l'utente chiude l'app mentre una nota viene salvata?»
• «Come lo testeresti? Cosa testeresti?»
• «Se dovessimo sincronizzare le note nel cloud, cosa cambieresti?»

Questo rivela:

• Capisce il proprio codice o l'ha copiato?
• Ha pensato ai modi di guasto?
• Sa ragionare sui trade-off architetturali?

Il problema del bridge in profondità

Questo è il filtro più importante. Chiedi nel walk-through:

«Devi salvare un file grande sul device. Scrivi un modulo nativo (Objective-C o Kotlin) che lo fa efficientemente. Il tuo codice JavaScript chiama questo modulo. Spiegami come lo strutturi. Cosa succede se il file è troppo grande? Come gestisci il progresso?»

La risposta rivela se capisce:

• Struttura dei moduli nativi
• Limiti di serializzazione del bridge
• Pattern async su due runtime
• Gestione errori in codice cross-language

Una sviluppatrice web non ci pensa. Un'engineer RN sì.

Disciplina di testing

Gli engineer RN che non sanno testare sono un rischio di assunzione. Scrivono codice difficile da rifattorizzare. Aggiungi questo all'assessment:

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

Buona risposta: i test verificherebbero che AsyncStorage venga chiamato, che gli errori siano gestiti, che la UI si aggiorni. Parte difficile: testare il comportamento effettivo dello storage del device.

Risposta debole: «Test Jest? Faccio mock di tutto e controllo che le funzioni vengano chiamate.»

Bandiere rosse nelle valutazioni RN

Troppo codice nativo

Se la valutazione richiede di scrivere Kotlin o Swift, stai testando expertise di piattaforma, non engineering RN. Gli engineer RN dovrebbero saper usare moduli nativi, non necessariamente scriverli.

Troppe feature web

«Costruisci un sistema di autenticazione completo con OAuth» non testa skill RN. Testa se hanno già fatto OAuth.

Casi limite mancanti

Una valutazione che ignora il supporto offline, la persistenza dei dati o la gestione dei permessi è incompleta.

Niente vincoli di performance

«Fai un'app» senza considerazione di performance è troppo facile.

Confronto delle soluzioni

Due soluzioni potrebbero entrambe funzionare. Come distingui?

Candidata A:

• Usa FlatList con keyExtractor
• AsyncStorage avvolto in un service layer
• Gestisce gli errori (storage pieno, permesso negato)
• Nessun test scritto
• Codice organizzato ma difensivo

Candidata B:

• Usa FlatList correttamente
• AsyncStorage con un wrapper che gestisce la serializzazione JSON
• Gestisce errori e casi limite
• Include test (Jest + mock AsyncStorage)
• Codice pulito, piccolo e testabile

La Candidata B è migliore. Non perché l'app funziona (entrambe funzionano), ma perché ha pensato a manutenibilità e testing.

Valutare RN con background React web

Se la candidata ha un forte background React ma nessuna esperienza React Native, regola le aspettative:

• Sintassi e pensiero a componenti si trasferiscono immediatamente
• I pattern di gestione dello stato (Redux, Zustand) si trasferiscono
• I pattern di testing (Jest, mocking) si trasferiscono in gran parte

Ma faticheranno con:

• Navigation (React Router è diverso da React Navigation)
• Tuning della performance
• Integrazione di moduli nativi
• Pensare in termini di vincoli di memoria del device

La valutazione dovrebbe comunque testare lo stack completo, ma puoi essere più morbida sulla curva di apprendimento e concentrarti sulle skill di ragionamento di base che si trasferiranno.

Implementare la valutazione

Se valuti sviluppatrici mobile su scala, considera che React Native ha strumenti e trade-off diversi rispetto a iOS o Android nativo. Non mescolare le valutazioni. Gli engineer RN hanno bisogno della propria pipeline.

Le tre fasi (screen live, take-home, walk-through) richiedono circa 2,5 ore di tempo della candidata e 1,5 ore di tempo dell'intervistatrice. È appropriato per un ruolo mid-level.

Per engineer RN senior, aggiungi una discussione di architettura di 30 minuti: «Stai costruendo un'app che recupera dati da un'API, li mette in cache locale e si sincronizza quando offline. Come strutturi tutto questo? Quali librerie useresti?»

Errori comuni da evitare

• Non testare framework web (React DOM, Next.js, ecc.)
• Non richiedere conoscenza di una specifica libreria di gestione dello stato
• Non fare la valutazione su CSS o styling
• Non presumere 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 device e pensiero di performance

Usa questo framework per interpretare i risultati del test in modo equo e coerente tra le candidate.