Proiectarea unui test de cod pentru programatori frontend care reflectă realitatea jobului

Ce necesită de fapt rolurile frontend

Majoritatea lucrărilor frontend nu se referă la algoritmi. Se referă la:

• Citirea unui arbore de componente necunoscut și găsirea locului unde se află starea
• Integrarea unui răspuns API într-o interfață fără a afecta cazurile limită (încărcare, eroare, gol)
• Scrierea CSS-ului care rezistă conținutului mai lung decât a modelat designerul
• Recunoașterea când o re-renderare este cauza unui bug de performanță
• Știerea când să adăugați o dependență și când nu

O întrebare LeetCode de tip "reverse-a-binary-tree" nu filtrează niciuna din acestea. Mai rău, filtrează în afară candidații care sunt excelați la jobul real și nu sunt interesați de puzzle-uri algoritmice.

Un test de 90 de minute care măsoară lucrul real

Oferiți candidatului o mică aplicație React defectă cu trei probleme:

1. Un bug subtil. O listă care re-renderează toate rândurile la o singură schimbare deoarece prop-ul key este indexul array-ului. Lista este lentă cu >100 de articole, dar nu evident defectă.
2. O funcție incompletă. Un formular care postează, dar nu gestionează starea de încărcare sau eroare.
3. O problemă de stil. O dispoziție de card care se spartă când titlul este mai lung de 40 de caractere.

Cereți-le să repare toate trei. Oferiți-le aplicația în funcțiune, baza de cod și libertatea de a adăuga biblioteci (sau nu).

Aceasta măsoară abilități reale: citirea codului necunoscut, recunoașterea modelelor, judecată cu privire la când să adăugați dependențe, gust în CSS, completitate cu privire la cazurile limită.

Rubrica de evaluare

Notați patru dimensiuni, 1–4 fiecare, ancorate:

• Diagnosticul bug-ului. Au identificat cauza înainte de reparație? Sau au rezolvat doar un simptom?
• Completitudinea cazurilor limită. Încărcare, eroare, gol - le-au acoperit fără solicitare?
• Calitatea codului. Denumire, structură, alegeri privind dependențele.
• Comunicare. Au lăsat comentarii sau o notă scurtă explicând compromisurile?

Candidații seniori notează în mod regulat 3–4 în toate patru dimensiuni. Testul nu trebuie să fie greu pentru a discrimina bine - trebuie să fie real.

Cum să-l administrați fără ca acesta să se scurgă

• Rotire între 3–4 variante de aplicație defectă.
• Atribuiți candidații la o variantă atribuită aleatoriu.
• Utilizați semnalele keystroke și coerență de cod integritate ale ClarityHire, astfel încât un candidat care a lipit o reparație de altundeva să fie marcat pentru revizuitor pentru a investiga în apelul de follow-up.
• Asociați întotdeauna testul cu o discuție de follow-up de 30 de minute în care candidatul prezintă modificările sale. Dacă nu pot explica propriul lor diff, scorul scade în consecință.

Ce nu trebuie niciodată să faceți

• Take-home-uri de 4 ore. Veți pierde cei mai buni candidați către companii care respectă timpul lor.
• Teste deschise "construiți un clone al X." Varianța este prea mare; rubricile se defectează.
• Teste care necesită configurarea unui mediu local de la zero. Utilizați un IDE găzduit, astfel încât timpul de configurare este zero.

Testul frontend potrivit durează 90 de minute, reflectă un tichet de marți dimineață și produce un scor rubric pe care îl puteți apăra într-o discuție de debrief. Este ancora oricărui funnel de angajare pentru programatori frontend.