Lecciones aprendidas tras realizar alrededor de 1,000 entrevistas en Amazon

• Basado en 17 años trabajando en Amazon y realizando alrededor de 1,000 entrevistas (de ellas, unas 600 como entrevistador Bar Raiser), este texto analiza cómo las entrevistas conductuales influyen más en la decisión de contratación que las entrevistas técnicas
• La razón principal por la que candidatos técnicamente sobresalientes quedan fuera no es la falta de capacidad técnica, sino la forma en que se presentan
• Mientras invierten el 95% de su tiempo de preparación en la parte técnica, casi no dedican tiempo a la preparación para entrevistas conductuales, y ese es su mayor punto ciego
• Una entrevista no se parece tanto a un examen, sino más bien a una audición para decidir: “¿quiero trabajar con esta persona?”
• Lo principal que las empresas evalúan en una entrevista conductual es el encaje con el rol, el encaje con la organización y el nivel, y entender esto ayuda a elegir mejores historias

---

Patrones clave detectados en entrevistas Bar Raiser

• Un Bar Raiser es un entrevistador especialmente entrenado que participa desde fuera del equipo contratante y cuya función es verificar si una nueva contratación elevará el nivel de talento de Amazon
• Tiene poder de veto sobre cualquier candidato y participa en loops de entrevistas de todos los niveles, desde interns hasta Principal Engineer
• Tras alrededor de 50 entrevistas como Bar Raiser, apareció un patrón claro: la mayoría de los candidatos que no recibían oferta no fallaban por falta de capacidad técnica, sino por fracasar al expresarse
• Al llegar a la ronda final, la persona ya pasó el filtro técnico o el ejercicio asignado; por eso, la pregunta clave en la ronda final es: “¿este equipo quiere trabajar con esta persona?”

• Lección 1: exceso de preparación para un tipo de entrevista y casi nada para la otra

  • El candidato promedio invierte 95% de su tiempo en preparación técnica y 5% en todo lo demás; algunos ni siquiera dedican tiempo a la preparación no técnica
  • La preparación técnica resulta atractiva porque es concreta y se puede medir el avance, pero incluso en problemas de código nunca antes vistos se puede razonar con ayuda de pistas
  • En cambio, en una entrevista conductual, ante preguntas como “¿cómo manejaste un proyecto que salió mal?”, si no tienes una historia preparada, no puedes improvisar bien
    • No hay pistas, no es posible razonar todo en tiempo real y, sin preparación, la respuesta suele salir desordenada
  • El autor vio cientos de veces el mismo patrón: candidatos que superaban muy bien la ronda de código y se derrumbaban al hablar de su experiencia
    • Retroalimentación típica del debrief: “no pude obtener respuestas concretas; todas sus historias eran vagas y poco convincentes”
  • La preparación no técnica requiere muchísimo menos tiempo que la técnica: de 80 a 100 horas de preparación total, dedicar solo un fin de semana (unas 10 horas) a preparar historias puede cambiar por completo el resultado de la entrevista conductual
  • El rendimiento de seguir estudiando técnica cae por rendimientos decrecientes, mientras que preparar historias ofrece un retorno exponencial porque casi nadie lo hace

• Lección 2: cómo cuentas una historia importa tanto como la historia misma

  • Incluso un logro impresionante puede desperdiciarse por una mala presentación, y el patrón de falla más común es “ramble and stumble” (hablar de forma desordenada y titubeante)
    • Por ejemplo, cuando el candidato parece ir construyendo la historia sobre la marcha, o pasa 5 minutos dando contexto y luego vuelve para añadir detalles que olvidó
  • Para una presentación importante de trabajo normalmente se preparan estructura, secuencia y puntos clave, pero muchas personas enfrentan la entrevista improvisando
  • Existe la tendencia a pensar que preparar historias para entrevistas es “poco natural” o “tramposo”, pero así como un músico ensaya antes de un concierto, practicar no tiene nada que ver con la autenticidad
  • Forma práctica de empezar: con las preguntas “háblame de ti” y “¿por qué quieres trabajar en esta empresa?”
    • Escribe tus respuestas, grábate y mira la grabación para detectar en qué partes te alargas demasiado o qué muletillas innecesarias tienes
    • Repite hasta que la respuesta haga pensar: “quiero trabajar con esta persona”
  • 30 minutos de este tipo de práctica pueden mejorar más tu desempeño en entrevista que 20 horas de práctica de código

