Cómo hablar sobre un error técnico o fracaso laboral en una entrevista

I. Introducción: el error técnico como indicador de madurez profesional

Pocas preguntas generan tanta incomodidad en una entrevista técnica como "cuéntame sobre un error grave que hayas cometido". La reacción instintiva de muchos candidatos es minimizar el hecho, diluirlo en generalidades o, en el extremo opuesto, convertirlo en una humildad performativa que en realidad busca lucimiento. Ninguna de las dos estrategias funciona, y hay evidencia empírica que lo confirma.

A. La falacia del "profesional infalible" y los riesgos de la falsa modestia

Un estudio publicado en el Journal of Personality and Social Psychology, basado en nueve investigaciones —incluyendo un diario de una semana de duración y un experimento de campo—, identificó y documentó empíricamente el fenómeno del "humblebragging": la jactancia disfrazada de queja o de humildad. Los resultados son contundentes: tanto la variante basada en quejas como la basada en falsa modestia resultan menos efectivas que la jactancia directa, porque reducen la simpatía que genera el interlocutor, la percepción de competencia, la disposición a acceder a peticiones y hasta la generosidad económica hacia esa persona. Curiosamente, la modalidad de "queja disfrazada" es incluso menos efectiva que quejarse sin más, porque el receptor la percibe como insincera^[4]. Trasladado a una entrevista técnica: decir "mi mayor defecto es que soy demasiado perfeccionista" o narrar un fracaso ficticio y trivial no genera la confianza que se busca; produce el efecto contrario. Los reclutadores técnicos, especialmente en roles de ingeniería de confiabilidad o desarrollo senior, están entrenados para detectar este patrón.

B. El cambio de paradigma: de la evasión de culpas a la demostración de seguridad psicológica

La alternativa no es la autoflagelación ni la broma vacía, sino un cambio de marco conceptual. Amy Edmondson, profesora en Harvard Business School y una de las investigadoras más citadas en el estudio de la seguridad psicológica en equipos, sostiene que la clave no está en si el fracaso ocurrió, sino en cómo se piensa sobre él^[2]. Este mismo principio es el que sostiene la cultura de post-mortems de Google SRE, donde escribir un informe de incidente "no es un castigo, sino una oportunidad de aprendizaje para toda la compañía"^[7]. Un candidato que puede narrar un incidente técnico con esta lógica —contexto, decisiones, causa raíz, aprendizaje sistémico— transmite exactamente el tipo de madurez que se busca en perfiles senior o de SRE, donde la honestidad operativa es una competencia tan valorada como el dominio técnico. Este enfoque conecta directamente con el método STAR para responder preguntas conductuales en entrevistas, ya que un post-mortem bien narrado es, en esencia, una estructura STAR aplicada a un incidente técnico.

II. Encuadre conceptual: cómo clasificar el incidente antes de contarlo

A. Diferenciación entre error humano y fallo sistémico

Antes de elegir qué historia contar, conviene entender la diferencia conceptual entre "error" (mistake) y "fracaso" (failure) que propone Edmondson. Un error es una desviación no intencionada de un procedimiento, estándar o protocolo conocido; solo puede ocurrir en territorio familiar, donde ya existe conocimiento previo disponible. Un fracaso, en cambio, es cualquier resultado que se desvía de lo deseado, independientemente de la intención o la causa que lo originó^[5]. Esta distinción importa porque no todos los fracasos son fruto de errores, y no todos los errores producen fracasos: se puede cometer un error y aun así obtener un buen resultado, o se puede fracasar sin haber cometido ningún error, simplemente por operar en condiciones de incertidumbre genuina.

B. Tipología de fallos aplicable a la narrativa profesional

A partir de esa distinción, Edmondson propone tres categorías de fracaso que resultan directamente aplicables a la narrativa de entrevista^[5][6]:

