Paano ko dinisenyo ang tech test scorecard na gumagana mula Graduate hanggang Senior

Ang problema sa “3 ba ‘to o 4?”

Noong sinimulan kong buuin ang hiring process para sa team ko, gusto ko ng structured scorecard mula sa simula. Naikuwento ko na ang mismong tech test sa isang naunang post. Gumana ang test. Ang scoring, hindi. O at least, hindi sa paraang una kong ginawa.

Ang unang scorecard ko ay gumagamit ng 1 hanggang 5 na scale para sa bawat criterion. “TypeScript usage: score 1 to 5.” “State management: score 1 to 5.” Bawat criterion, may rubric na naglalarawan kung ano ang ibig sabihin ng bawat score. Sa papel, mukha siyang okay.

Tapos ginamit ko na.

Dalawang tao ang nag-review ng parehong submission. Nag-score ang isa ng 3 sa TypeScript (“nandiyan naman ang types pero hindi strict”). Nag-score naman ang isa pa ng 4 (“malinis na types sa buong code, magandang gamit ng typed hooks”). Parehong code ang tinitingnan nila. Iba lang ang pagkakabasa nila sa rubric. Kung puwedeng magkaiba ng score ang dalawang reasonable na tao, hindi sapat ang specificity ng rubric. Ang tool ang problema, hindi ang mga reviewer.

Checklists sa halip na rubrics

Simple lang ang fix: palitan ang bawat subjective score ng yes/no checklist.

Ganito ang hitsura ng isang criterion bago at pagkatapos. Ito ang para sa TypeScript usage:

Ang problema: “malinis na types” at “types para sa main structures” ay parehong reasonable na description ng parehong code. Nakakita ang isang reviewer ng 3, ang isa naman ng 4. Tama silang dalawa.

Parehong criterion. Pitong checks. Bawat isa ay isang fact na makikita mo mismo sa code. Magche-check ang dalawang reviewer ng parehong boxes kasi wala nang dapat i-interpret.

Ginawa ko ito sa bawat criterion sa apat na sections:

• Core Functionality: gumagana ba ang app?
• Data Layer at API: paano nito kinukuha at mina-manage ang data?
• Code Quality: maganda ba ang pagkakasulat at pagkaka-organisa ng code?
• Testing: naka-test ba, at paano?

100 checks. 100 points. Isang point bawat isa.

Iisang test, ibang ceiling

Nakaayos ang checks ayon sa laki ng investment na kailangan.

Ang mga unang checks sa bawat criterion ay mga bagay na makukuha ng kahit sinong competent na candidate sa 4 hanggang 6 na oras:

• Nagre-render ba ng items ang FlatList?
• Gumagana ba ang pagination?
• May empty state ba ang party screen?
• May types ba para sa main data structures?
• May kahit isang test file ba?

Iyan ang baseline. Kung ginawa mo ang hinihingi ng brief, papasa ka dito.

Ang mga checks sa ibaba ay nangangailangan ng mas maraming oras, mas maraming taon sa trabaho, o pareho:

• GraphQL sa halip na REST
• Runtime response validation gamit ang Zod
• MSW para sa HTTP mocking sa tests
• Feature-first project structure
• BDD gamit ang Cucumber
• Mga coverage threshold na enforced

Hindi mo gagawin ang mga ito sa isang weekend. Mga pattern itong nakukuha mo sa pag-ship ng totoong apps.

Ang candidate na gumugol ng 4 hanggang 6 na oras, makaka-score sa 50 hanggang 65 na range. Ang candidate na gumugol ng buong linggo at may maraming taon ng experience, puwedeng umabot sa 85 hanggang 95. Iisa lang ang brief. Ang expectations ang nag-e-scale kasama ng score.

Paano nagiging level ang scores

Diretso ang mapping ng total score sa level:

Hindi kumpleto ang picture sa code review score lang. Ang walkthrough call ay nagdadagdag ng signal. Ang code review ang pundasyon.

Pag-respeto sa time constraint

Ang tech test ay hindi production app. May trabaho, pamilya, at buhay ang mga candidate. Binibigay nila sa’yo ang gabi o weekend nila. Ang pagpe-penalise sa isang tao dahil hindi nag-implement ng caching layer o hindi nag-co-locate ng styles ay parang pagbabawas ng score sa isang timed essay dahil walang footnotes.

Kaya mahalaga ang baseline checks. Kapag nakuha mo lahat nang tama, around 50 hanggang 65 out of 100 ang score mo. Associate hanggang Software Engineer territory iyan. Sa lumang rubric ko, ang “3 out of 5” ay parang consolation prize pakinggan. Ang 55 out of 100 sa checklist ay positive result na may malinaw na path papunta sa next level.

Ano ang hitsura ng “above baseline”

Sa mga checks sa ibaba nakaka-stand out ang mga candidate. Hindi mga requirement ang mga ito. Signals ang mga ito.

