Hoe Moeilijk Is Het Amazon-Interview?

Als je algoritmeoefeningen hebt gebeukt en je toch onvoorbereid voelt, klopt dat instinct. Dit deel legt uit waaruit de extra moeilijkheid bestaat, want het zit niet in de opgaven, en er meer van oefenen lost het niet op.

Amazon hanteert een gestructureerde ronde. Interviewers krijgen specifieke Leadership Principles toegewezen om te onderzoeken, ze maken tijdens het gesprek gedetailleerde aantekeningen, en die aantekeningen worden achteraf in een debrief vergeleken. Dat heeft twee gevolgen. Een verhaal dat in de kamer prima klonk, oogt op papier dun als er geen beslissing en geen resultaat in zit, en hetzelfde verhaal dat in twee rondes met verschillende details wordt verteld, valt meteen op zodra de aantekeningen worden vergeleken.

De andere bron van moeilijkheid is dat de gedragslat ook in technische rondes geldt. Een kandidaat die het codeerprobleem netjes oplost maar geen moment kan beschrijven waarop hij het oneens was met een manager, is gezakt op een onderdeel dat een puur technisch interview nooit zou hebben gemeten.

De Bar Raiser is een interviewer van buiten het wervende team, opgeleid voor die rol, wiens taak het is te beoordelen of jij het gemiddelde verhoogt van de mensen die al op dat niveau zitten. Ze beoordelen niet of het team dit kwartaal iemand nodig heeft, en ze kunnen een aanname blokkeren die de wervende manager wil doen.

In de praktijk betekent dit dat degene die over je uitkomst beslist geen belang heeft bij het invullen van de rol. Urgentie helpt je niet, en een goede klik met de manager evenmin. Wat wel helpt, is bewijs dat overeind blijft nadat het is opgeschreven en gelezen door iemand die je nooit heeft ontmoet.

Meestal weet je niet welke interviewer het is, en dat maakt niet uit. Beantwoord elke ronde alsof die later door een vreemde wordt gelezen, want dat gebeurt ook.

Splits het werk. De technische helft is de bekende: datastructuren, algoritmen, en voor middenniveau en hoger, systeemontwerp. De meeste kandidaten die zakken, zakken niet hierop.

De gedragshelft vraagt acht tot twaalf verhalen die verdeeld zijn over de Leadership Principles, elk met de situatie, wat jij persoonlijk besliste, en het meetbare resultaat. Eén project kan twee of drie verhalen leveren vanuit verschillende hoeken. Schrijf het resultaat op als een getal waar dat kan, want de vervolgvraag is meestal precies daarnaar op zoek.

Oefen ze daarna hardop. Een back-end engineer met negen jaar ervaring schreef uitstekende aantekeningen en liep toch vast bij haar eerste oefenronde, omdat een verhaal lezen en het onder een vervolgvraag vertellen andere vaardigheden zijn. Twee weken mondelinge oefening op /mock-interview veranderde de uitvoering meer dan nog een maand lezen had gedaan. Het overzicht van de ronde stap voor stap staat op /answers/topic/company-interviews.

Vier patronen verklaren het meeste ervan, en geen enkel daarvan gaat over intelligentie.

• Verhalen zonder beslissing. Beschrijven wat een team deed in plaats van wat jij koos. De aantekeningen eindigen zonder bewijs dat aan jouw naam gekoppeld is.
• Geen resultaat. Een verhaal dat eindigt zodra het project werd opgeleverd, zonder iets te zeggen over of het werkte.
• Materiaal opraken. Hetzelfde project in vier rondes hergebruiken, wat in de debrief opvalt ook al merkte geen enkele interviewer het apart.
• Stil problemen oplossen. Een codeervraag doorwerken zonder de redenering hardop te vertellen, waardoor de interviewer niets heeft om op te schrijven.

Het is ook goed om ronduit te zeggen dat capabele engineers hier worden afgewezen om redenen die niets met bekwaamheid te maken hebben, waaronder teamfit en de samenstelling van het panel die dag. Voorbereiding verschuift de kansen; ze legt ze niet vast, en een afwijzing is geen oordeel over je kunnen.