• Fallo básico: un resultado no deseado causado por un error humano en territorio conocido. Es el más prevenible de los tres.
• Fallo complejo: el resultado de la interacción de múltiples factores, ninguno de los cuales por sí solo habría provocado el incidente. Este tipo de fallo, que Edmondson describe como "tormentas perfectas", se ha vuelto cada vez más frecuente a medida que los sistemas se interconectan y ganan complejidad.
• Fallo inteligente: el resultado no deseado de una acción tomada en territorio nuevo, guiada por una hipótesis razonada, en persecución de un objetivo y habiendo tomado recaudos para minimizar el riesgo innecesario. Para calificar como "inteligente", el fallo debe cumplir cuatro criterios: ocurrir en territorio sin precedentes claros, perseguir un objetivo genuino, partir de una hipótesis fundamentada tras haber hecho la tarea de investigación previa, y ser de magnitud acotada en términos de seguridad, reputación e impacto financiero^[6].

Elegir bien la categoría del incidente que se va a narrar cambia por completo el mensaje que recibe el entrevistador. Un fallo básico bien gestionado demuestra disciplina y capacidad de aprendizaje de procedimientos; un fallo complejo bien analizado demuestra pensamiento sistémico; un fallo inteligente bien defendido demuestra criterio para tomar riesgos calculados, una competencia especialmente valorada en roles que exigen innovación técnica.

C. Selección del caso apropiado según el nivel de experiencia

El caso elegido debe ser proporcional al nivel de seniority del puesto. Un perfil junior que se postula a su primer rol de backend puede narrar con total legitimidad un fallo básico —un despliegue sin pruebas suficientes, una migración de base de datos mal validada— siempre que demuestre haber interiorizado el procedimiento correcto después. Un perfil senior o de SRE, en cambio, debería poder narrar un fallo complejo o inteligente, porque se espera que ya haya automatizado la prevención de los fallos básicos más comunes. Esta calibración es la misma lógica que distingue la progresión descrita en la matriz de habilidades y criterio técnico de programador junior a senior: el criterio técnico madura junto con la capacidad de anticipar y contener el radio de impacto de un incidente antes de que escale.

III. Anatomía de la respuesta: estructurar el relato como un post-mortem técnico

El formato de post-mortem de Google SRE ofrece una estructura narrativa robusta porque fue diseñada precisamente para comunicar incidentes de forma clara, objetiva y útil para terceros que no vivieron el evento^[1][7]. Un caso ilustrativo documentado por Google ayuda a ver esta estructura en acción: durante una operación rutinaria de baja de un rack de servidores ("satélite"), un bug en la automatización de mantenimiento interpretó una lista vacía de máquinas como "sin filtro" en lugar de "ninguna máquina", lo que provocó que miles de servidores de producción, a nivel global, fueran borrados de disco simultáneamente. El tráfico de usuarios tuvo que redirigirse a los centros de datos principales, generando un ligero incremento de latencia durante los dos días que tomó reinstalar las máquinas afectadas^[1].

A. Contexto y detección: alcance e impacto objetivo

La primera parte del relato debe establecer, sin dramatismo ni minimización, qué sistema estaba en juego, qué se esperaba que ocurriera y cómo se detectó la desviación. En el caso del rack decommission, esto se traduce en explicar qué es un proceso de "diskerase", por qué se reintentó la operación y en qué momento el comportamiento del sistema divergió de lo esperado. En una entrevista, esta sección equivale a responder con precisión: ¿qué estaba en producción?, ¿qué usuarios o sistemas dependían de ello?, ¿cómo se dio cuenta el equipo de que algo estaba mal —alertas automáticas, reportes de usuarios, monitoreo proactivo—? Cuantificar el impacto (duración, usuarios afectados, servicios degradados) transmite rigor y evita la ambigüedad que suele acompañar los relatos vagos de "tuvimos un problema en producción".

B. Mitigación inmediata y contención: decisiones bajo presión