Ang candidate na nagdagdag ng Detox E2E tests na may extracted helpers, may sinasabi sa akin tungkol sa testing culture niya. Ang nag-implement ng GraphQL gamit ang Apollo, may sinasabi tungkol sa API thinking niya. Ang nag-setup ng MSW na may multiple handler sets (success, error, 401, timeout, offline), nagpapakita na nakapag-debug na siya ng mga totoong API failure dati.

Wala sa mga ito ang required. Lahat ng mga ito ay napapansin.

Ang stretch goals ay naka-stack sa ibabaw ng 100 points bilang bonuses: search, dark mode, accessibility, i18n, Storybook, ErrorBoundary. Mga marka ito ng taong may oras at pinili niyang gamitin nang tama.

Ano ang idinadagdag ng walkthrough

Ang code review ay nagbibigay sa akin ng number. Ang walkthrough ay nagbibigay sa akin ng context.

Ang candidate na may 65 sa code review ay pwedeng tumalon sa 85 pagkatapos ng walkthrough kung kaya niyang i-explain ang bawat trade-off, sabihin kung ano ang babaguhin niya kung mas may oras siya, at i-navigate ang codebase niya na parang kabisado. Gumagana rin ito pabaliktad: ang submission na mukhang malakas pero hindi ma-explain ng candidate, bumababa nang isang band. Sinusukat ng number kung ano ang ginawa niya. Sinusukat ng conversation kung paano siya mag-isip.

Dinisenyo ko ang walkthrough bilang isang set ng question tables. Bawat tanong ay may limang signal description, mula “hindi mahanap ang code” hanggang “ine-explain mula sa memory kasama ng edge cases.” Nagche-check ang interviewer ng isang row per tanong. Kamukha ito ng 1 hanggang 5 na rubric na kaaalis ko pa lang, pero magkaiba ang klase ng mga anchor: bawat row ay naglalarawan ng observable na behaviour, hindi quality judgement, kaya parehong row ang iche-check ng dalawang interviewer na nanonood ng parehong sagot. Wala nang “3 ba o 4 yung walkthrough na yun?”

Para sa Senior candidates, may dagdag na system design section sa parehong call. Walang separate interview. Ang huling 15 hanggang 20 minuto ay lumilipat mula sa “ipakita mo sa akin ang code mo” papunta sa “paano mo idi-design ito para sa team na may 20 engineers?” Parehong question tables, parehong check-one-row format.

Ano ang natutunan ko sa pagbuo nito

Mag-start sa checklists, hindi rubrics. Sa tuwing nagsusulat ako ng rubric (“5 = excellent, 3 = good, 1 = poor”), nagiging debate kung ano ang ibig sabihin ng “good”. Tinatanggal ng checklists ang debate. Nandoon sa code ang bagay o wala.

I-order ang checks ayon sa investment, hindi importance. Ang mga unang checks ay hindi mas importante kaysa sa mga huli. Mas abot lang sila sa 4 hanggang 6 na oras. Ang Senior candidate na nag-skip ng check 3 pero nakuha ang check 7 ay hindi pinaparusahan sa skip kasi ang total ay nagre-reflect pa rin ng level niya.

I-separate ang nakikita mo sa kailangan mong itanong. Ang code review scorecard ay 100% observable mula sa code. Walang “maganda ba ang architecture?” na tanong. Ang walkthrough ay 100% conversational. Walang pagbabasa ng code habang naka-call. Isang trabaho lang ang bawat document.

Panatilihing abot-kaya ang baseline. Kung ang isang check ay mangangailangan ng mahigit 6 na oras ng trabaho mula sa isang competent na Software Engineer, nasa upper half siya ng checklist, hindi sa baseline. Nahuli ko ang sarili ko nang ilang beses na nagsusulat ng baseline checks na talagang Senior expectations pala. Ang tanong na palagi kong ginagamit: “Aasahan ko ba ito mula sa isang taong gumagawa ng test na ito pagkatapos ng trabaho isang Miyerkules ng gabi?” Kung hindi, itinataas ko ito sa listahan.

Ginamit ko ang scorecard na ito para sa unang round ng React Native hiring namin, at ni-review ito ng kapwa kong EM at in-adopt niya rin para sa mga hire ng team niya. Iyan ang test ng magandang system: kaya itong kunin ng iba at gamitin nang wala ka sa kwarto. Baka kailanganin pang i-recalibrate ang mga band kapag mas marami nang candidate ang dumaan, pero tumatag ang structure.

Kung gumagawa ka ng hiring process at palaging hindi nagkakasundo ang mga interviewer mo sa scores, subukan mong palitan ang rubric mo ng checklist. Magugulat ka sa dami ng agreement na makukuha mo kapag tumigil ka sa pagtatanong ng “gaano kaganda ito?” at nagsimula kang magtanong ng “nandito ba ito?”

Kung gusto mong makita ang perspective ng candidate sa sinusukat ng scorecard na ito, sumulat ako ng companion post: Paano pumasa sa React Native tech test.