Planteamiento y contexto
Cuéntame sobre alguna ocasión en la que tú y un equipo dependiente no estuvieron de acuerdo sobre un contrato de API. Ellos creían que tu propuesta aumentaría los costos de mantenimiento, mientras que tú temías que dejar el contrato sin cambios afectara la confiabilidad. ¿Cómo aclaraste los hechos, tomaste la decisión y realizaste la entrega?
Esta pregunta evalúa la colaboración entre equipos, los balances técnicos (trade-offs) y la capacidad de influencia. La guía de entrevistas de ingeniería de Atlassian busca explícitamente resolución de problemas, agilidad de aprendizaje, colaboración y comunicación. Una respuesta sólida muestra restricciones reales, evidencia verificable, una decisión compartida y un resultado, en lugar de describir al otro equipo como un obstáculo.
Qué está evaluando el entrevistador
El entrevistador quiere saber si puedes transformar un desacuerdo en un objetivo compartido, separar los hechos de las preferencias, explicar los trade-offs de compatibilidad, confiabilidad, costo y cronograma, registrar las decisiones y la propiedad (ownership), y cambiar de rumbo cuando la evidencia cambie. También observa si proteges el ritmo de entrega del equipo dependiente.
Preguntas de clarificación
Confirma los consumidores de la API, la versión, el SLO, la sensibilidad de los datos, la ventana de lanzamiento y las fallas inaceptables. Identifica si el desacuerdo se refiere a la semántica de los campos, los contratos de error, la duración de la compatibilidad o la propiedad operativa. Prepara registros (logs), tráfico, muestras de fallas, esfuerzo de migración y condiciones de rollback que ambos equipos puedan verificar.
Respuesta de 30 segundos
“Primero replanteé el desacuerdo como un objetivo compartido: cumplir con las restricciones de confiabilidad y mantenimiento dentro de la ventana de lanzamiento. Separé los hechos conocidos, los supuestos y las incógnitas, e invité al equipo dependiente a validarlos. Comparamos los costos de compatibilidad, observabilidad, migración y rollback, y luego utilizamos una prueba pequeña y reversible para reducir la incertidumbre. Finalmente, registramos la decisión, el responsable, la fecha límite y las señales de rollback. Después de la entrega, verificamos el resultado y convertimos la lección en una plantilla reutilizable”.
Respuesta detallada
Paso 1: Alinear los objetivos de los usuarios y del servicio
No comiences debatiendo qué diseño de campos es el correcto. Pon por escrito el impacto en el usuario, los objetivos de confiabilidad, los tiempos de lanzamiento y los límites de mantenimiento para que ambos equipos optimicen el mismo resultado. Si los objetivos entran en conflicto, identifica quién es el responsable de tomar el trade-off de producto o arquitectura.
Paso 2: Separar hechos, supuestos y preferencias
Enumera el volumen real de llamadas, la tasa de fallas, los clientes compatibles, el esfuerzo de migración y la ventana de soporte. Etiqueta las afirmaciones sin datos como supuestos y programa una verificación reversible. No utilices la antigüedad, el tamaño del equipo o el volumen de voz como evidencia.
Paso 3: Comparar las opciones de contrato
Compara el contrato actual, el cambio compatible más pequeño y el diseño a largo plazo. Para cada uno, registra la semántica de los campos, los códigos de error, el control de versiones, la observabilidad, el rendimiento, el mantenimiento y el rollback. Haz que el equipo dependiente complete sus propios costos para que la discusión no sea “me estás pidiendo que cambie”.
Paso 4: Diseñar un experimento reversible
Comienza con campos opcionales, escrituras duales (dual writes), tráfico espejo (shadow traffic) o pruebas de contrato del consumidor y observa los resultados reales. Dale al experimento un límite de tiempo (time box), medidas de éxito y condiciones de parada; no dejes que una capa de compatibilidad viva para siempre.
Paso 5: Decidir y registrar
Escribe el contexto, las opciones, la justificación, los riesgos, los responsables, la fecha límite y los desencadenantes de rollback en un ADR o registro de proyecto. Las personas pueden mantener su desacuerdo, pero deben saber cuándo se revisará la decisión.
Paso 6: Proteger la entrega del equipo dependiente
Proporciona ejemplos de migración, accesorios de prueba (test fixtures), una ventana de compatibilidad y tiempo de integración conjunto. Si tu cambio agrega trabajo, establece de qué soporte te harás cargo; no transfieras silenciosamente la responsabilidad de una migración incompleta a los consumidores.
Paso 7: Gestionar el riesgo del despliegue con métricas
Define la tasa de errores, la latencia, la tasa de campos desconocidos, el tiempo de rollback y el éxito del consumidor antes del lanzamiento. Expande el tráfico por etapas y pausa o realiza un rollback cuando se superen los umbrales, en lugar de esperar a buscar culpables.
Paso 8: Aprender y modificar el sistema
Verifica si los resultados coincidieron con los supuestos y registra qué evidencia cambió la decisión. Agrega plantillas de contratos, listas de verificación de revisión, pruebas de compatibilidad o una matriz de responsabilidades al proceso para que el próximo desacuerdo surja más temprano.
Respuesta modelo
Durante la migración de una API de estado de pedidos, el equipo consumidor temía que una nueva jerarquía de errores aumentara el mantenimiento del cliente, mientras que yo temía que los errores vagos amplificaran los reintentos durante una falla. Nos alineamos para mantener la ventana de lanzamiento y, al mismo tiempo, distinguir los estados reintentables de los no reintentables. Revisamos 30 días de muestras de errores, versiones de clientes y volumen de reintentos, y descubrimos que dos estados causaban la mayor parte del riesgo. Agregamos campos compatibles hacia atrás primero y utilizamos pruebas de contrato y shadow traffic. Yo me encargué del SDK de ejemplo, la guía de migración y el panel de control; el otro equipo se encargó de dos clientes de alto volumen. El ADR registró a los responsables, dos señales de pausa y el rollback. Aumentamos el tráfico gradualmente, observamos menos solicitudes duplicadas y no encontramos fallas de análisis sintáctico en clientes antiguos. En la retrospectiva, se agregó la plantilla de contrato de errores a la revisión. La decisión provino de métricas compartidas y pasos reversibles, no de imponer mi preferencia.
Errores comunes
Calificar al otro equipo como técnicamente débil
El equipo dependiente generalmente conoce las restricciones del consumidor. Descartarlo oculta el costo de migración y no demuestra una construcción de confianza.
Describir únicamente el diseño final
El entrevistador necesita ver cómo comparaste los trade-offs. Explica al menos dos opciones, la evidencia y por qué se rechazó una de ellas.
No dar resultados medibles ni asignación de responsabilidades
“Todos estuvieron de acuerdo” no es un resultado. Indica métricas, rango de tiempo, tu trabajo y el riesgo remanente.
Preguntas de seguimiento y respuestas
¿Qué pasa si el otro equipo todavía no está de acuerdo?
Verifica si nuevos hechos cambiaron la disputa y luego pide al responsable de arquitectura o de producto designado por el proceso de decisión que elija. Registra el desacuerdo, el riesgo y una fecha de revisión mientras se entrega el paso reversible más pequeño.
¿Qué pasa si solo quedan dos días antes del lanzamiento?
Reduce el alcance, protege contra riesgos irreversibles y a los consumidores críticos, y utiliza campos compatibles, un feature flag o verificación en shadow. Especifica qué se pospone; no sustituyas un rollback con una promesa verbal.
¿Cómo demuestras que el diseño no estuvo sobrediseñado (over-engineered)?
Menciona las capacidades que eliminaste, compara el tráfico real y el costo de fallas, limita en el tiempo la capa de compatibilidad y planifica su eliminación. Deja que la evidencia determine la complejidad.
¿Qué pasa si los datos refutan tu criterio?
Admite que el supuesto era incorrecto, actualiza el ADR y los umbrales, elige el camino más seguro y muestra cómo compartiste la nueva evidencia con los equipos afectados.
¿Cómo evitas que vuelva a ocurrir el mismo desacuerdo?
Convierte las decisiones sobre contratos, versiones, errores, ventanas de compatibilidad y responsabilidades en una plantilla. Agrega pruebas de contrato del consumidor y una lista de verificación de lanzamiento con una breve revisión previa al código.
¿Cómo demuestra esto influencia en lugar de control?
Enfatiza que creaste un objetivo compartido, evidencia y una decisión reversible mientras te hiciste cargo del trabajo de soporte. El equipo eligió el resultado; no te impusiste sobre el otro equipo.