La segunda parte narra las decisiones tomadas en tiempo real, con la incertidumbre propia del momento. Aquí es donde el candidato debe explicar qué opciones evaluó, qué información tenía disponible y por qué eligió una ruta de mitigación sobre otra. No se trata de demostrar que la decisión fue perfecta, sino de mostrar el razonamiento bajo presión: capacidad de priorizar la contención del daño por sobre la comprensión completa del problema, algo que en sistemas complejos rara vez ocurre de forma simultánea. Es importante mencionar aquí que este tipo de presión sostenida, si se repite sin los apoyos adecuados, es también uno de los factores que alimentan el desgaste profesional descrito en los síntomas del síndrome de burnout; reconocerlo en una entrevista, sin victimizarse, añade una capa adicional de autoconocimiento profesional.

C. Análisis de causa raíz (RCA): claridad técnica sin abstracciones vacías

La tercera parte es la más exigente técnicamente y la que distingue a un candidato senior de uno que simplemente memorizó un guion. El objetivo de un post-mortem, según la filosofía SRE, es asegurar que el incidente quede documentado, que todas las causas raíz contribuyentes sean bien comprendidas y, sobre todo, que se implementen acciones preventivas efectivas para reducir la probabilidad o el impacto de una recurrencia^[7]. En el caso del rack, la causa raíz no fue simplemente "un bug", sino un patrón específico: una API que trataba una lista vacía como ausencia de filtro en lugar de como "ningún elemento que procesar", combinada con límites de tasa insuficientes que permitieron que la operación destructiva se propagara sin control a miles de máquinas simultáneamente^[1]. Explicar la causa raíz con ese nivel de especificidad técnica —evitando frases genéricas como "hubo una falla de comunicación" o "no seguimos el proceso"— es lo que separa un relato memorable de uno olvidable.

IV. Responsabilidad personal frente a la cultura sin culpas (Blameless)

A. El equilibrio entre responsabilidad directa y factores sistémicos

La cultura blameless de Google SRE parte de la premisa de que todas las personas involucradas en un incidente actuaron de buena fe y tomaron la mejor decisión posible con la información disponible en ese momento; el objetivo es identificar causas contribuyentes sin señalar a un individuo o equipo por un comportamiento inapropiado^[7]. Pero aplicar esto en una entrevista no significa diluir la responsabilidad personal en el sistema. Un análisis publicado que revisa críticamente esta práctica advierte que los post-mortems "blameless" no son realmente ausentes de responsabilidad (blame), sino que deberían ser "sin sanción" (sanction-less); esa distinción es importante porque, en la práctica, muchos autores bien intencionados terminan omitiendo detalles clave, evitando nombrar a los actores involucrados y abusando de la voz pasiva, lo cual paradójicamente obstruye el aprendizaje e invita al chisme y la culpa encubierta^[3]. En una entrevista, el equivalente es no esconder la propia participación detrás de un "el equipo decidió" quirúrgicamente vago: se puede reconocer el propio rol en la decisión y, al mismo tiempo, explicar los factores sistémicos —falta de límites de tasa, ausencia de pruebas automatizadas, presión de plazos— que hicieron que el error individual escalara a incidente.

B. Superación de la voz pasiva: modelos mentales y presiones en el momento

El mismo análisis crítico propone una serie de preguntas que investigadores de incidentes deberían formularse para ir más allá de la superficie: qué supuestos hizo la persona al diseñar o implementar un componente, si esos supuestos seguían siendo válidos, qué influyó en la decisión de actuar de determinada manera cuando fue alertada, o por qué se decidió postergar la implementación de una salvaguarda que podría haber evitado el problema^[3]. Trasladar estas preguntas a la propia narrativa de entrevista implica abandonar construcciones como "se cometió un error" y reemplazarlas por "asumí que el endpoint validaba los datos de entrada antes de procesarlos, y esa suposición resultó incorrecta bajo cierta condición de carga". Esta transparencia sobre el propio modelo mental —y no solo sobre el resultado— es precisamente lo que un entrevistador técnico busca evaluar, y es una habilidad que también resulta central al dar y recibir feedback técnico constructivo en revisiones de código, donde la honestidad sobre las propias decisiones de diseño facilita la mejora colectiva.

C. El valor de la transparencia como muestra de confiabilidad profesional

