Cómo diseñé un scorecard de prueba técnica que funciona de Graduate a Senior

El problema del «¿esto es un 3 o un 4?»

Cuando empecé a montar el proceso de contratación para mi equipo, quería un scorecard estructurado desde el principio. Escribí sobre la prueba técnica en sí en un post anterior. La prueba funcionaba. La puntuación, no. Al menos, no como la diseñé al principio.

Mi primer scorecard usaba una escala del 1 al 5 para cada criterio. «Uso de TypeScript: puntuación 1 a 5». «Gestión del estado: puntuación 1 a 5». Cada criterio tenía una rúbrica que describía qué significaba cada puntuación. Sobre el papel pintaba bien.

Después intenté usarlo.

Dos personas revisaron la misma entrega. Una le puso un 3 al TypeScript («hay tipos pero no son estrictos»). La otra le puso un 4 («tipos limpios en todo el código, buen uso de hooks tipados»). Estaban mirando el mismo código. Simplemente leyeron la rúbrica de forma distinta. Si dos personas razonables pueden no estar de acuerdo en la puntuación, la rúbrica no es lo suficientemente específica. La herramienta es el problema, no los revisores.

Checklists en vez de rúbricas

La solución fue simple: reemplazar cada puntuación subjetiva por una checklist de sí/no.

Así quedaba un solo criterio antes y después. Este es el uso de TypeScript:

El problema: «tipos limpios» y «tipos para las estructuras principales» son descripciones razonables del mismo código. Un revisor ve un 3, otro ve un 4. Los dos tienen razón.

Mismo criterio. Siete checks. Cada uno es un hecho que puedes verificar mirando el código. Dos revisores van a marcar las mismas casillas porque no hay nada que interpretar.

Hice esto para cada criterio en cuatro secciones:

• Funcionalidad core: ¿funciona la app?
• Capa de datos y API: ¿cómo obtiene y gestiona los datos?
• Calidad de código: ¿el código está bien escrito y bien organizado?
• Testing: ¿está testeado, y cómo?

100 checks. 100 puntos. Un punto cada uno.

Misma prueba, distinto techo

Los checks están ordenados por cuánta inversión representan.

Los primeros checks de cada criterio son cosas que cualquier candidato competente va a sacar en un plazo de 4 a 6 horas:

• ¿El FlatList renderiza items?
• ¿Funciona la paginación?
• ¿La pantalla de party tiene un estado vacío?
• ¿Hay tipos para las estructuras de datos principales?
• ¿Hay al menos un archivo de test?

Eso es la línea base. Si construiste lo que pedía el brief, pasas estos checks.

Los checks de más abajo necesitan más tiempo, más años de oficio, o ambas cosas:

• GraphQL en vez de REST
• Validación de respuestas en runtime con Zod
• MSW para mockear HTTP en tests
• Estructura de proyecto feature-first
• BDD con Cucumber
• Umbrales de cobertura obligatorios

Nada de esto se hace en un fin de semana. Son patrones que aprendes poniendo apps reales en producción.

Un candidato que invierte de 4 a 6 horas saca entre 50 y 65. Un candidato que invierte una semana entera con años de oficio detrás puede sacar de 85 a 95. El brief es el mismo. Las expectativas escalan con la puntuación.

Cómo se mapean los niveles

La puntuación total se mapea directamente a un nivel:

La puntuación del code review no es el panorama completo. La llamada de walkthrough añade más señal. El code review es la base.

Respetar la limitación de tiempo

Una prueba técnica no es una app de producción. Los candidatos tienen trabajos, familias, vidas. Te están dando su noche o su fin de semana. Bajarle la nota a alguien por no implementar una capa de caché o por no poner sus estilos junto al componente sería como bajarle la nota a una redacción contrarreloj por no tener notas al pie.

Por eso importan los checks de línea base. Tenerlos todos bien te da entre 50 y 65 de 100. Eso es territorio de Associate a Software Engineer. En mi antigua rúbrica, un «3 de 5» sonaba a premio de consolación. 55 de 100 en la checklist es un resultado positivo con un camino claro al siguiente nivel.

Qué aspecto tiene «por encima de la línea base»

Es en los checks de más abajo donde los candidatos se diferencian. No son requisitos. Son señales.

