Cât de Greu Este Interviul Amazon?

Dacă ai tot exersat probleme de algoritmi și tot te simți nepregătit, instinctul e corect. Această secțiune explică din ce e făcută dificultatea suplimentară, pentru că nu problemele sunt cauza, iar exersarea altora nu rezolvă asta.

Amazon derulează un proces structurat. Intervievatorilor li se atribuie anumite Leadership Principles de investigat, iau notițe detaliate în timpul discuției, iar acele notițe sunt comparate ulterior la un debrief. De aici decurg două consecințe. O poveste care a sunat bine în sală pare firavă pe hârtie dacă nu are o decizie și un rezultat, iar aceeași poveste spusă de două ori cu detalii diferite în două runde iese imediat la iveală când se compară notițele.

Cealaltă sursă de dificultate este că ștacheta comportamentală se aplică și în rundele tehnice. Un candidat care rezolvă curat problema de cod, dar nu poate descrie un moment în care nu a fost de acord cu un manager, a picat o componentă pe care un interviu pur tehnic nu ar fi măsurat-o niciodată.

Bar Raiser este un intervievator din afara echipei de angajare, instruit pentru acest rol, a cărui sarcină este să judece dacă ridici media celor deja la nivelul respectiv. Nu evaluează dacă echipa are nevoie de o persoană în trimestrul acesta și poate bloca o angajare dorită de hiring manager.

În practică, asta înseamnă că persoana care decide rezultatul tău nu are niciun interes să ocupe postul. Urgența nu te ajută, nici relația bună cu managerul. Ce ajută este o dovadă care rezistă odată scrisă și citită de cineva care nu te-a întâlnit niciodată.

De obicei nu poți ști care intervievator este, și nici nu contează. Răspunde la fiecare rundă ca și cum ar fi citită mai târziu de un străin, pentru că exact asta se întâmplă.

Împarte munca în două. Jumătatea tehnică este cea familiară: structuri de date, algoritmi și, de la nivel mediu în sus, design de sistem. Majoritatea candidaților care pică nu pică aici.

Jumătatea comportamentală necesită între opt și douăsprezece povești distribuite pe Leadership Principles, fiecare cu situația, ce ai decis personal și rezultatul măsurabil. Un singur proiect poate furniza două sau trei povești din unghiuri diferite. Notează rezultatul ca număr oriunde există unul, pentru că întrebarea de urmărire cere de obicei exact asta.

Apoi repetă-le cu voce tare. O inginer back-end cu nouă ani de experiență a scris notițe excelente și tot s-a blocat la primul exercițiu, pentru că a citi o poveste și a o spune sub o întrebare de urmărire sunt abilități diferite. Două săptămâni de exersat vorbit pe /mock-interview au schimbat livrarea mai mult decât încă o lună de citit. Imaginea etapă cu etapă a procesului în sine este la /answers/topic/company-interviews.

Patru tipare explică majoritatea cazurilor, și niciunul nu ține de inteligență.

• Povești fără decizie. Descrierea a ceea ce a făcut o echipă, nu a ceea ce ai ales tu. Notițele rămân fără nicio dovadă legată de numele tău.
• Fără rezultat. O poveste care se termină când proiectul a fost livrat, fără nimic despre dacă a funcționat.
• Rămâi fără material. Refolosirea aceluiași proiect în patru runde, lucru vizibil la debrief chiar dacă niciun intervievator singur nu l-a observat.
• Rezolvarea tăcută a problemelor. Parcurgerea unei întrebări de cod fără a-ți nara raționamentul, fără a lăsa intervievatorului nimic de notat.

Merită spus clar și că ingineri capabili sunt respinși aici din motive care nu au nimic de-a face cu capacitatea lor, inclusiv potrivirea cu echipa și componența panelului din acea zi. Pregătirea schimbă șansele; nu le decide, iar o respingere nu este un verdict asupra capacității tale.