Cel mai bun test React Native pentru angajare: ce funcționează cu adevărat

De ce eșuează testele standard JavaScript pentru React Native

Multe companii angajează ingineri React Native folosind evaluări JavaScript sau teste de frontend. E greșit. React Native împărtășește sintaxa cu React, dar constrângerile, capcanele și tiparele de design sunt complet diferite.

Un candidat care trece un test de coding frontend ar putea eșua la React Native. Nu pentru că e slab, ci pentru că RN forțează compromisuri diferite.

Ce face diferită angajarea pentru RN

Problema bridge-ului

În React Native, trebuie să te gândești la granița dintre JavaScript și codul nativ. Dezvoltatorii web nu o fac niciodată. Un inginer RN trebuie să înțeleagă:

• Cum se apelează module native din JavaScript
• Ce se întâmplă când blochezi thread-ul principal (înghețare instantă a aplicației)
• Cum funcționează layout-ul diferit (fără CSS, alt model de cutie)
• Depanarea pe două runtime-uri (Chrome DevTools pentru JS, Xcode/Android Studio pentru nativ)

Acest decalaj între JavaScript și nativ e de unde vin angajările proaste.

Performanța e mai grea

Dezvoltatorii web pot fi lenți și să scape cu asta. RN rulează pe telefoane cu jumătate din memoria unui laptop. Performanța contează:

• Renderizarea unei flat list de 1000 de itemi e lentă fără optimizare
• Cache-ul de imagini e critic
• Mărimea bundle-ului afectează startup-ul
• Serializarea bridge-ului e costisitoare (prea multe apeluri native = latență)

Un dezvoltator web strălucitor care n-a gândit niciodată la performanță va scrie RN lent.

Testarea e diferită

Web: jsdom, Jest, RTL. RN: testarea specifică platformei e mai grea. Mulți ingineri RN testează puțin. O evaluare care nu testează aptitudinea de testare ratează semnal.

Structura ideală de evaluare RN

Faza 1: screening (30 de minute live)

Dă-le o aplicație construită pe jumătate cu un bug specific. Exemplu:

„Această aplicație afișează o listă paginată de utilizatori dintr-un API. Când derulezi în jos, încarcă pagina următoare. Dar lista se bâlbâie (pierde frame-uri) la încărcare. Găsește blocajul și explică cum l-ai repara."

Ce testează

• Poate raționa despre performanța RN?
• Știe despre FlatList, keyExtractor și optimizare?
• Înțelege bridge-ul?
• Poate diagnostica fără să ruleze codul?

Un dezvoltator web ar putea sugera memoization. Un inginer RN știe că răspunsul real e optimizarea FlatList.

Faza 2: take-home (90 de minute)

„Construiește o aplicație simplă de notițe. Utilizatorii pot crea, edita și șterge notițe. Notițele persistă pe stocarea dispozitivului. Cerințe:

• Folosește AsyncStorage pentru persistență
• Arată o stare de încărcare
• Tratează cazul când stocarea e plină
• Navigare între lista și ecranul de detaliu"

Ce testează

• Poate construi o funcționalitate completă?
• Se gândește la persistență?
• Gestionează cazurile-limită (stocare plină, date corupte)?
• Folosește React Navigation eficient?
• E codul organizat și testabil?

Rubrica:

• Rulează? (50 %)
• Cerințele sunt îndeplinite? (30 %)
• E mentenabil? (20 %)

Nu te aștepta la perfecțiune. Așteaptă cod funcțional și gândit.

Faza 3: walk-through (30 de minute)

Întreabă:

• „Spune-mi cum se salvează notița. Care e fluxul de la input la stocare?"
• „Ce se întâmplă dacă utilizatorul închide aplicația în timp ce o notiță se salvează?"
• „Cum ai testa asta? Ce ai testa?"
• „Dacă ar trebui să sincronizăm notițele în cloud, ce ai schimba?"

Asta dezvăluie:

• Își înțelege propriul cod sau l-a copiat?
• S-a gândit la moduri de eșec?
• Poate raționa despre compromisuri arhitecturale?

Problema bridge-ului în profunzime

E cel mai important filtru. Întreabă în walk-through:

„Trebuie să salvezi un fișier mare pe dispozitiv. Scrii un modul nativ (Objective-C sau Kotlin) care face asta eficient. Codul tău JavaScript apelează acest modul. Spune-mi cum ai structura asta. Ce se întâmplă dacă fișierul e prea mare? Cum gestionezi progresul?"

