Entrevista de Revisión de Código: Preguntas, Rúbrica y Por Qué Supera los Algoritmos

Qué es realmente una entrevista de revisión de código

Una entrevista de revisión de código es exactamente lo que parece: al candidato se le proporciona un pull request funcional —de 100 a 400 líneas, una única característica o corrección de error— y se le pide que lo revise como si un compañero lo hubiera abierto. Identifica problemas, sugiere cambios y camina al entrevistador a través de su razonamiento. A veces hay errores deliberados. Siempre hay decisiones que requieren criterio.

Es el formato más infrautilizado en la contratación técnica. La mayoría de los procesos aún recurren por defecto a una ronda de algoritmo en pizarra o un ejercicio para hacer en casa. Ambos son buenas señales para cosas específicas. Ninguno prueba la habilidad en la que los ingenieros dedican más tiempo después de ser contratados.

Por qué supera la ronda de algoritmo

Tres razones, en orden de impacto.

1. Prueba el trabajo real. Los ingenieros pasan más horas revisando código que escribiéndolo desde cero. Un proceso que no mide la capacidad de revisión está midiendo la dimensión equivocada y llamándola ingeniería.
2. Es difícil de falsificar con IA. Los LLMs pueden escribir el diff. Tienen dificultades para argumentar por qué una función debería dividirse cuando un revisor senior tiene un argumento defendible para el otro lado. La señal está en el ida y vuelta, que es donde los candidatos asistidos por LLM colapsan.
3. Se escala según la antigüedad. Los juniors notan sintaxis y errores. Los mid notan estructura. Los seniors notan las decisiones de diseño que el diff está ocultando (qué se eliminó, qué se cambió deliberadamente no). El mismo artefacto, lecturas muy diferentes —lo que significa que un PR puede impulsar entrevistas de L3 a L6 con pesos de rúbrica ajustados en lugar de bancos de preguntas separados.

Este es el formato al que recurren los equipos cuando se han dado cuenta de que LeetCode no es predictivo y una muestra de trabajo pura para hacer en casa es demasiado cara para ejecutar al principio del embudo.

Cómo elegir la base de código

El PR que uses determina si la entrevista mide criterio o trivialidades. Tres cosas son importantes:

• Usa código real y anonimizado. Un fragmento de juguete con tres errores obvios entrena a los candidatos a buscar trucos. Un diff real con cambios de calidad mixta los obliga a leer realmente.
• Elige un dominio que el candidato no haya memorizado. Evita una aplicación de tareas pendientes o un algoritmo de estilo leetcode. Usa algo con lógica de negocio —una regla de precios, una verificación de permisos, una política de reintentos. La familiaridad con el dominio no es la señal.
• Asegúrate de que hay al menos una decisión defendible basada en criterio. La mejor entrevista de revisión de código tiene cero respuestas "incorrectas" y tres lugares donde un revisor reflexivo podría objetar de ambas formas. Ahí es donde mides antigüedad.

Carga la ronda con el diff cargado en un editor real —no un PDF estático. Las salas de codificación colaborativa de ClarityHire abren el archivo con anotaciones y un hilo de comentarios que el entrevistador puede ver en tiempo real, por lo que la revisión se siente como un PR normal de GitHub en lugar de un interrogatorio.

La rúbrica de calificación de cuatro dimensiones

Toma prestada la estructura de una rúbrica de diseño de sistemas pero reconstruye las dimensiones para el trabajo de revisión.

1. Identificación de problemas

¿Identificaron las cosas que una revisión real identificaría? Califica por densidad y severidad:

• 4 — identificó el problema crítico (seguridad, corrección o arquitectura) más las cosas pequeñas
• 3 — identificó el problema crítico o la mayoría de las cosas pequeñas
• 2 — identificó problemas de nivel superficial pero perdió el problema estructural
• 1 — perdió el problema crítico y criticó formato

2. Priorización

