Com vaig dissenyar un scorecard de prova tècnica que funciona de Graduate a Senior

El problema de l’«això és un 3 o un 4?»

Quan vaig començar a construir el procés de contractació per al meu equip, volia un scorecard estructurat des del primer dia. Vaig escriure sobre la prova tècnica en si en un post anterior. La prova funcionava. La puntuació, no. Almenys, no com la vaig dissenyar al principi.

El meu primer scorecard feia servir una escala d’1 a 5 per a cada criteri. «Ús de TypeScript: puntuació 1 a 5». «Gestió d’estat: puntuació 1 a 5». Cada criteri tenia una rúbrica que descrivia què significava cada puntuació. Sobre el paper feia el fet.

Després vaig intentar fer-lo servir.

Dues persones van revisar la mateixa entrega. Una va puntuar el TypeScript amb un 3 («hi ha tipus però no són estrictes»). L’altra va posar un 4 («tipus nets arreu del codi, bon ús de hooks tipats»). Estaven mirant el mateix codi. Simplement van llegir la rúbrica de manera diferent. Si dues persones raonables poden no estar d’acord en la puntuació, la rúbrica no és prou específica. L’eina és el problema, no els revisors.

Checklists en comptes de rúbriques

La solució era simple: substituir cada puntuació subjectiva per una checklist de sí/no.

Així quedava un sol criteri abans i després. Aquest és l’ús de TypeScript:

El problema: «tipus nets» i «tipus per a les estructures principals» són descripcions raonables del mateix codi. Un revisor hi veu un 3, l’altre hi veu un 4. Tots dos tenen raó.

Mateix criteri. Set checks. Cadascun és un fet que pots verificar mirant el codi. Dos revisors marcaran les mateixes caselles perquè no hi ha res a interpretar.

Vaig fer això per a cada criteri en quatre seccions:

• Funcionalitat core: funciona l’app?
• Capa de dades i API: com obté i gestiona les dades?
• Qualitat de codi: el codi està ben escrit i ben organitzat?
• Testing: està provat, i com?

100 checks. 100 punts. Un punt cadascun.

Mateixa prova, diferent sostre

Els checks estan ordenats segons la inversió que representen.

Els primers checks de cada criteri són coses que qualsevol candidat competent aconseguirà en un termini de 4 a 6 hores:

• El FlatList renderitza ítems?
• Funciona la paginació?
• La pantalla de party té un estat buit?
• Hi ha tipus per a les estructures de dades principals?
• Hi ha almenys un fitxer de test?

Això és la línia base. Si vas construir el que demanava el brief, passes aquests checks.

Els checks de més avall requereixen més temps, més experiència, o totes dues coses:

• GraphQL en comptes de REST
• Validació de respostes en runtime amb Zod
• MSW per fer mock d’HTTP en tests
• Estructura de projecte feature-first
• BDD amb Cucumber
• Llindars de cobertura obligatoris

Res d’això no es fa en un cap de setmana. Són patrons que aprens posant apps reals en producció.

Un candidat que hi dedica de 4 a 6 hores treu entre 50 i 65. Un candidat amb anys d’experiència que hi dedica una setmana sencera pot treure de 85 a 95. El brief és el mateix. Les expectatives escalen amb la puntuació.

Com es mapegen els nivells

La puntuació total es mapeja directament a un nivell:

La puntuació del code review no és tot el panorama. La trucada de walkthrough afegeix més senyal. El code review és la base.

Respectar la limitació de temps

Una prova tècnica no és una app de producció. Els candidats tenen feines, famílies, vides. T’estan donant el seu vespre o el seu cap de setmana. Penalitzar algú per no implementar una capa de cache o per no posar els seus estils al costat del component seria com treure punts a un assaig fet a contrarellotge per no tenir notes a peu de pàgina.

Per això importen els checks de línia base. Tenir-los tots bé et dona entre 50 i 65 de 100. Això és territori d’Associate a Software Engineer. A la meva antiga rúbrica, un «3 de 5» sonava a premi de consolació. 55 de 100 a la checklist és un resultat positiu amb un camí clar cap al següent nivell.

Com queda «per sobre de la línia base»

