Paano pumasa sa React Native tech test

Ano talaga ang binibigyang-puntos ng panel

Nagre-review ako ng React Native tech test submissions. Karamihan ng mga rejection ay hindi problema sa coding. Marunong naman mag-code ang kandidato. Hindi nila ipinakita ang tamang mga bagay.

Ang post na ito ang advice na ibibigay ko sa isang kaibigan bago mag-submit ng take-home. Specific, practical, mula sa panig ng panel. Ang mga pagbabagong ginagawang “oo” ang “baka.”

Sumulat ako tungkol sa kung bakit ko ni-redesign ang isang tech test mula sa perspektibo ng hiring manager sa ibang post. Ito naman ang kabilang panig: paano pumasa sa isa.

Basahin ang brief nang dalawang beses. Tapos basahin mo ulit

Mukhang obvious. Ito ang pinakakaraniwang nami-miss.

Kung sinabi ng brief na “gumawa ng tatlong screens na may navigation,” huwag kang gumawa ng dalawa lang. Kung sinabi na “gamitin ang TypeScript,” huwag kang gumamit ng JavaScript. Kung sinabi na “mag-manage ng list na hanggang 6 items,” siguraduhing ang pag-add ng ika-7 ay naha-handle nang maayos.

Tini-check ng mga reviewer ang requirements na parang checklist. Bawat requirement na wala, bawas puntos. Ang pagsunod sa spec ay bahagi ng trabaho. Kung may nalalampasan kang requirements sa isang tech test na may malinaw na brief, ano pa kaya sa isang malabong Jira ticket? Basahin ang brief bago ka mag-start, basahin ulit sa gitna ng trabaho, at basahin nang isang huling beses bago mo i-submit.

Sinasabi ng project structure sa panel kung paano ka mag-isip

Ang unang ginagawa ko kapag binuksan ko ang isang submission ay tingnan ang folder structure. Bago ko basahin kahit isang linya ng code, may sinasabi na ang layout tungkol sa kung paano mo inaayos ang trabaho.

Type-first structure (screens/, components/, hooks/, services/):

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

Feature-first structure (bawat feature ay self-contained):

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

Wala namang mali sa kahit alin. Nagpapakita ang feature-first na nag-isip ka kung paano magsa-scale ang app. Kung itatanong ko sa’yo kung “ano ang mangyayari kapag 5 teams ang nagtatrabaho sa codebase na ito?” at sagot na ng structure mo ang tanong na ‘yon, lamang ka na.

Red flag: lahat ng file, nakatambak sa iisang flat na src/ folder nang walang organisasyon. Senyales ito na nagsimula ang coding bago naplano ang architecture.

Hindi optional ang TypeScript

Kung sinabi ng brief na “TypeScript preferred,” ituring mo itong required. Ang pag-submit ng plain JavaScript sa 2026 ay automatic na downgrade sa scorecard namin.

Ang bar ay ang paggamit nito nang maayos:

Ang isang any na patatawarin ko: isang third-party library type na aabutin ng isang oras para i-model nang maayos. Aminin mo ito sa isang comment. // TODO: i-type ito nang maayos, naubusan ng oras ay mas maganda basahin kaysa magkunwaring wala itong problema.

Red flag: any na nakakalat sa buong codebase na walang acknowledgement.

State management: pumili ka at panindigan mo

Wala akong pakialam kung gagamit ka ng Redux Toolkit, Zustand, React Context, o Jotai. Ang mahalaga ay pinili mo ito nang sinadya at kaya mong i-explain kung bakit.

Kung pipiliin mo ang Redux, gamitin mo ang Redux Toolkit. Hindi yung lumang switch/case reducer pattern. Kung makita kong createStore sa halip na configureStore, o manual na action type constants sa halip na createSlice, malamang kailangan ng pag-refresh ang Redux knowledge.

Ang talagang mahalaga:

Gawin:

• State logic na hiwalay sa UI
• Actions, reducers, at selectors sa sarili nilang files
• Business rules (tulad ng max list size) na enforced sa state layer
• Predictable ang mga updates

Huwag:

• Business logic na nasa loob ng mga components
• State na nakakalat sa mga useState calls na walang malinaw na pattern

Huwag mag-dispatch ng fetch tuwing nagmo-mount ang screen. Kung nag-navigate ako sa detail screen, bumalik, at bumalik sa parehong detail screen, hindi ko dapat makitang loading spinner ulit. Isang simpleng if (!data[id]) check bago ang dispatch(fetchDetails(id)) mo ay sapat na.

Tests: quality over coverage

Hindi mo kailangan ng 90% coverage. Kailangan mo ng meaningful tests. Mas panalo ang tatlong magagandang test kaysa sa dalawampung snapshot test.

Ang gusto kong makita:

Ang ayaw kong makita:

• Snapshot tests sa lahat ng dako. Nasisira sa bawat UI change at kaunti lang ang sinasabi tungkol sa behaviour.
• Tests na mino-mock ang lahat. Kung mino-mock ng test mo ang function na tini-test nito, tini-test nito ang mock.
• Walang tests. Mahirap mag-recover dito sa walkthrough.

Para sa brief na ganito kalaki, ang 5 hanggang 10 focused tests na nagko-cover ng critical paths (reducers, selectors, key interactions) ang hinahanap ng panel namin.

I-handle ang loading, errors, at empty states

Kahit sino ay kayang mag-build ng happy path. Ang tanong ay kung ano ang mangyayari kapag may nangyaring mali.

Red flag: nag-crash ang app sa mabagal na network. Walang loading state, walang error handling. Binuksan ng reviewer ang DevTools, ni-throttle ang network, at bumagsak ang app.