Dos problemas nunca son del mismo peso. Califica si el candidato distingue "esto es un error" de "esto podría ser más limpio" de "no bloquearía esto". Los ingenieros seniors anclan a los revisores alrededor de los errores; los juniors tratan cada comentario como de igual prioridad.

3. Calidad de la justificación

Para cada comentario que dejan, ¿pueden articular la disyuntiva? "Extraería este helper" es un comentario de nivel B. "Extraería este helper porque la misma lógica aparece en el flujo de cancelación de pedidos y queremos que evolucionen juntos" es la versión senior. Califica por especificidad, no por vocabulario.

4. Tono y colaboración

La revisión de código es una habilidad relacional. Un revisor que es técnicamente correcto pero escribe comentarios que tu equipo rechazará es un negativo neto. Califica por: ¿el comentario se presenta como una sugerencia en la que el autor puede actuar, o como un ataque?

Esta es la dimensión que la mayoría de los formatos de entrevista no pueden medir en absoluto. Las entrevistas de revisión de código la surfacean claramente.

Preguntas de muestra para anclar la conversación

Estos son los indicadores que los entrevistadores deben guardar hasta después de que el candidato haya hecho su propio pase:

• "Camina conmigo por los comentarios que realmente publicarías, en el orden en que los publicarías."
• "¿Qué comentario único harías bloqueante?"
• "Si el autor se opone a tu comentario más grande, ¿cuál es tu segundo mejor argumento?"
• "¿Qué no está en este diff que debería estarlo? ¿Qué preguntarías en la descripción del PR?"
• "¿Qué no mencionarías, aunque lo hayas notado?"

La última pregunta es la más discriminatoria de antigüedad del conjunto. Saber qué ignorar es la mitad de la revisión de código efectiva.

Cómo evaluar una revisión abierta

La entrevista produce artefactos desordenados —comentarios en línea, una transcripción del recorrido verbal, a veces un resumen escrito. Tres reglas para evaluarlos consistentemente:

• Usa una plantilla de calificación compartida por rol. Constrúyela una vez desde tu biblioteca de rúbricas y reutilízala en candidatos.
• Califica el artefacto y la conversación por separado. Un candidato que escribió grandes comentarios pero argumentó mal en la discusión en vivo es una contratación diferente que uno que lo invirtió.
• Ejecuta una ronda solo escrita a escala, en vivo en persona para finalistas. La calificación asistida por IA de los comentarios escritos proporciona un primer pase útil sobre densidad y especificidad al principio del embudo, donde no puedes permitirte tiempo en vivo. La ronda en vivo recoge la señal de conversación que la calificación no puede.

Resistir la asistencia de IA durante la ronda

Si el candidato ejecuta el diff a través de Claude o GPT en otra pestaña, los comentarios que pegue serán técnicamente densos pero estilísticamente inconsistentes con su propia argumentación en la discusión. Dos formas de surfacear eso:

• Observa el patrón de edición —los pegados limpios y grandes de prosa estructurada seguidos de silencio son la señal, de la misma manera que lo son en una ronda de codificación
• Haz la discusión en vivo obligatoria y adversarial: elige el comentario más fuerte del candidato y argumenta en su contra. Los comentarios autorados por IA colapsan cuando el candidato no puede defender la redacción específica que eligió

No necesitas prohibir la IA para que la ronda funcione. Necesitas diseñarla para que un candidato solo de IA no pueda pasar la mitad de la conversación.

Qué hacer después

Elige un PR de tu base de código, anonimízalo e pilota la ronda con dos ingenieros actuales la próxima semana. Que revisen el diff en frío y se califiquen a sí mismos contra la rúbrica. Cualquier discrepancia que aparezca entre su puntuación y tu sentimiento visceral de cómo revisan realmente en el trabajo es la discrepancia que tu rúbrica está arreglando. Luego ejecútalo en tu próximo proceso y compara las puntuaciones de los candidatos contra tus resultados de evaluación de codificación existentes. En nuestra base de clientes, el ordenamiento de rango se desplaza —y el nuevo orden mapea mejor a quién realmente se desempeña después de la contratación.