Hur Svår Är Amazon-Intervjun?

Om du har tränat på algoritmproblem och ändå känner dig oförberedd stämmer den känslan. Det här avsnittet förklarar vad den extra svårigheten består av, för det är inte uppgifterna, och att öva på fler av dem löser inte det.

Amazon kör en strukturerad process. Intervjuare tilldelas specifika Leadership Principles att undersöka, de för detaljerade anteckningar under samtalet, och dessa anteckningar jämförs sedan vid en debriefing. Det får två följder. En historia som lät bra i rummet framstår som tunn på papper om den saknar ett beslut och ett resultat, och samma historia berättad två gånger med olika detaljer i två rundor syns direkt när anteckningarna jämförs.

Den andra svårighetskällan är att den beteendemässiga ribban gäller även i tekniska rundor. En kandidat som löser kodproblemet snyggt men inte kan beskriva ett tillfälle då hen var oense med en chef har misslyckats med en komponent som en rent teknisk intervju aldrig skulle ha mätt.

Bar Raiser är en intervjuare utanför det rekryterande teamet, utbildad för rollen, vars uppgift är att bedöma om du höjer snittet för de som redan finns på den nivån. De bedömer inte om teamet behöver en person till detta kvartal, och de kan blockera en anställning som den rekryterande chefen vill göra.

I praktiken betyder det att personen som avgör ditt utfall inte har något intresse av att fylla rollen. Brådska hjälper dig inte, och inte heller god kemi med chefen. Det som hjälper är bevis som håller när det skrivs ner och läses av någon som aldrig har träffat dig.

Du kan oftast inte veta vilken intervjuare det är, och det spelar ingen roll. Svara i varje runda som om det senare läses av en främling, för det gör det.

Dela upp arbetet. Den tekniska halvan är den bekanta: datastrukturer, algoritmer och, för medelnivå och uppåt, systemdesign. De flesta kandidater som misslyckas gör det inte här.

Den beteendemässiga halvan kräver åtta till tolv historier fördelade över Leadership Principles, var och en med situationen, vad du personligen beslutade och det mätbara resultatet. Ett enda projekt kan ge två eller tre historier från olika vinklar. Skriv ner resultatet som en siffra där ett sådant finns, för följdfrågan brukar be om exakt det.

Öva sedan på dem högt. En backend-ingenjör med nio års erfarenhet skrev utmärkta anteckningar men körde ändå fast vid sin första övningsrunda, eftersom att läsa en historia och att berätta den under en följdfråga är olika färdigheter. Två veckors muntlig övning på /mock-interview förändrade framförandet mer än ytterligare en månads läsning skulle ha gjort. Den steg-för-steg-bilden av själva processen finns på /answers/topic/company-interviews.

Fyra mönster förklarar det mesta av det, och inget av dem handlar om intelligens.

• Historier utan beslut. Att beskriva vad ett team gjorde i stället för vad du valde. Anteckningarna slutar utan bevis kopplat till ditt namn.
• Inget resultat. En historia som slutar när projektet levererades, utan att säga något om det fungerade.
• Slut på material. Att återanvända samma projekt i fyra rundor, vilket syns vid debriefingen även om ingen enskild intervjuare märkte det.
• Tyst problemlösning. Att arbeta igenom en kodfråga utan att berätta resonemanget, vilket lämnar intervjuaren utan något att anteckna.

Det är också värt att säga rakt ut att kompetenta ingenjörer avvisas här av skäl som inte har med förmåga att göra, inklusive teampassning och sammansättningen av panelen den dagen. Förberedelse ändrar oddsen; den avgör dem inte, och en avvisning är inget utlåtande om din förmåga.