Evaluación de código: criterios objetivos de revisión

Dos evaluadores pueden revisar el mismo código y llegar a conclusiones opuestas, no porque uno tenga razón y el otro no, sino porque cada uno está evaluando con criterios distintos sin habérselo dicho a sí mismo. Una rúbrica explícita es lo único que evita que la evaluación de código dependa del humor o el estilo personal de quien corrige.

Qué mirar al revisar código

Cinco dimensiones cubren la mayoría de lo que importa al revisar código de un candidato o de un compañero de equipo: si el código resuelve correctamente el problema, incluyendo casos límite razonables; si es legible, con nombres y estructura que comunican intención sin necesitar comentarios excesivos; si maneja errores de forma apropiada, sin fallar silenciosamente ni de forma abrupta sin contexto; si está bien organizado, con responsabilidades separadas de forma lógica; y si las decisiones de diseño están justificadas, incluso cuando difieren del enfoque que el evaluador hubiera elegido.

Ninguna de estas dimensiones debería evaluarse de forma aislada. Código perfectamente legible que no maneja un caso límite crítico no es mejor código que uno menos elegante pero robusto frente a ese mismo caso.

Rúbrica de evaluación de código en 5 criterios

Corrección. El código resuelve el problema planteado, incluyendo casos límite no explícitos en el enunciado.

Legibilidad. Nombres de variables y funciones comunican propósito, la estructura es fácil de seguir sin necesitar explicación adicional constante.

Manejo de errores. Los casos de fallo se manejan de forma explícita y con mensajes útiles, sin excepciones silenciadas sin criterio.

Organización. El código está dividido en unidades con responsabilidad clara, sin funciones que hacen demasiadas cosas a la vez.

Justificación de decisiones. La persona puede explicar por qué eligió cada enfoque y qué alternativas consideró, cuando se le pregunta directamente.

Puntúa cada dimensión de forma independiente antes de llegar a una conclusión general. Esto evita que una impresión positiva o negativa temprana contamine la evaluación de las dimensiones restantes, un sesgo conocido como efecto halo.

Cómo evitar el sesgo de estilo

El error más común al revisar código ajeno es confundir "distinto a como yo lo haría" con "peor". Antes de señalar algo como un problema, pregúntate si esa decisión realmente introduce un riesgo real, como un bug potencial o dificultad de mantenimiento, o si simplemente refleja una preferencia estilística sin consecuencia práctica.

Una forma concreta de reducir este sesgo: separa explícitamente en tus notas de revisión los comentarios de estilo personal de los comentarios sobre correctitud o mantenibilidad real. Si un candidato usa una convención de nombres distinta a la que usarías tú pero consistente y clara dentro de su propio código, eso no debería restar puntos en la rúbrica.

Cómo dar feedback al candidato

Incluso cuando el candidato no avanza en el proceso, dar feedback específico sobre su código, cuando la política de la empresa lo permite, deja una impresión mucho mejor que un rechazo genérico. El feedback útil menciona algo concreto que hizo bien y algo concreto que podría mejorar, con ejemplo, no una valoración vaga como "el nivel no era el que buscábamos".

Si el candidato sí avanza, la conversación de revisión de código es una oportunidad para confirmar el razonamiento detrás de sus decisiones, no para hacerlo sentir examinado de nuevo. Preguntas abiertas como "¿qué harías distinto con más tiempo?" suelen revelar más que preguntas que buscan una respuesta correcta específica.

Para ver cómo aplicar estos mismos criterios dentro de un ejercicio completo de arquitectura de sistemas, en test de system design está la guía de cómo evaluarlo con criterio. Para los enunciados que se corrigen con esta rúbrica, en test de Python y en prueba de backend están los ejercicios por nivel, y en test de algoritmos, cuándo conviene aplicarlo y cuándo no.

Una evaluación de código con rúbrica explícita hace que dos evaluadores lleguen al mismo resultado sobre el mismo entregable. Si quieres estandarizar la revisión técnica de tu equipo, puedes agendar una demo.

Preguntas frecuentes

¿Debo revisar el código solo o también hacer preguntas al candidato sobre él?
Ambas cosas aportan valor distinto. La revisión del código muestra el resultado, la conversación posterior revela el razonamiento, que es donde suele estar la señal más útil sobre el nivel real.

¿Cómo evalúo código escrito con asistencia de IA?
El foco debería moverse hacia si el candidato entiende, puede explicar y puede corregir el código generado, más que hacia si lo escribió letra por letra sin ayuda.

¿Qué hago si dos evaluadores dan puntajes muy distintos al mismo código?
Es una señal de que la rúbrica necesita más claridad o que los evaluadores necesitan calibrar juntos revisando casos concretos, comparando qué vio cada uno de forma distinta antes de comunicar el resultado final.

¿La evaluación de código debe ser anónima respecto al origen del candidato?
Cuando es posible, sí. Ocultar información como universidad o empresa anterior durante la revisión inicial del código ayuda a reducir sesgos que no tienen relación con la calidad real del trabajo.