Els checks de més avall són on els candidats es diferencien. No són requisits. Són senyals.

Un candidat que afegeix tests E2E amb Detox amb helpers extrets em diu alguna cosa sobre la seva cultura de testing. Un que implementa GraphQL amb Apollo em diu alguna cosa sobre com pensa les APIs. Un que configura MSW amb múltiples conjunts de handlers (èxit, error, 401, timeout, offline) em diu que ja ha depurat fallades d’API reals.

Res d’això no és obligatori. Tot es nota.

Els stretch goals se sumen als 100 punts com a bonificacions: cerca, mode fosc, accessibilitat, i18n, Storybook, ErrorBoundary. Són les marques d’algú que va tenir temps i va triar fer-lo servir bé.

Què hi afegeix el walkthrough

El code review em dona un número. El walkthrough em dona context.

Un candidat que treu 65 al code review pot pujar a 85 després del walkthrough si sap explicar cada trade-off, dir què canviaria amb més temps i moure’s pel seu codebase de memòria. També passa a la inversa: una entrega que fa bona pinta però que el candidat no sap explicar baixa un nivell. El número mesura el que van construir. La conversa mesura com pensen.

Vaig dissenyar el walkthrough com un conjunt de taules de preguntes. Cada pregunta té cinc descripcions de senyal, des de «no troba el codi» fins a «ho explica de memòria amb edge cases». L’entrevistador marca una fila per pregunta. S’assembla a la rúbrica de l’1 al 5 que acabava d’abandonar, però els ancoratges són d’una altra mena: cada fila descriu un comportament observable, no un judici de qualitat, així que dos entrevistadors que veuen la mateixa resposta marquen la mateixa fila. S’ha acabat l’«aquell walkthrough va ser un 3 o un 4?».

Per a candidats Senior hi ha una secció addicional de disseny de sistemes a la mateixa trucada. Sense entrevista separada. Els últims 15 a 20 minuts passen d’«ensenya’m el teu codi» a «com dissenyaries això per a un equip de 20 enginyers?». Les mateixes taules de preguntes, el mateix format de marcar una fila.

Què vaig aprendre construint això

Comença amb checklists, no amb rúbriques. Cada cop que escrivia una rúbrica («5 = excel·lent, 3 = bé, 1 = malament»), es convertia en un debat sobre què vol dir «bé». Les checklists acaben el debat. El criteri és al codi o no hi és.

Ordena els checks per inversió, no per importància. Els primers checks no són més importants que els últims. Només són més assolibles en un termini de 4 a 6 hores. Un candidat Senior que se salta el check 3 però clava el check 7 no és castigat pel salt perquè el total segueix reflectint el seu nivell.

Separa el que pots veure del que necessites preguntar. L’scorecard del code review és 100% observable des del codi. Res de «l’arquitectura està neta?». El walkthrough és 100% conversacional. Res de llegir codi durant la trucada. Cada document té una sola feina.

Mantén la línia base assolible. Si un check requereix més de 6 hores de feina d’un Software Engineer competent, pertany a la meitat superior de la checklist, no a la línia base. Em vaig enxampar diverses vegades escrivint checks de línia base que en realitat eren expectatives de Senior. La pregunta que em feia una vegada i una altra: «Esperaria això d’algú que fa aquesta prova després de la feina un dimecres al vespre?». Si la resposta era no, el pujava.

He fet servir aquest scorecard per a la nostra primera ronda de contractació de React Native, i el meu company EM el va revisar i també el va adoptar per a les contractacions del seu equip. Aquesta és la prova d’un bon sistema: algú altre pot agafar-lo i fer-lo servir sense que tu siguis a la sala. Els nivells podrien necessitar recalibració quan passin més candidats, però l’estructura ha aguantat.

Si estàs muntant un procés de contractació i els teus entrevistadors segueixen sense posar-se d’acord en les puntuacions, prova de substituir la teva rúbrica per una checklist. Et sorprendrà com es posen d’acord quan deixes de preguntar «com és de bo això?» i comences a preguntar «això hi és?».

Si vols veure la perspectiva del candidat sobre el que avalua aquest scorecard, vaig escriure un post complementari: Com aprovar una prova tècnica de React Native.