Com aprovar una prova tècnica de React Native

Què puntuen de debò els panells

Reviso entregues de proves tècniques de React Native. La majoria dels rebutjos no són un problema de codi. El candidat sabia programar. No va mostrar les coses correctes.

Aquest post és el consell que donaria a un amic abans d’entregar una prova tècnica per fer a casa. Específic, pràctic, des del costat del panell. Els petits canvis que porten una entrega de «potser» a «sí».

Vaig escriure sobre per què vaig redissenyar una prova tècnica des de la perspectiva del hiring manager en un altre post. Aquest és l’altre costat: com aprovar-ne una.

Llegeix el brief dues vegades. Després torna’l a llegir

Sembla obvi. És el descuit més comú.

Si el brief diu «construeix tres pantalles amb navegació», no en construeixis dues. Si diu «fes servir TypeScript», no facis servir JavaScript. Si diu «gestiona una llista de fins a 6 ítems», assegura’t que afegir-ne un 7è es gestioni correctament.

Els revisors verifiquen els requisits com una checklist. Cada requisit que falta es tradueix en punts perduts. Seguir una especificació és part de la feina. Si et saltes requisits en una prova tècnica amb un brief clar, què passa amb un ticket de Jira ambigu? Llegeix el brief abans de començar, torna’l a llegir a la meitat, i llegeix-lo un últim cop abans d’entregar.

L’estructura del projecte explica al panell com penses

La primera cosa que faig quan obro una entrega és mirar l’estructura de carpetes. Abans de llegir una línia de codi, la disposició ja diu alguna cosa sobre com organitzes la feina.

Estructura per tipus (screens/, components/, hooks/, services/):

src/
  components/
  hooks/
  screens/
  services/
  types/

Estructura per feature (cada feature és autocontinguda):

src/
  features/
    product-list/
    product-detail/
    favourites/
  shared/
    components/
    hooks/

Cap de les dues no és incorrecta. L’estructura per feature mostra que has pensat en com escala l’app. Si pregunto «què passa quan 5 equips treballen en aquest codebase?» i la teva estructura ja respon aquesta pregunta, vas per davant.

Red flag: tot en una carpeta plana src/ sense organització. Suggereix que el codi va començar abans de planificar l’arquitectura.

TypeScript no és opcional

Si el brief diu «TypeScript preferit», tracta-ho com a obligatori. Entregar JavaScript pur el 2026 és un downgrade automàtic al nostre scorecard.

El llistó és fer-lo servir bé:

L’únic any que perdonaré: un tipus d’una biblioteca de tercers que costaria una hora de modelar bé. Reconeix-ho en un comentari. // TODO: tipar això bé, em vaig quedar sense temps es llegeix millor que fer veure que no hi és.

Red flag: any escampat per tot el codebase sense cap reconeixement.

State management: tria’n un i fes-te’n responsable

No m’importa si fas servir Redux Toolkit, Zustand, React Context o Jotai. M’importa que ho hagis triat deliberadament i puguis explicar per què.

Si tries Redux, fes servir Redux Toolkit. No el vell patró de reducer amb switch/case. Si veig createStore en lloc de configureStore, o constants manuals d’action types en lloc de createSlice, el coneixement de Redux probablement necessita una actualització.

El que realment importa:

Fes:

• Lògica d’estat separada de la UI
• Actions, reducers i selectors en els seus propis fitxers
• Regles de negoci (com una mida màxima de llista) aplicades a la capa d’estat
• Actualitzacions predictibles

No facis:

• Lògica de negoci que viu dins dels components
• Estat escampat entre crides a useState sense cap patró clar

No facis dispatch d’un fetch cada vegada que es munta una pantalla. Si navego a una pantalla de detall, torno enrere, i torno a la mateixa pantalla de detall, no hauria de veure un spinner de càrrega una altra vegada. Un simple if (!data[id]) abans del teu dispatch(fetchDetails(id)) és suficient.

Tests: qualitat per sobre de cobertura

No necessites un 90% de cobertura. Necessites tests significatius. Tres bons tests valen més que vint snapshot tests.

El que vull veure:

El que no vull veure:

• Snapshot tests a tot arreu. Es trenquen amb cada canvi de UI i diuen poc sobre el comportament.
• Tests que ho simulen tot. Si el teu test simula la funció que està provant, està provant el mock.
• Cap test. És difícil recuperar-se d’això al walkthrough.

Per a un brief d’aquesta mida, de 5 a 10 tests enfocats que cobreixin els camins crítics (reducers, selectors, interaccions clau) és el punt que busca el nostre panell.

Gestiona els estats de càrrega, error i buit

