Quanto È Difficile il Colloquio Amazon?

Se ti sei allenato su problemi di algoritmi e ti senti comunque impreparato, l'istinto è giusto. Questa sezione spiega di cosa è fatta la difficoltà in più, perché non sono i problemi, e allenarsi su altri non risolve il problema.

Amazon segue un percorso strutturato. Agli intervistatori vengono assegnati specifici Leadership Principles da sondare, prendono appunti dettagliati durante la conversazione, e quegli appunti vengono confrontati in un debrief successivo. Ne derivano due conseguenze. Una storia che in sala sembrava convincente risulta debole sulla carta se non ha una decisione e un risultato, e la stessa storia raccontata due volte con dettagli diversi in due round emerge subito quando gli appunti vengono confrontati.

L'altra fonte di difficoltà è che la soglia comportamentale si applica anche nei round tecnici. Un candidato che risolve bene il problema di coding ma non sa descrivere un momento in cui era in disaccordo con un manager ha fallito una componente che un colloquio puramente tecnico non avrebbe mai misurato.

Il Bar Raiser è un intervistatore esterno al team che assume, formato per questo ruolo, il cui compito è giudicare se alzi la media delle persone già a quel livello. Non valuta se il team ha bisogno di una persona in più questo trimestre, e può bloccare un'assunzione voluta dal hiring manager.

In pratica questo significa che chi decide il tuo esito non ha alcun interesse a coprire quella posizione. L'urgenza non ti aiuta, e nemmeno il feeling con il manager. Ciò che aiuta è una prova che regge dopo essere stata messa per iscritto e letta da qualcuno che non ti ha mai incontrato.

Di solito non puoi sapere quale intervistatore sia, e non importa. Rispondi a ogni round come se venisse letto in seguito da uno sconosciuto, perché è proprio così.

Dividi il lavoro in due. La metà tecnica è quella familiare: strutture dati, algoritmi e, dal livello intermedio in su, system design. La maggior parte dei candidati che fallisce non fallisce qui.

La metà comportamentale richiede da otto a dodici storie distribuite sui Leadership Principles, ciascuna con la situazione, cosa hai deciso personalmente e il risultato misurabile. Un solo progetto può fornire due o tre storie da angolazioni diverse. Scrivi il risultato come numero ovunque ne esista uno, perché la domanda di approfondimento di solito chiede esattamente quello.

Poi provale ad alta voce. Un'ingegnera back-end con nove anni di esperienza aveva scritto ottimi appunti ma si è comunque bloccata nella prima prova, perché leggere una storia e raccontarla sotto una domanda di approfondimento sono competenze diverse. Due settimane di pratica orale su /mock-interview hanno cambiato l'esposizione più di un altro mese di lettura. Il quadro passo per passo del percorso stesso è su /answers/topic/company-interviews.

Quattro schemi spiegano la maggior parte dei casi, e nessuno riguarda l'intelligenza.

• Storie senza decisione. Descrivere cosa ha fatto un team invece di cosa hai scelto tu. Gli appunti finiscono senza prove collegate al tuo nome.
• Nessun risultato. Una storia che finisce quando il progetto è stato consegnato, senza dire se ha funzionato.
• Finire il materiale. Riutilizzare lo stesso progetto in quattro round, cosa che il debrief nota anche se nessun singolo intervistatore se ne accorge.
• Risolvere i problemi in silenzio. Affrontare una domanda di coding senza narrare il ragionamento, lasciando all'intervistatore nulla da scrivere.

Vale anche la pena dire chiaramente che ingegneri capaci vengono qui rifiutati per motivi che non hanno nulla a che fare con la capacità, tra cui il fit con il team e la composizione del panel quel giorno. La preparazione sposta le probabilità; non le determina, e un rifiuto non è un giudizio sulle tue capacità.