Isang test na gawa para sa ibang panahon
Apat na araw bago ako opisyal na mag-start, pumunta ako sa office para sa passport check. Habang nandoon ako, nabanggit ng manager ko na magbu-build ako ng team. Ang unang tanong ko: pwede ko bang baguhin ang interview process? Sabi niya oo. Hindi pa nga ako nag-uumpisa. Pagdating ng day one ko, ginagawa ko na ang bagong test.
Pumasok ako bilang bagong Engineering Manager ng mobile platform team, na nire-rebuild noon ang mobile app sa React Native: isang brownfield migration mula sa existing native iOS at Android apps. Kailangan ko ng mga engineer na kayang magtrabaho sa platform level.
Hindi ko na kailangang humingi pa na makita ang tech test. Pinagdaanan ko rin ito ilang linggo lang ang nakalipas. Ganoon ako na-hire: isang live coding exercise kung saan mag-build ka ng maliit na app sa loob ng mga isang oras habang nanonood ang interviewer, tapos may mga technical questions mula sa isang questionnaire. Mga 90 minuto ang buong interview.
May sense ang test sa original context nito. Noong mas maliit pa ang team at iba ang mga role na hinahanap, reasonable na paraan ito para mag-screen ng candidates nang mabilis. Nagbago na ang mga kailangan namin. Hindi na kami naghahanap ng taong gagawa ng simpleng screens. Nagha-hire na kami ng platform engineers na mag-o-own ng architecture na gagamitin ng lahat ng ibang mobile team.
Kailangan kong masagot ng test ang ibang mga tanong:
- Kaya ba nilang i-structure ang isang multi-screen app na may navigation na hindi babagsak?
- Kaya ba nilang mag-call sa totoong API at i-handle kung ano ang mangyayari kapag bumagsak ang network?
- Nagsusulat ba sila ng tests kasi may pakialam sila sa gumaganang software, o kasi sinabihan lang sila?
- Kaya ba nilang umupo sa harap ko at i-explain kung bakit ganoon ang ginawa nila?
Dinisenyo ang existing test para sa ibang mga tanong. Kailangan kong gumawa ng test na umiikot sa mga tanong namin.
Sinasaklaw ng post na ito ang pag-iisip sa likod ng redesign. Ang mga kasamang post ay tungkol sa detalye ng take-home brief, ang scorecard system, at kung saan dapat mag-focus ang mga kandidato.
Kung saan talaga bagay ang live coding
Masasabi sa’yo ng live coding kung komportableng mag-code ang isang tao habang may nanonood. Para sa ibang roles, mahalaga ‘yon. Para sa amin, iba ang kailangan kong makita.
Naranasan ko na ang dalawang panig. Nitong taon, habang nag-i-interview sa ibang kompanya, kumuha ako ng live coding exercise para sa role na kwalipikado ako, at nag-blangko ako. Simple ang problem, alam ko kung paano solusyunan, at dahil may nanonood sa bawat keystroke ko, nawala lahat sa isip ko. Bilang interviewer, nakita ko ring nangyari ang ganoon sa mga candidate: mga capable na engineer na nag-freeze sa mga problem na kayang-kaya nilang i-solve sa limang minuto kung nasa sarili nilang desk sila.
Para sa isang platform engineering role, kung saan ang trabaho ay architecture decisions, design system components, at CI/CD pipelines, gusto kong makita kung paano mag-approach ng problems ang mga candidate kapag may oras at context sila. Ang klaseng pag-iisip na talagang kailangan ng trabaho.
Pagpapakita vs. pagsasabi
Kasama rin sa dating process ang isang technical questionnaire. Pipili ang interviewer ng mga tanong mula sa isang reference sheet na nagko-cover ng React Native architecture, state management, testing strategies, at platform differences, tapos iko-compare ang mga sagot sa mga expected responses. Minsan, natatalakay na ng mga candidate ang mga topic habang nagla-live coding sila, kaya sini-skip na lang ng interviewer ang mga tanong na ‘yun.
Valid na topic ang lahat ng ‘yan. Ito mismo ang mga bagay na gusto kong maintindihan ng mga engineer ko. Kapag pinapa-explain mo sa isang tao ang isang concept, malalaman mo kung naiintindihan niya ang theory. Kapag nakita mo kung paano niya ito ina-apply sa sarili niyang code, ibang klase ng signal ‘yon.
Tine-test ng bagong process ang parehong mga topic gamit ang mismong code ng candidate. Sa halip na itanong ang “paano mo i-structure ang navigation sa isang complex na app?”, mabubuksan ko ang submission nila at makikita kung paano nila ito ina-approach, tapos magkakaroon kami ng mas malalim na usapan tungkol sa mga desisyon nila. Sakop pa rin ng walkthrough ang architecture, trade-offs, at technical depth, pero nakabatay ito sa isang bagay na ginawa ng candidate.
Ang ginawa ko sa halip
Nag-design ako ng take-home assessment. Isang maliit pero totoong app: multiple screens, public API, navigation, state management na may totoong business rules, TypeScript sa lahat. Hindi laruan. Hindi rin weekend project. Isang bagay na humihingi ng tunay na architectural thinking.
Apat na prinsipyo ang gumabay sa design.
I-mirror ang totoong trabaho. Dapat parang totoong trabaho ang dating ng test. Kung kaya ng candidate na i-build ang app na ito, kaya niyang mag-contribute sa codebase namin sa day one. Kung hindi niya kaya, useful pa rin na information ‘yon.
Alisin ang boilerplate. Binibigyan ko ang mga candidate ng fully configured starter project. TypeScript, ESLint, Prettier, Jest, React Native Testing Library, path aliases. Handa na lahat. Wala akong pakialam kung marunong mag-configure ng bundler ang isang tao. Ang pakialam ko ay kung marunong siyang magsulat ng application code.
Maging malinaw sa kung ano, hindi sa kung paano. Ine-explain ng brief kung ano ang dapat gawin ng app. Hindi nito sinasabi kung aling state management library ang gagamitin, paano i-structure ang mga folder, o aling API client ang pipiliin. Ang mga desisyon na ‘yon ang pinaka-revealing na parte ng submission. Ibang-iba ang sinasabi sa’yo ng candidate na pumili ng Redux Toolkit para sa isang three-screen app kumpara sa pumili ng Zustand o React Context. Walang mali sa dalawa. Parehong interesting. Bine-break down ko ang bawat design decision sa likod ng brief sa Paano magsulat ng take-home tech test na gusto talagang gawin ng mga kandidato.
Respetuhin ang oras ng mga tao. Isang linggo ang bigay sa mga candidate. Ang trabaho ay dapat tumagal ng 4 hanggang 6 na oras. May mga trabaho ang mga tao, pamilya, buhay. Walang dapat mag-file ng leave para sa tech test ng company na baka hindi naman sila i-hire.
Bakit ang walkthrough ang gumagawa ng karamihan sa trabaho
Kalahati lang ng evaluation ang take-home code. Ang kalahati pa ay ang walkthrough call: nagde-demo ang candidate ng app, niru-run niya nang live ang mga test niya, at tinatalakay niya ang code.
Dito mo nalalaman kung gaano kalalim naiintindihan ng isang tao ang ginawa niya. Ang pag-unawang ‘yon ang pagkakaiba ng engineer na kayang i-extend ang sarili niyang code sa engineer na kaya lang niyang i-ship ang gumaganang version nito.
Tatlong bagay ang hinahanap ko.
Ownership. “Navigate ka sa file kung saan hina-handle mo ang API response.” Kung siya ang sumulat, diretso siya doon. Kung hindi siya ganoon ka-comfortable sa code, mabilis na lumalabas iyon.
Trade-off thinking. Tinatanong ko ang bawat significant na desisyon. “Bakit ganyang state management approach?” Ang sagot na gusto ko ay hindi “kasi ‘yon ang pinakamahusay.” Ang sagot na gusto ko ay “kasi kasya sa scope na ito, ito ang punto kung saan masisira, at ito ang lilipatan ko.” Mas magandang systems ang nabubuo ng mga engineer na nag-iisip ng trade-offs kaysa sa mga nag-iisip ng absolutes.
Self-awareness. “Ano ang babaguhin mo kung may mas maraming oras ka?” Welcome ang tanong na ‘to sa magagaling na candidate. May listahan sila. Alam nila kung saan sila nag-cut corners. Alam nila kung ano ang marupok. Nag-iisip na sila ng improvements mula nang mag-submit sila. Madalas namang sumagot na lang ng “okay naman ako dito” ang mga candidate na mas kaunti ang experience, tapos move on.
Kung naghahanda ka para sa take-home assessment na tulad nito, sumulat ako ng gabay para sa mga kandidato: Paano pumasa sa React Native tech test.
Structured na scoring
Isang bagay na gusto ko agad mula day one ay isang structured scorecard. Kapag pinapalaki mo ang team at maraming tao ang kasali sa hiring, kailangang lahat ay mag-evaluate ng parehong bagay sa parehong paraan. Kung wala ‘yon, dalawang interviewer ang pwedeng mag-review ng parehong candidate at magkaiba ang conclusion kasi magkaiba ang tinitimbang nila.
Gumawa ako ng scorecard na hinahati ang code review sa apat na section: gumagana ba ang app, matino ba ang data layer, maayos ba ang pagkakabuo ng code, at may tests ba. Bawat section ay listahan ng mga yes/no check na tig-iisang punto, at may hiwalay na scoring ang walkthrough call gamit ang sarili nitong mga question table. Bawat interviewer, parehong mga bagay ang ine-evaluate sa parehong pagkakasunod-sunod.
Mina-map din ng scorecard ang scores sa levels. Isang number ang nagsasabi sa’yo kung Graduate, Associate, Software Engineer, o Senior level ang isang tao. Inaalis nito ang ambiguity sa levelling conversation. Ang rubric na ang sumasagot sa pag-iisip. Ang mga tao, nagve-verify na lang. In-publish ko ang buong checklist, ang mga level threshold, at ang scoring design na hindi gumana bago nito, sa Paano ko dinisenyo ang tech test scorecard na gumagana mula Graduate hanggang Senior, at kalaunan ay gumawa ako ng maliit na app para i-capture ang mga score na ‘yon habang nasa call.
May mas mahirap na round ang mga senior candidate
Para sa mga senior hires, may dagdag na system design conversation. Walang whiteboard. Walang “i-design mo ang Twitter sa 45 minuto.” Nag-uusap kami tungkol sa totoong scenarios na relevant sa platform na binubuo namin. Ano ang nagbabago kapag 20 teams ang nagbu-build sa iisang mobile platform? Paano mo hina-handle ang shared dependencies? Ano ang approach mo sa backwards compatibility?
Usapan ito ng dalawang engineer, hindi performance para sa audience. Ang mga pinakamahusay na candidate, nagpu-push back sa assumptions ko at nagtatanong para mag-clarify. ‘Yan ang behaviour na gusto ko sa isang senior sa team.
Mga unang araw
Sa unang linggo ko, naka-hire ako ng isang Senior Engineer sa pamamagitan ng existing process (nangyari ‘yon sa day two, bago pa matapos ang bagong test). Mula noon, ang bagong process na ang naging standard para sa lahat ng React Native hiring sa buong organisasyon. Ni-review ng kapwa kong EM, na may hawak na ibang team, ang test at ang scorecard, at pumayag siyang gamitin din ang mga ito para sa mga hire ng team niya. ‘Yan ang advantage ng well-documented system: gumagana ito lampas sa team ng isang manager.
Ang mga sumunod na hire, dalawang Software Engineer, ay dumaan sa bagong process: nakatanggap ang bawat candidate ng parehong test, parehong starter project, parehong evaluation criteria, at parehong scoring checklist. Kumokonti ang pagkakataong makapasok ang bias kapag nag-standardize ka.
Ang aral
Kung papasok ka sa bagong team bilang engineering manager, tingnan mo agad ang hiring process. Huwag kang maghintay hanggang “natutunan mo na ang codebase” o “naintindihan mo na ang culture.” Ang hiring ay isa sa mga bagay na may pinakamalaking epekto na gagawin mo. Bawat taong dinadala mo ay humuhubog sa team sa mga darating na taon.
At kung ang tech test mo ay hindi na tugma sa hinahanap mo, sulit na i-revisit ito.
Mas marami kang malalaman tungkol sa isang engineer mula sa pinag-isipang take-home code at structured walkthrough kaysa sa isang oras na panonood sa kanya habang nagta-type.