Qualsevol pot construir el camí feliç. La pregunta és què passa quan les coses van malament.

Red flag: l’app peta amb una xarxa lenta. Sense estat de càrrega, sense gestió d’errors. El revisor obre DevTools, limita la xarxa, i l’app es trenca.

La crida a l’API importa

GraphQL vs REST. Si el brief ofereix tots dos, l’execució va primer: un client REST ben implementat supera un setup de GraphQL desordenat. Però un GraphQL ben fet puntua més alt a la nostra rúbrica, així que si et sents igual de còmode amb tots dos, és l’opció més forta. Estigues preparat per explicar el perquè en qualsevol dels dos casos.

Fes servir FlatList o FlashList per a llistes de dades. ScrollView renderitza tots els ítems de cop. Per a una llista curta i estàtica ja va bé; amb més de 100 ítems veuràs caigudes de frames, pics de memòria i, tard o d’hora, crashes. FlatList virtualitza la llista, renderitzant una finestra al voltant de la zona visible. Un ScrollView que embolcalla un .map() sobre dades d’una API suggereix una llacuna en la comprensió del model de renderitzat de RN.

Altres coses que es noten:

• Caching: no tornis a fer fetch de dades que ja tens
• Paginació: no facis fetch de 1000 ítems a la primera càrrega
• ErrorBoundary: captura errors de JavaScript i mostra un fallback en lloc d’una pantalla blanca

Els edge cases són on destaques

El camí feliç és el mínim. El que separa una entrega de nivell Software Engineer d’una de Senior és la gestió d’edge cases:

• Llista plena? Què passa quan algú intenta afegir un 7è ítem? Un toast, un botó desactivat, un modal. Qualsevol cosa excepte fallar silenciosament.
• Llista buida? Mostra un estat buit amb sentit, no una pantalla en blanc.
• Taps ràpids? Prémer «afegir» cinc cops seguits ben de pressa causa duplicats o crashes?
• Navegació enrere? Quan torno del detall a la llista, es preserva la meva posició de scroll?
• Final de la llista? La paginació s’atura netament quan no hi ha més dades?

No necessites gestionar tots aquests. Gestionar-ne alguns mostra que penses en usuaris reals, no només en complir requisits.

El README és part de la prova

Escriu un README. No una novel·la. Un document curt que cobreixi:

Aquesta última secció és la que val la pena escriure amb cura. Et permet reconèixer les dreceres que has pres sense que el revisor les descobreixi com a defectes. «Amb més temps, afegiria tests E2E amb Detox i implementaria caching adequat» converteix una feature que falta en una demostració de criteri.

El walkthrough: aquí és on es guanyen els llocs

Si la prova té una trucada de walkthrough, prepara’t. El codi t’obre la porta de la sala. El walkthrough et dona l’oferta.

Coneix el teu codi. Si dic «mostra’m on gestiones la resposta de l’API», hauries d’arribar-hi gairebé a l’instant. Dubtar genera preguntes sobre fins a quin punt coneixes realment el codi.

Explica els teus trade-offs sense esperar que t’ho preguntin. Quan mostres una secció de codi, digues «He triat aquest enfocament perquè X, però sé que el trade-off és Y». Aquesta és la resposta que busco fins i tot abans de fer la pregunta.

Sigues sincer amb les dreceres. «He fet servir Context aquí perquè era més ràpid, però en una app de producció ho mouria a Zustand un cop l’estat es tornés més complex». Resposta forta. «Crec que Context és el millor enfocament» és més feble, perquè el panell coneix els trade-offs i acabes de suggerir que tu no.

Tingues una llista de millores. Quan pregunti «què canviaries amb més temps?», la pitjor resposta és «res, n’estic content». La millor resposta és una llista prioritzada: «Primer afegiria caching, després tests E2E, després refactoritzaria a carpetes per feature».

Fes preguntes tu també. Els millors walkthroughs són converses, no presentacions. Pregunta sobre l’arquitectura de l’equip, el seu enfocament de testing, el seu procés de deploy. Mostra que tu també estàs avaluant el lloc, no només esperant aprovar.

Stretch goals: fes-los, però fes-los bé

Si el brief menciona extres opcionals, tria’n un o dos que puguis fer bé. No intentis fer-los tots de qualsevol manera. Un stretch goal ben executat val més que tres a mig fer.

Els errors que realment costen el lloc a la gent

Són problemes de senyal més que de qualitat de codi.

Mostra que penses

Programar és la línia base. Els candidats que acaben contractats demostren criteri: per què van triar aquest enfocament, què farien diferent, on es trencaria el codi a escala, quins tests realment importen. El codi de React Native és el mitjà; les decisions són el que llegeix el panell.