• Lección 3: la entrevista es una audición para mostrar cómo sería trabajar contigo

  • La mayoría de los candidatos piensa en la entrevista como un examen, pero no existe una hoja de respuestas correctas; en realidad es un proceso donde el entrevistador forma una impresión
  • El rol concreto del Bar Raiser es decidir si el candidato es mejor que el 50% superior de las personas que ya desempeñan ese trabajo
  • Los problemas de código que aparecen en la entrevista no se parecen del todo al trabajo real, pero las preguntas conductuales sí evalúan situaciones del día a día: resolver desacuerdos, manejar una crisis de proyecto, tomar decisiones con información incompleta
    • Cuando preguntan por una experiencia presentando una opinión contraria a stakeholders, el entrevistador imagina a esa persona en la siguiente reunión de planeación
    • Cuando explica cómo maneja conflictos dentro del equipo, el entrevistador se pregunta: “¿querría estar en la misma sala con esta persona?”
  • Los candidatos que abordan la entrevista como si fuera un examen intentan adivinar la respuesta que el entrevistador quiere oír y dan respuestas pulidas, sin asperezas
    • Resultado: queda la incertidumbre de “no tengo idea de cómo sería trabajar realmente con esta persona” → casi siempre termina en “No”
  • Forma práctica de prepararte: no pienses en lo que el entrevistador quiere oír, sino en lo que tú querrías oír de alguien que se va a unir a tu equipo
    • Cuenta con honestidad la versión real, incluyendo las partes difíciles y las decisiones que estuvieron al límite

Conclusión central tras unas 1,000 entrevistas

• Las personas que consiguen la contratación entran a la sala y comunican con claridad historias sobre su trabajo y sus capacidades, logrando que el entrevistador piense: “quiero trabajar con esta persona”
• La habilidad de contar historias es una capacidad que mejora con práctica, pero la mayoría ni siquiera piensa que sea algo que pueda prepararse
• Con un poco de preparación, el impacto puede ser mayor que casi cualquier otra cosa que hagas en tu carrera

Lo que las empresas buscan en las entrevistas conductuales

• La capacidad técnica por sí sola no define una oferta; en las entrevistas conductuales, las empresas buscan responder dos preguntas clave: “¿encaja con el rol y con la empresa?” y “¿en qué nivel sería más efectivo?”
• Si el encaje no existe, incluso alguien muy fuerte técnicamente puede quedar fuera; y si el nivel se evalúa mal, puede recibir una downlevel o ser rechazado por no cumplir con el nivel esperado

• Entender el encaje: encaje con el rol y con la organización

  • Role Fit (encaje con el rol): si la persona puede manejar los retos específicos y las condiciones del puesto
    • Un rol de backend en una startup de alto crecimiento y un rol de backend en una gran empresa pueden parecer similares técnicamente, pero exigen cosas distintas
  • Company Fit (encaje con la empresa): si la persona puede tener éxito en el entorno particular de esa organización
    • Se evalúa si su estilo de trabajo, forma de tomar decisiones y valores coinciden con la manera en que trabaja la empresa

• Cómo detectan las empresas señales de encaje

  • No pueden preguntar de forma directa “¿encajas con nuestra empresa?”, así que buscan en las historias del candidato señales de alineación o desajuste
  • Señales de encaje con el rol: comodidad ante requisitos ambiguos, capacidad de coordinar entre equipos, rapidez para iterar e incorporar feedback, etc.
  • Señales de encaje con la empresa: aparecen en las decisiones del candidato y en cómo las explica
    • Una empresa que valora bias for action preferirá historias donde alguien actuó rápido aun con información incompleta
    • Una empresa que valora customer obsession querrá ejemplos donde la persona profundizó de verdad en las necesidades del usuario
    • Una empresa que enfatiza radical transparency buscará historias donde se compartió información de forma abierta, incluso si resultaba incómoda
  • La misma historia puede enviar señales distintas según la empresa: un caso de pasar 3 semanas perfeccionando una solución podría interpretarse en una empresa como énfasis en calidad y en otra como parálisis por análisis