Un candidato que añade tests E2E con Detox con helpers extraídos me está diciendo algo sobre su cultura de testing. Uno que implementa GraphQL con Apollo me está diciendo algo sobre cómo enfoca las APIs. Uno que configura MSW con múltiples conjuntos de handlers (éxito, error, 401, timeout, offline) me está diciendo que ya ha depurado fallos de API reales.

Nada de esto es obligatorio. Todo se nota.

Los stretch goals se suman a los 100 puntos como bonificaciones: búsqueda, modo oscuro, accesibilidad, i18n, Storybook, ErrorBoundary. Son las marcas de alguien que tuvo tiempo y eligió invertirlo bien.

Lo que añade el walkthrough

El code review me da un número. El walkthrough me da contexto.

Un candidato que saca 65 en el code review podría subir a 85 después del walkthrough si puede explicar cada trade-off, decir qué cambiaría con más tiempo y navegar su codebase de memoria. También funciona en el otro sentido: una entrega de buena pinta que el candidato no sabe explicar baja un nivel. El número mide lo que construyeron. La conversación mide cómo piensan.

Diseñé el walkthrough como un conjunto de tablas de preguntas. Cada pregunta tiene cinco descripciones de señal, desde «no encuentra el código» hasta «lo explica de memoria con edge cases». El entrevistador marca una fila por pregunta. Se parece a la rúbrica del 1 al 5 que acababa de abandonar, pero los anclajes son de otra naturaleza: cada fila describe un comportamiento observable, no un juicio de calidad, así que dos entrevistadores que ven la misma respuesta marcan la misma fila. Se acabó el «¿ese walkthrough fue un 3 o un 4?».

Para candidatos Senior hay una sección adicional de diseño de sistemas en la misma llamada. Sin entrevista separada. Los últimos 15 a 20 minutos pasan de «enséñame tu código» a «¿cómo diseñarías esto para un equipo de 20 ingenieros?». Las mismas tablas de preguntas, el mismo formato de marcar una fila.

Lo que aprendí construyendo esto

Empieza con checklists, no con rúbricas. Cada vez que escribía una rúbrica («5 = excelente, 3 = bueno, 1 = malo»), se convertía en un debate sobre qué significa «bueno». Las checklists terminan el debate. El criterio está en el código o no está.

Ordena los checks por inversión, no por importancia. Los primeros checks no son más importantes que los últimos. Solo son más alcanzables en un plazo de 4 a 6 horas. A un candidato Senior que se salta el check 3 pero clava el check 7 no se le penaliza por el salto porque el total sigue reflejando su nivel.

Separa lo que puedes ver de lo que necesitas preguntar. El scorecard del code review es 100% observable desde el código. Nada de «¿la arquitectura está limpia?». El walkthrough es 100% conversacional. Nada de leer código durante la llamada. Cada documento tiene un solo trabajo.

Mantén la línea base alcanzable. Si un check necesitaría más de 6 horas de trabajo de un Software Engineer competente, pertenece a la mitad superior de la checklist, no a la línea base. Me pillé varias veces escribiendo checks de línea base que en realidad eran expectativas de Senior. La pregunta que me hacía todo el tiempo: «¿Esperaría esto de alguien que hace esta prueba después del trabajo un miércoles por la noche?». Si la respuesta era no, lo subía.

Usé este scorecard para nuestra primera ronda de contratación de React Native, y mi homólogo EM lo revisó y lo adoptó para las contrataciones de su equipo también. Esa es la prueba de un buen sistema: otra persona puede cogerlo y usarlo sin que estés en la sala. Los rangos podrían necesitar recalibración cuando pasen más candidatos, pero la estructura ha aguantado.

Si estás montando un proceso de contratación y tus entrevistadores siguen sin ponerse de acuerdo en las puntuaciones, prueba a reemplazar tu rúbrica por una checklist. Te va a sorprender lo mucho que se ponen de acuerdo cuando dejas de preguntar «¿cómo de bueno es esto?» y empiezas a preguntar «¿esto está aquí?».

Si quieres ver el punto de vista del candidato sobre lo que mide este scorecard, escribí un post complementario: Cómo aprobar una prueba técnica de React Native.