Răspunsul dezvăluie dacă înțelege:

• Structura modulelor native
• Limitele de serializare ale bridge-ului
• Tipare async între două runtime-uri
• Tratarea erorilor în cod cross-language

Un dezvoltator web nu se gândește la asta. Un inginer RN da.

Disciplina de testare

Inginerii RN care nu pot testa sunt risc de angajare. Scriu cod greu de refactorat. Adaugă asta la evaluare:

„Cum ai scrie un test pentru logica de salvare a notiței? Ce ai testa? Ce e dificil de testat?"

Răspuns bun: testele ar verifica dacă AsyncStorage e apelat, dacă erorile sunt tratate, dacă UI-ul se actualizează. Partea grea: testarea comportamentului real al stocării dispozitivului.

Răspuns slab: „Teste Jest? Mochez tot și verific că funcțiile sunt apelate."

Semne de alarmă în evaluările RN

Prea mult cod nativ

Dacă evaluarea cere scrierea de Kotlin sau Swift, testezi expertiza de platformă, nu inginerie RN. Inginerii RN ar trebui să poată să folosească module native, nu neapărat să le scrie.

Prea multe trăsături de tip web

„Construiește un sistem complet de autentificare cu OAuth" nu testează skill-uri RN. Testează dacă au făcut OAuth înainte.

Cazuri-limită lipsă

O evaluare care ignoră suportul offline, persistența datelor sau gestionarea permisiunilor e incompletă.

Fără constrângeri de performanță

„Fă o aplicație" fără considerare pentru performanță e prea ușor.

Compararea soluțiilor candidaților

Două soluții pot funcționa amândouă. Cum distingi?

Candidatul A:

• Folosește FlatList cu keyExtractor
• AsyncStorage învelit într-un strat de service
• Gestionează erori (stocare plină, permisiune refuzată)
• Niciun test scris
• Codul e organizat, dar defensiv

Candidatul B:

• Folosește FlatList corect
• AsyncStorage cu un wrapper care gestionează serializarea JSON
• Gestionează erori și cazuri-limită
• Include teste (Jest + AsyncStorage mockat)
• Codul e curat, mic și testabil

Candidatul B e mai bun. Nu pentru că aplicația funcționează (ambele funcționează), ci pentru că s-a gândit la mentenabilitate și testare.

Evaluarea RN cu background React web

Dacă candidatul are background React puternic dar fără experiență RN, ajustează așteptările:

• Sintaxa și gândirea de componente se transferă imediat
• Tiparele de management de stare (Redux, Zustand) se transferă
• Tiparele de testare (Jest, mocking) în mare parte se transferă

Dar se vor chinui cu:

• Navigarea (React Router e diferit de React Navigation)
• Tunarea performanței
• Integrarea modulelor native
• Gândirea în termeni de constrângeri de memorie ale dispozitivului

Evaluarea ar trebui totuși să testeze tot stack-ul, dar poți fi mai îngăduitor cu curba de învățare și să te concentrezi pe abilitățile de raționament de bază.

Implementarea evaluării

Dacă evaluezi dezvoltatori mobili la scară, ține cont că React Native are unelte și compromisuri diferite față de iOS sau Android nativ. Nu amesteca evaluările. Inginerii RN au nevoie de propriul pipeline.

Cele trei faze (screening live, take-home, walk-through) iau cam 2,5 ore din timpul candidatului și 1,5 ore din timpul intervievatorului. E potrivit pentru un rol mid-level.

Pentru ingineri RN seniori, adaugă o discuție de arhitectură de 30 de minute: „Construiești o aplicație care aduce date dintr-un API, le pune în cache local și le sincronizează când e offline. Cum structurezi asta? Ce librării ai folosi?"

Greșeli comune de evitat

• Nu testa framework-uri web (React DOM, Next.js etc.)
• Nu cere cunoașterea unei librării specifice de management de stare
• Nu face evaluarea despre CSS sau stilizare
• Nu presupune că au folosit fiecare platformă (Android, iOS, Web)

Concentrează-te pe:

• Fundamentele React
• Fundamentele JavaScript
• Tipare specifice React Native (FlatList, AsyncStorage, Navigation, Bridge)
• Constrângerile dispozitivului și gândirea de performanță

Folosește acest cadru pentru a interpreta rezultatele testului echitabil și consecvent între candidați.