Design delle valutazioni

Progettare un test di coding per frontend developer che rifletta il lavoro reale

ClarityHire Team(Editorial)2 min read

Cosa richiedono davvero i ruoli frontend

La maggior parte del lavoro frontend non sono algoritmi. È:

  • Leggere un albero di componenti non familiare e trovare dove vive lo state
  • Cablare una risposta API in una UI senza rompere edge case (loading, error, empty)
  • Scrivere CSS che sopravviva a contenuto più lungo di quello mockato dal designer
  • Riconoscere quando un re-render è la causa di un bug di perf
  • Sapere quando aggiungere una dependency e quando no

Una domanda LeetCode "reverse-a-binary-tree" non filtra niente di questo. Peggio, filtra fuori candidate eccellenti nel lavoro reale e non interessate ai puzzle algoritmici.

Un test di 90 minuti che misura il reale

Dai alla candidata una piccola app React rotta con tre problemi:

  1. Un bug sottile. Una lista re-rendera tutte le righe a un singolo cambiamento perché il key prop è l'indice dell'array. È laggy con >100 item ma non ovviamente rotta.
  2. Una feature incompleta. Un form che posta ma non gestisce gli stati loading o error.
  3. Un problema di styling. Un layout card che si rompe quando il title è più lungo di 40 caratteri.

Chiedi di sistemare tutti e tre.

Rubrica

Punteggia quattro dimensioni, 1-4 ciascuna:

  • Diagnosi bug. Hanno identificato la causa prima di sistemare?
  • Completezza edge case. Loading, error, empty — coperti senza prompting?
  • Qualità codice. Naming, struttura, scelte di dependency.
  • Comunicazione. Hanno lasciato commenti o una nota breve che spiega trade-off?

Le candidate senior totalizzano abitualmente 3-4 in tutti e quattro. Il test non deve essere difficile per discriminare bene — deve essere reale.

Come somministrarlo senza che venga divulgato

  • Ruota tra 3-4 varianti di app rotta.
  • Pinna le candidate a una variante assegnata casualmente.
  • Usa i segnali di keystroke e coerenza del codice di ClarityHire.
  • Abbina sempre il test a un follow-up di 30 minuti.

Cosa non fare mai

  • Take-home di 4 ore.
  • "Costruisci un clone di X" aperto.
  • Test che richiedono setup locale da zero.

Il test frontend giusto richiede 90 minuti, rispecchia un ticket di martedì mattina e produce un punteggio rubrica che puoi difendere in un debrief.

frontendtest codingdesign valutazionereact

Articoli correlati