Google ha llevado este principio incluso más allá de los límites internos de la organización: comparte post-mortems externos con clientes afectados por incidentes de su plataforma, bajo la lógica de que "preocuparse por la confiabilidad de tus clientes significa compartir los detalles de tus caídas"^[8]. Este mismo principio de responsabilidad compartida —definir objetivos de nivel de servicio (SLOs), medir el cumplimiento y reaccionar conjuntamente ante desviaciones— es trasladable a una entrevista: cuando un candidato comparte abiertamente qué salió mal y qué aprendió, sin edulcorar ni ocultar, está demostrando el mismo tipo de confiabilidad relacional que las organizaciones buscan replicar con sus propios clientes.

V. Mitigación a largo plazo y aprendizajes técnicos transferibles

A. Implementación de medidas preventivas sostenibles

Todo relato de incidente debe cerrar con las acciones de seguimiento, que son, según la filosofía de postmortems, tan importantes como la documentación y la comprensión de la causa raíz^[7]. En el caso de Google, tras el incidente del rack, el equipo invirtió varias semanas auditando y añadiendo verificaciones de sanidad ("sanity checks") a la automatización, para hacer que el flujo de baja de servidores fuera idempotente —es decir, que ejecutarlo múltiples veces produjera siempre el mismo resultado seguro—^[1]. Este tipo de medida preventiva concreta (guardarraíles automatizados, límites de tasa, pruebas de idempotencia) es mucho más convincente en una entrevista que una promesa abstracta de "tener más cuidado la próxima vez". Además, prácticas como los simulacros DiRT (Disaster Recovery Testing), que permiten a los equipos ensayar respuestas a fallos catastróficos antes de que ocurran en producción, son un ejemplo de cómo la cultura de aprendizaje se institucionaliza más allá de un incidente puntual^[8].

B. Transformación del fallo personal en valor organizacional duradero

La prueba más contundente de que un aprendizaje fue genuino, y no solo retórico, es su efecto medible en el tiempo. Tres años después del incidente del rack, Google experimentó un evento similar —varios satélites quedaron inactivos, generando de nuevo un incremento de latencia—, pero los elementos de acción implementados a partir del primer post-mortem redujeron drásticamente el radio de impacto y la velocidad de propagación del segundo incidente^[1]. Este es el arco narrativo ideal para una entrevista: no solo "aprendí de mi error", sino "la medida que implementé después demostró su valor cuando una situación similar volvió a presentarse". Instituir este tipo de aprendizaje de forma sistemática también es una de las razones por las que muchas organizaciones invierten en procesos de onboarding técnico que transmiten explícitamente estas lecciones a quienes se incorporan, evitando que el conocimiento adquirido a partir de un incidente se pierda con la rotación del equipo.

C. Conclusión: cerrar la respuesta vinculando la experiencia al puesto

Un relato de fracaso técnico bien construido no termina en la anécdota; termina conectando esa experiencia con las competencias específicas que el puesto exige. Si se postula a un rol de SRE, la conclusión natural es mencionar cómo esa experiencia moldeó la forma en que se definen SLOs, se diseñan pruebas de resiliencia o se documentan incidentes. Si se postula a un rol de liderazgo técnico, vale la pena vincular el aprendizaje con la manera en que hoy se fomenta la seguridad psicológica en el propio equipo, un aspecto que también resulta relevante al considerar la transición descrita en las diferencias entre Staff Engineer y Engineering Manager, donde la gestión de la cultura de aprendizaje del equipo pesa tanto como la competencia técnica individual. En última instancia, hablar de un error técnico en una entrevista no es una confesión: es una demostración estructurada de cómo se piensa, se decide y se mejora un sistema —y a quien lo cuenta— bajo condiciones reales de incertidumbre. Para complementar esta preparación, conviene también revisar qué preguntas inteligentes hacerle al reclutador al final de la entrevista, ya que indagar sobre la cultura de post-mortems y manejo de incidentes de la propia empresa es, a su vez, una señal de la misma madurez profesional que se intenta transmitir.

Fuentes Oficiales y Referencias Consultadas

• sre.google - sre.google
• ovid.com - ovid.com
• sre.google - sre.google