Jak Těžký Je Pohovor v Amazonu?

Pokud jste dřeli algoritmické úlohy a přesto se cítíte nepřipraveni, ten instinkt je správný. Tato sekce vysvětluje, z čeho se skládá ta navíc obtížnost, protože nejde o úlohy samotné a řešení dalších z nich to nevyřeší.

Amazon vede strukturovaný proces. Tazatelům jsou přiděleny konkrétní Leadership Principles, které mají prověřit, během rozhovoru si dělají podrobné poznámky a tyto poznámky se poté porovnávají na debriefingu. Z toho plynou dva důsledky. Příběh, který v místnosti zněl dobře, na papíře působí chatrně, pokud v něm chybí rozhodnutí a výsledek, a stejný příběh vyprávěný dvakrát s odlišnými detaily ve dvou kolech se hned projeví při porovnání poznámek.

Dalším zdrojem obtížnosti je, že behaviorální laťka platí i v technických kolech. Kandidát, který úlohu z kódování vyřeší čistě, ale neumí popsat okamžik, kdy nesouhlasil s manažerem, propadl v součásti, kterou by čistě technický pohovor nikdy nezměřil.

Bar Raiser je tazatel mimo náborový tým, vyškolený pro tuto roli, jehož úkolem je posoudit, zda zvyšujete průměr lidí, kteří už na dané úrovni jsou. Neposuzuje, zda tým tento kvartál potřebuje další osobu, a může zablokovat nábor, který chce náborový manažer.

V praxi to znamená, že osoba rozhodující o vašem výsledku nemá žádný zájem na obsazení místa. Naléhavost vám nepomůže, stejně jako dobrý vztah s manažerem. Pomáhá důkaz, který obstojí poté, co je zapsán a přečten někým, kdo vás nikdy nepotkal.

Obvykle nepoznáte, který tazatel to je, a na tom nezáleží. Odpovídejte v každém kole tak, jako by si to později přečetl cizí člověk, protože přesně to se stane.

Rozdělte si práci na dvě části. Technická polovina je ta známá: datové struktury, algoritmy a pro střední úroveň a výše návrh systémů. Většina kandidátů, kteří neuspějí, neuspěje právě zde.

Behaviorální polovina vyžaduje osm až dvanáct příběhů rozprostřených napříč Leadership Principles, každý se situací, tím, co jste osobně rozhodli, a měřitelným výsledkem. Jeden projekt může poskytnout dva nebo tři příběhy z různých úhlů. Výsledek zapište jako číslo, kdekoli existuje, protože doplňující otázka obvykle žádá přesně o to.

Pak si je nahlas nacvičte. Back-endová inženýrka s devítiletou praxí měla vynikající poznámky, a přesto se při první zkušební zkoušce zadrhla, protože číst příběh a vyprávět ho pod doplňující otázkou jsou různé dovednosti. Dva týdny mluvené praxe na /mock-interview změnily podání víc než další měsíc čtení. Přehled procesu krok za krokem najdete na /answers/topic/company-interviews.

Za většinu z toho mohou čtyři vzorce a žádný z nich se netýká inteligence.

• Příběhy bez rozhodnutí. Popis toho, co udělal tým, místo toho, co jste zvolili vy. Poznámky pak neobsahují žádný důkaz spojený s vaším jménem.
• Žádný výsledek. Příběh, který končí dodáním projektu, bez zmínky, zda fungoval.
• Docházející materiál. Opakované použití stejného projektu ve čtyřech kolech, což je na debriefingu vidět, i když si toho žádný jednotlivý tazatel nevšimne.
• Tiché řešení problémů. Řešení úlohy z kódování bez slovního vysvětlení úvahy, takže tazatel nemá co zapsat.

Stojí za to i jasně říct, že schopní inženýři jsou zde odmítáni z důvodů, které s jejich schopnostmi nemají nic společného, včetně souladu s týmem a složení panelu daného dne. Příprava mění šance; nerozhoduje o nich s jistotou, a odmítnutí není rozsudkem nad vaší schopností.