• Tipos comunes de misfit

  • Independencia vs. colaboración: estilo de resolver algo solo y volver con la solución vs. involucrar al equipo en cada etapa
    • Si todas las historias son de trabajo individual, eso genera dudas en empresas orientadas al consenso; a la inversa, si todas son de validación grupal, genera dudas en empresas que valoran la propiedad individual
  • Velocidad vs. rigurosidad: experimentación rápida y MVPs en startups vs. validación cuidadosa en sectores como salud o finanzas
    • También incluye diferencias de visión sobre calidad de código: invertir tiempo extra en una arquitectura limpia vs. priorizar una solución funcional dentro del plazo
  • Excelencia vs. pragmatismo: priorizar la perfección técnica y una arquitectura impecable vs. lanzar una solución práctica aunque sea imperfecta y cumpla con la fecha
  • Innovación vs. estabilidad: crear soluciones nuevas y desafiar lo existente vs. mantener y optimizar sistemas probados
  • Directo vs. diplomático: una cultura de radical candor frente a una cultura que valora la armonía y el cuidado de las formas
  • Datos vs. intuición: culturas que exigen respaldo de datos para toda decisión vs. culturas que confían más en el juicio basado en experiencia
  • Especialista vs. generalista: especialización profunda en un dominio dentro de una gran empresa vs. capacidad de asumir múltiples funciones en compañías pequeñas

Las 4 dimensiones que definen el nivel

• El nivel de un candidato se evalúa observando cuatro dimensiones presentes en todas sus historias; juntas muestran el punto donde puede operar con mayor efectividad

• Scope (alcance)

  • Mide a cuántas personas y en qué amplitud impacta el trabajo
  • Entry Level: mejora la productividad personal, ayuda a unos pocos compañeros
  • Mid Level: impacta una parte de cómo opera el equipo
  • Senior Level: impacta directamente a todo el equipo y empieza a extender su influencia al menos a otro equipo; colabora estrechamente con partners de producto y diseño
  • Staff Level: impacta directamente al menos a dos equipos, se expande a una organización más amplia e influye más allá de ingeniería, incluyendo producto, diseño y program management
  • Principal Level: cambia la forma en que operan múltiples equipos o grandes áreas de la organización, con influencia que llega hasta la estrategia de negocio

• Contribution (contribución)

  • Mide lo que realmente hizo la persona, distinguiendo con claridad entre “yo” y “nosotros”
  • Entry Level: ejecuta tareas asignadas, se hace cargo por completo de funcionalidades bien definidas
  • Mid Level: se apropia de una solución completa, desde identificar el problema hasta implementarla, al mismo tiempo que guía a otros
  • Senior Level: lidera iniciativas que requieren coordinación y hace avanzar el trabajo incluso cuando los requisitos son poco claros o la dirección es incierta
  • Staff Level: lidera iniciativas entre equipos, define dirección técnica y responde a situaciones donde las prioridades de stakeholders entran en conflicto
  • Principal Level: crea capacidades organizacionales, establece nuevas formas de trabajo y opera en entornos altamente ambiguos donde incluso hay que definir el problema en sí

• Impact (impacto)

  • Muestra qué mejoró como resultado del trabajo, y es importante incluir cifras que conecten el logro técnico con resultados de negocio o de usuario
  • Entry Level: mejora de productividad individual, reducción de tiempo en tareas repetitivas, prevención de bugs, etc.
  • Mid Level: mejoras cuantificables en la efectividad del equipo en un área específica, como reducir tiempos de despliegue o crear herramientas
  • Senior Level: cambia la forma de trabajar de todo un equipo y se expande a equipos cercanos; su impacto alcanza resultados de producto, experiencia de usuario o costos operativos
  • Staff Level: mejora la operación de varios equipos, con impacto conectable a métricas de negocio como ingresos, retención o velocidad de lanzamiento
  • Principal Level: crea capacidades organizacionales y lidera cambios estratégicos medidos en resultados de negocio y capacidad estratégica