Mahalaga ang API call

GraphQL vs REST. Kung pareho ang ini-offer ng brief, execution ang una: ang well-implemented na REST client ay nananalo laban sa magulong GraphQL setup. Pero ang GraphQL na ginawa nang maayos ay mas mataas ang score sa rubric namin, kaya kung pareho kang komportable sa dalawa, ito ang mas malakas na pick. Maging handa kang i-explain kung bakit, alinman ang piliin mo.

Gamitin ang FlatList o FlashList para sa mga data list. Nire-render ng ScrollView ang lahat ng items nang sabay-sabay. Ayos lang ‘yan sa maikli at static na lista; sa mahigit 100 items, makikita mo ang frame drops, memory spikes, at eventual crashes. Ginagawang virtualised ng FlatList ang list, nire-render lang ang isang window sa palibot ng nakikitang bahagi. Ang ScrollView na nagwa-wrap ng .map() sa data na galing sa API ay nagsu-suggest ng gap sa pag-unawa sa rendering model ng RN.

Ibang mga bagay na napapansin:

• Caching: huwag mag-refetch ng data na meron ka na
• Pagination: huwag mag-fetch ng 1000 items sa unang load
• ErrorBoundary: nagke-catch ng JavaScript errors at nagpapakita ng fallback sa halip na puting screen

Sa edge cases ka nakaka-stand out

Ang happy path ang minimum. Ang pagkakaiba ng Software Engineer submission sa Senior ay ang edge case handling:

• Puno na ang list? Ano ang mangyayari kapag may nag-try na mag-add ng ika-7 na item? Isang toast, disabled button, modal. Kahit ano maliban sa tahimik na pag-fail.
• Walang laman ang list? Magpakita ng meaningful na empty state, hindi blangkong screen.
• Mabilis na taps? Nagdudulot ba ng duplicates o crashes ang pagpindot ng “add” nang limang beses nang mabilis?
• Back navigation? Kapag bumalik ako mula sa detail papuntang list, naka-preserve ba ang scroll position ko?
• Dulo ng list? Humihinto ba nang maayos ang pagination kapag wala nang data?

Hindi mo kailangang i-handle lahat ng ito. Ang pag-handle ng ilan sa mga ito ay nagpapakita na iniisip mo ang totoong users, hindi lang ang pagpasa ng requirements.

Ang README ay bahagi ng test

Sumulat ng README. Hindi novel. Isang maikling document na naglalaman ng:

Ang huling section na ‘yon ang sulit isulat nang maingat. Pinapayagan ka nitong aminin ang mga shortcut na ginawa mo nang hindi nadidiskubre ng reviewer bilang mga depekto. “Kung may mas maraming oras, magdadagdag ako ng E2E tests gamit ang Detox at mag-iimplement ng proper caching” ay nagko-convert ng nawawalang feature sa isang demonstrasyon ng judgement.

Ang walkthrough: dito napapanalunan ang trabaho

Kung may walkthrough call ang test, mag-prepare. Ang code ang nagpapasok sa’yo sa interview. Ang walkthrough ang magbibigay sa iyo ng offer.

Kilalanin ang code mo. Kung sasabihin ko “ipakita mo kung saan mo hina-handle ang API response,” dapat makarating ka doon halos agad-agad. Ang pag-hesitate ay nagdudulot ng duda kung gaano mo talaga kilala ang codebase.

I-explain ang trade-offs mo nang hindi naghihintay na tanungin. Kapag nagpapakita ka ng section ng code, sabihin mo “Pinili ko itong approach dahil X, pero alam ko na ang trade-off ay Y.” Iyan ang sagot na hinahanap ko bago pa man ako magtanong.

Maging honest tungkol sa mga shortcut. “Ginamit ko ang Context dito kasi mas mabilis, pero sa production app ililipat ko ito sa Zustand kapag naging mas complex ang state.” Malakas na sagot. “Sa tingin ko Context ang pinakamagandang approach” ay mas mahina, dahil alam ng panel ang mga trade-off at parang sinasabi mo na hindi mo alam.

Magkaroon ng listahan ng improvements. Kapag tinanong kita “ano ang babaguhin mo kung may dagdag na oras?” ang pinakamasamang sagot ay “wala, okay na ako dito.” Ang pinakamagandang sagot ay isang prioritised na listahan: “Una, magdadagdag ako ng caching, tapos E2E tests, tapos i-refactor ko sa feature-first folders.”

Magtanong pabalik. Ang mga pinakamahusay na walkthrough ay mga usapan, hindi presentasyon. Magtanong tungkol sa architecture ng team, sa testing approach nila, sa deployment process nila. Nagpapakita na ine-evaluate mo rin ang role, hindi ka lang umaasang pumasa.

Stretch goals: gawin mo, pero gawin mong maayos

Kung may binabanggit ang brief na mga optional extras, pumili ng isa o dalawa na kaya mong gawin nang maayos. Huwag mong pilitin ang lahat kung pangit ang kalalabasan. Isang well-executed na stretch goal ay mas mahalaga kaysa sa tatlong hindi tapos.

Ang mga pagkakamaling talagang nagpapalampas ng trabaho

Mga problema ito sa signal, hindi sa code quality.

Ipakita mong nag-iisip ka

Ang coding ang baseline. Nagpapakita ng judgement ang mga kandidatong natatanggap: bakit ito ang pinili nilang approach, ano ang gagawin nila nang iba, saan masisira ang code kapag nag-scale, anong tests ang talagang mahalaga. Ang React Native code ang medium; ang mga desisyon ang binabasa ng panel.