Quão difícil é a entrevista da Amazon?

Se você vem treinando problemas de algoritmos sem parar e ainda se sente despreparado, o instinto está certo. Esta seção explica do que é feita essa dificuldade extra, porque ela não vem dos problemas, e resolver mais deles não resolve isso.

A Amazon usa um processo de entrevistas estruturado. Os entrevistadores recebem Leadership Principles específicos para avaliar, fazem anotações detalhadas durante a conversa, e essas anotações são comparadas depois em um debrief. Daí vêm duas consequências. Uma história que soou bem na hora parece fraca no papel se não tem decisão nem resultado, e a mesma história contada com detalhes diferentes em duas etapas aparece na hora quando as anotações são comparadas.

A outra fonte de dificuldade é que o nível comportamental também se aplica nas etapas técnicas. Um candidato que resolve o problema de código com limpeza mas não consegue descrever um momento em que discordou de um gestor falhou em um componente que uma entrevista puramente técnica nunca teria medido.

O Bar Raiser é um entrevistador de fora do time que está contratando, treinado especificamente para essa função, cujo trabalho é julgar se você eleva a média das pessoas que já estão naquele nível. Ele não avalia se o time precisa de alguém neste trimestre, e pode bloquear uma contratação que o gestor da vaga deseja.

Na prática, isso significa que a pessoa que decide seu resultado não tem interesse nenhum em preencher a vaga. Urgência não ajuda você, e boa relação com o gestor também não. O que ajuda são evidências que resistem depois de escritas e lidas por alguém que nunca te conheceu.

Normalmente você não sabe quem é esse entrevistador, e isso não importa. Responda cada etapa como se fosse ser lida depois por um desconhecido, porque é exatamente isso que acontece.

Divida o trabalho. A metade técnica é a parte familiar: estruturas de dados, algoritmos e, do nível pleno para cima, design de sistemas. A maioria dos candidatos que falha não falha aqui.

A metade comportamental precisa de oito a doze histórias distribuídas pelos Leadership Principles, cada uma com a situação, o que você decidiu pessoalmente, e um resultado mensurável. Um único projeto pode fornecer duas ou três histórias de ângulos diferentes. Anote o resultado como número sempre que existir um, porque a pergunta de aprofundamento costuma pedir exatamente isso.

Depois, ensaie em voz alta. Uma engenheira de back-end com nove anos de experiência tinha anotações excelentes e mesmo assim travou no primeiro ensaio, porque ler uma história e contá-la sob uma pergunta de aprofundamento são habilidades diferentes. Duas semanas de prática oral em /mock-interview mudaram a forma de contar mais do que mais um mês de leitura teria mudado. O panorama do processo, etapa por etapa, está em /answers/topic/company-interviews.

Quatro padrões explicam a maior parte dos casos, e nenhum deles tem a ver com inteligência.

• Histórias sem decisão. Descrever o que um time fez em vez do que você escolheu. As anotações acabam sem nenhuma evidência ligada ao seu nome.
• Sem resultado. Uma história que termina quando o projeto foi lançado, sem dizer se funcionou.
• Ficar sem material. Reutilizar o mesmo projeto em quatro etapas, o que o debrief percebe mesmo que nenhum entrevistador sozinho tenha percebido.
• Resolver o problema em silêncio. Trabalhar em uma questão de código sem narrar o raciocínio, sem deixar nada para o entrevistador anotar.

Também vale dizer claramente: engenheiros capazes são recusados aqui por motivos que nada têm a ver com capacidade, incluindo fit com o time e a composição do painel naquele dia. A preparação muda as chances; ela não as garante, e uma recusa não é um veredito sobre sua capacidade.