• Difficulty (dificultad)

  • Refleja la complejidad, las restricciones y los trade-offs del problema resuelto; un problema difícil bien resuelto impresiona más que uno fácil con gran impacto
  • Entry Level: problemas intuitivos dentro de patrones establecidos, como aprender una tecnología nueva o depurar código poco familiar
  • Mid Level: problemas con más piezas en movimiento y soluciones menos obvias, incluyendo requisitos en tensión o complejidad técnica no vista antes
  • Senior Level: gestión de restricciones entre varios sistemas que interactúan, decisiones de arquitectura a nivel de equipo y necesidad de considerar tanto factores técnicos como de negocio
  • Staff Level: manejo de trade-offs en conflicto entre varios equipos, equilibrando enfoques técnicos distintos cuando las necesidades realmente chocan
  • Principal Level: tratamiento de trade-offs fundamentales entre necesidades organizacionales, resolución de problemas nuevos sin patrones ni precedentes establecidos, y decisiones a nivel de estrategia empresarial que requieren aprobación ejecutiva

Investigar lo que a la empresa realmente le importa

• No es posible tener información perfecta, pero con un poco de investigación enfocada se pueden obtener insights que la mayoría de los demás candidatos pasa por alto

• Aprovechar al recruiter

  • La mayoría de los candidatos trata al recruiter como un simple portero, cuando en realidad es la mejor fuente interna de información
  • El desempeño del recruiter depende de cuántas ofertas aceptadas logra, así que quiere que al candidato le vaya bien
  • Conviene preguntar directamente: “¿cuál es el reto actual de esta empresa?”, “¿qué capacidades son las más importantes para este rol?”, “¿me puedes compartir material para prepararme para la entrevista?”
  • Las preguntas de ejemplo en ese material de preparación tienen alta probabilidad de aparecer en la entrevista real

• Usar información pública

  • Las palabras que se repiten en la vacante revelan lo que la empresa valora: “fast-paced” y “compliance” mandan señales muy distintas
  • Dónde mirar: blog de ingeniería (qué logros celebran), tech talks y conferencias (de qué temas hablan), contribuciones open source (qué hacen público), documentación técnica (calidad de la documentación de APIs públicas), status pages y postmortems (si existe una cultura de aprender de los fallos)
  • Aunque no haya blog de ingeniería, es posible inferir prioridades observando el ritmo de lanzamiento del producto (velocidad de desarrollo) y las decisiones tecnológicas (innovación vs. estabilidad)

• Analizar patrones de discusión

  • En Glassdoor, Blind y Reddit no hay que quedarse con quejas individuales, sino buscar patrones a través de múltiples publicaciones
  • Una queja como “hay demasiadas reuniones” puede indicar una cultura muy orientada a colaboración y consenso, o bien un exceso de reuniones que afecta la productividad
  • Los elogios a la “autonomía” sugieren un entorno donde se confía en que la gente tome decisiones sin pedir validación constante

• Hablar con empleados actuales

  • En lugar de hacer preguntas superficiales sobre cultura, conviene preguntar cosas específicas
    • “¿Qué hicieron las personas que lograron ascender?”
    • “¿Qué comportamientos reciben retroalimentación negativa?”
    • “Cuando hay desacuerdo, ¿cómo toma decisiones el equipo?”
    • “¿Qué fue lo que más te sorprendió al trabajar aquí?”
  • Las personas que ya trabajan ahí pueden contar verdades que jamás aparecen en el sitio web: por ejemplo, que customer obsession en la práctica significa revisar datos de uso antes de escribir código, o que ownership puede significar estar disponible a las 2 a.m. por un incidente en producción

• El objetivo último de investigar

  • Toda la investigación tiene un único propósito: entender qué historias resonarán en la entrevista
  • Si la empresa valora velocidad, conviene enfatizar historias donde lanzaste rápido e iteraste; si valora profundidad técnica, casos donde fuiste a la raíz del problema; si valora colaboración, experiencias de trabajo entre equipos
  • Investigar también ayuda a evaluar si esa empresa es adecuada para ti: si valora comportamientos que no muestras de forma natural o que ni siquiera quieres desarrollar, tal vez no tenga sentido perseguir ese rol

Síntesis

• Las empresas no solo evalúan si puedes hacer el trabajo, sino también tu probabilidad de tener éxito en un entorno específico y el nivel en el que serías más efectivo
• Entender el encaje ayuda a elegir experiencias que conecten mejor con los valores de la empresa
• Entender el nivel ayuda a posicionar bien tus historias: el mismo proyecto puede verse como ejecución de entry-level, ownership de mid-level o liderazgo de senior-level según tu contribución real y cómo lo enmarques
• El objetivo no es conseguir cualquier oferta, sino la oferta correcta, en la empresa correcta y en el nivel correcto, donde tengas altas probabilidades de éxito