Planteamiento y contexto
El entrevistador quiere saber cómo manejas el desacuerdo técnico, no si puedes decir "hago cumplir mis estándares". Considera un pull request en el que crees que una nueva complejidad de concurrencia, un riesgo de privacidad o una prueba faltante reducirán la salud del código; el autor lo considera menor y pide fusionarlo primero. Explica los hechos, la discusión, la decisión y el resultado.
Las Prácticas de Ingeniería de Google recomiendan verificar si el autor tiene mejor contexto y luego explicar la inquietud en términos de salud del código. Si la complejidad permanecerá en la base de código, generalmente es mejor abordarla en el cambio actual; las emergencias son una excepción. Una respuesta sólida fundamenta el principio en un evento de colaboración verificable en lugar de calificar al autor como difícil.
Qué evalúa el entrevistador
- Vuelves a verificar tu propio juicio y puedes reconocer el contexto que tiene el autor.
- Explicas la inquietud basándote en el riesgo, el impacto en el usuario, las pruebas y el costo de mantenimiento, en lugar del estatus o el estilo personal.
- Separas un bloqueador de corrección, seguridad, privacidad o regresión de una tarea de seguimiento y una preferencia.
- Propones el cambio viable más pequeño, invitas al revisor adecuado y defines una ruta de decisión o escalamiento.
- Cuantificas el resultado: defectos evitados, menos rollbacks, tiempo de revisión, confianza del equipo y mejora de procesos.
Preguntas para aclarar primero
- ¿El desacuerdo es sobre corrección, seguridad, privacidad, rendimiento, mantenibilidad o una preferencia de codificación?
- ¿A qué capa concierne el comentario: implementación, pruebas, contrato de interfaz, riesgo de lanzamiento o política del equipo?
- ¿El autor proporcionó nueva evidencia, restricciones históricas o una fecha límite? ¿Quién es el dueño de la decisión técnica final?
- ¿El cambio es urgente y puede un gray release, un rollback o un feature flag reducir el riesgo?
- ¿Cómo protegerás la privacidad del autor y evitarás que una discusión pública se convierta en un juicio personal?
Una respuesta de 30 segundos
"Primero reproduzco o verifico los hechos y compruebo si el autor tiene un contexto que pasé por alto. Si el problema afecta la corrección, la privacidad o reduce claramente la salud del código, utilizo la ruta del código, el resultado de la prueba y el riesgo para el usuario para explicar por qué corresponde a este cambio, y luego propongo la solución más pequeña. Si es una preferencia, la marco como no bloqueante. Si aún estamos en desacuerdo, invito a un revisor del dominio o al líder técnico y registro la decisión y el seguimiento. Concluyo revisando los resultados de entrega, calidad y relaciones".
Solución paso a paso
Paso 1: Convierte un juicio personal en una afirmación comprobable
Reemplaza "este código es peligroso" por "dos actualizaciones concurrentes pueden sobrescribir el valor más reciente porque no hay una verificación de versión". Proporciona una reproducción, registro, prueba o benchmark. Mantén el comentario enfocado en el código y el riesgo, nunca en la capacidad del autor. Sin evidencia, haz una pregunta antes de bloquear.
Paso 2: Revisa el contexto que te falta
Pregunta sobre el contrato de interfaz, la compatibilidad, la ventana de lanzamiento, los equipos dependientes y el rollback. La guía de Google señala que el autor puede estar más cerca de la implementación y tener mejor información. Si la nueva evidencia refuta tu sugerencia, reconócelo y retírala en lugar de tratar la persistencia como calidad.
Paso 3: Clasifica los comentarios y propón el cambio mínimo
Clasifica los comentarios como bloqueadores, sugerencias no bloqueantes o refuerzo positivo. Un bloqueador se asigna a corrección reproducible, seguridad, privacidad o un riesgo de regresión de alta probabilidad; una preferencia de estilo puede ser un Nit o una convención documentada. Ofrece un parche pequeño, una prueba o un feature flag en lugar de una refactorización no relacionada en el mismo pull request.
Paso 4: Explica el porqué a través de la salud del código
Conecta la solución con el costo de mantenimiento futuro, la prevención de incidentes o la experiencia del usuario. No pegues un enlace a una regla sin aplicarlo a la ruta, el impacto y los criterios de aceptación de este cambio. Si el autor pide "limpiarlo más tarde", evalúa si la complejidad se olvidará o dificultará futuras revisiones.
Paso 5: Establece una ruta de decisión y escalamiento
Resume los acuerdos y las preguntas abiertas en la revisión. Si es necesario, programa una breve discusión o invita a un revisor con autoridad en el dominio. Un líder técnico debe decidir a partir de la evidencia, la salud del código y las restricciones de entrega, no por rango. Realiza el seguimiento de un elemento no bloqueante no resuelto con un responsable y una fecha límite.
Paso 6: Verifica los resultados y mejora el proceso
Antes de fusionar, verifica las pruebas, las comprobaciones estáticas, las métricas de despliegue y el rollback. Después de fusionar, observa los defectos, los rollbacks, las rondas de revisión y el tiempo de entrega. Si se repite el mismo rechazo, mejora la revisión de diseño, la plantilla de pull request o la documentación en lugar de depender de la persuasión cada vez. Limita la revisión en caso de emergencia, pero registra el riesgo y la remediación.
Una respuesta de ejemplo sólida
"Durante una migración de caché concurrente, comenté que las escrituras carecían de una verificación de versión. El autor lo consideró teórico y pidió fusionarlo. Reproduje un valor antiguo sobrescribiendo un valor nuevo con dos actualizaciones concurrentes y confirmé que el endpoint cambiaba el estado del pedido, por lo que era un bloqueador de corrección para este cambio. Reconocí que el autor conocía mejor los campos de compatibilidad heredados, mantuve esos campos, agregué escrituras versionadas condicionales y añadí pruebas de conflicto y métricas".
"Le pedimos al revisor de almacenamiento de pedidos que verificara el diseño y acordamos monitorear la tasa de conflictos y el rollback durante un gray release. El autor aceptó el parche pequeño y el despliegue no tuvo más sobrescrituras. Expliqué la evidencia en la revisión y di seguimiento a la refactorización más amplia de la caché por separado. En retrospectiva, el equipo agregó pruebas de escritura concurrente a la plantilla de pull request, reduciendo disputas similares".
Errores comunes
- Usar la antigüedad o 'el estándar lo dice' → el autor no puede ver el riesgo → muestra la ruta del código, la evidencia y la prueba de aceptación.
- Hacer que cada comentario sea bloqueante → la entrega y la confianza se ven afectadas → separa el riesgo, la sugerencia y la preferencia.
- Asumir que el autor está equivocado → se pasa por alto el contexto de implementación → vuelve a verificar y retira cuando la evidencia cambie.
- Tratar 'limpiarlo más tarde' como la opción por defecto → la complejidad tiende a permanecer → corrígelo ahora o asigna un responsable y una fecha límite.
- Juzgar a una persona en una revisión pública → el desacuerdo se convierte en conflicto → discute el código, el impacto y los siguientes pasos.
- Omitir las métricas de resultados → no se puede demostrar la efectividad → registra pruebas, despliegue, defectos, tiempo de revisión y cambios en los procesos.
Preguntas de seguimiento y respuestas
¿Qué haces cuando descubres que estabas equivocado?
Indica el hecho que faltaba, retira el bloqueador y explica la nueva evidencia públicamente. Agradece al autor por el contexto y deja de defender la autoridad; añade un breve registro si esto evita que se repita el error.
¿Qué pasa si el autor dice que la fecha límite requiere una fusión inmediata?
Evalúa si el riesgo afecta la corrección, la seguridad o el cumplimiento normativo. Mantén un bloqueador de alto riesgo y propón un alcance más pequeño, un feature flag, un gray release y un rollback explícito. Una sugerencia de bajo riesgo puede ser no bloqueante con un seguimiento asignado y con fecha programada.
¿Qué pasa si ninguna de las partes llega a un acuerdo?
Escribe la afirmación, la evidencia, el riesgo aceptable y las alternativas. Invita a un revisor del dominio o al líder técnico a decidir, y luego registra el razonamiento en el pull request para que futuros lectores no reabran la misma discusión.
¿Cómo evitas que la revisión se convierta en un cuello de botella?
Discute el diseño con anticipación, divide en pull requests pequeños y automatiza las pruebas y las comprobaciones de estilo. Revisa primero el diseño de alto riesgo y luego las sugerencias locales. Para emergencias, mantén una revisión mínima y un registro de remediación.