¿Qué tan difícil es la entrevista de Amazon?

Si llevas tiempo entrenando problemas de algoritmos y aun así te sientes poco preparado, tu instinto no se equivoca. Esta sección explica de qué está hecha esa dificultad adicional, porque no son los problemas, y resolver más de ellos no la resuelve.

Amazon usa un proceso de entrevistas estructurado. A los entrevistadores se les asignan Leadership Principles concretos para evaluar, toman notas detalladas durante la conversación, y esas notas se comparan después en un debrief. De ahí surgen dos consecuencias. Una historia que sonó bien en el momento se lee floja sobre el papel si no tiene decisión ni resultado, y la misma historia contada dos veces con detalles distintos en dos rondas se nota de inmediato al comparar las notas.

La otra fuente de dificultad es que el nivel conductual también se aplica en las rondas técnicas. Un candidato que resuelve el problema de código con limpieza pero no puede describir un momento en que discrepó con un manager ha fallado en un componente que una entrevista puramente técnica nunca habría medido.

El Bar Raiser es un entrevistador ajeno al equipo que contrata, capacitado específicamente para ese rol, cuyo trabajo es juzgar si elevas el promedio de las personas que ya están en ese nivel. No evalúa si el equipo necesita a alguien este trimestre, y puede bloquear una contratación que el manager que contrata sí desea.

En la práctica, esto significa que la persona que decide tu resultado no tiene ningún interés en cubrir el puesto. La urgencia no te ayuda, ni tampoco la buena relación con el manager. Lo que sí ayuda es una evidencia que resista quedar escrita y ser leída por alguien que nunca te conoció.

Normalmente no puedes saber quién es ese entrevistador, y no importa. Responde cada ronda como si un desconocido fuera a leerla después, porque así es.

Divide el trabajo. La mitad técnica es la parte conocida: estructuras de datos, algoritmos y, para nivel medio en adelante, diseño de sistemas. La mayoría de los candidatos que fallan no fallan aquí.

La mitad conductual necesita entre ocho y doce historias distribuidas entre los Leadership Principles, cada una con la situación, lo que tú decidiste personalmente y un resultado medible. Un solo proyecto puede aportar dos o tres historias desde ángulos distintos. Anota el resultado como número siempre que exista uno, porque la pregunta de seguimiento suele pedir exactamente eso.

Después, practica en voz alta. Una ingeniera backend con nueve años de experiencia había escrito notas excelentes y aun así se trabó en su primer ensayo, porque leer una historia y contarla ante una pregunta de seguimiento son habilidades distintas. Dos semanas de práctica oral en /mock-interview cambiaron su forma de contarlo más de lo que habría cambiado otro mes de lectura. El panorama del proceso, etapa por etapa, está en /answers/topic/company-interviews.

Cuatro patrones explican la mayoría de los casos, y ninguno tiene que ver con la inteligencia.

• Historias sin decisión. Describir lo que hizo un equipo en vez de lo que tú elegiste. Las notas terminan sin ninguna evidencia asociada a tu nombre.
• Sin resultado. Una historia que termina cuando el proyecto se lanzó, sin decir si funcionó.
• Quedarse sin material. Reutilizar el mismo proyecto en cuatro rondas, algo que el debrief detecta aunque ningún entrevistador individual lo haga.
• Resolver el problema en silencio. Trabajar una pregunta de código sin narrar el razonamiento, sin dejarle al entrevistador nada que anotar.

También vale la pena decirlo con claridad: aquí se rechaza a ingenieros capaces por razones que nada tienen que ver con su capacidad, incluidos el encaje con el equipo y la composición del panel ese día. La preparación mueve las probabilidades; no las decide, y un rechazo no es un veredicto sobre tu capacidad.