Perché non riesco a passare la mia intervista telefonica con Google?

Spesso, quando non conosco la risposta completa alla domanda, faccio qualche ricerca e raccolgo pensieri interessanti da persone che hanno più o meno risposto alla tua domanda e li metto insieme in una forma che ha senso e risponde alla tua domanda. (Il plagio è rubare da una fonte, la ricerca è rubare da molte). Quindi ecco alcuni spunti su ciò che accade durante un'intervista telefonica con Google. E' concreto e schietto, ma si esce dall'articolo vedendo cosa sta succedendo e cosa si deve fare per migliorare. Spero che questo aiuti, e buona fortuna!

Round 1: un reclutatore ti chiama. Vi faranno alcune semplici domande. Cose come "cosa è più veloce, quicksort o bubblesort". Se rispondi correttamente a un numero sufficiente di queste domande, passi al turno successivo. Se fallite qui: smettete di lamentarvi, andate via e andate a migliorarvi, non c'è modo in cui avreste comunque superato le fasi successive.

Round 2: un ingegnere vi chiamerà, e vi intervisterà per 45 minuti. Solo i "migliori" intervistatori arrivano a fare quello che noi chiamiamo "primi schermi telefonici" perché è lì che la maggior parte delle persone viene buttata fuori. Dal punto di vista dell'intervistatore, questo è il peggiore in assoluto. Circa 1/10 dei candidati passano questo passo, perché la maggior parte dei candidati (anche con master ed esperienza pluriennale) sono completamente incompetenti.

Non posso dirvi cosa succederà esattamente durante questa intervista, perché persone diverse hanno stili diversi, ma da quello che ho visto si riduce a due approcci principali:

- L'approccio "coprire più terreno possibile". L'intervistatore vi farà 5-10 domande diverse distribuite nelle vostre aree di competenza. Io uso questo approccio per le persone che stanno facendo domanda per lavori di sysadmin o di ingegneria dei sistemi. Per esempio, una domanda sul networking, una domanda su unix, un piccolo problema di codifica, qualcosa sulla sicurezza e qualcosa sul web.

- L'approccio "un problema difficile". Lo uso per gli ingegneri del software, ai quali chiedo sempre di scrivere codice. Vuoi essere pagato per scrivere codice, quindi è meglio che tu lo sappia fare. In realtà, di solito lo divido in due domande: un facile "riscaldamento" seguito da una domanda "vera".

Per darvi un'idea, una domanda di riscaldamento potrebbe essere qualcosa come "invertire una stringa in posizione" o "implementare atoi" o qualcosa del genere. Un ingegnere bravo e capace dovrebbe essere in grado di risolverla in circa 5 minuti. Purtroppo, solo una minoranza delle persone che intervisto supera questa domanda di riscaldamento nei 45 minuti assegnati.

Se un intervistatore inizia con una domanda tecnica, e poi passa a "il tuo progetto più interessante" o "il bug più complicato che hai mai risolto", questo significa una delle due cose:

a) Improbabile: Sei così fantastico che hai esaurito le domande dell'intervistatore. Questo succede, ma molto raramente. b) Più probabilmente, sei un tale imbranato che l'intervistatore preferirebbe accoltellarsi piuttosto che sentirti fallire di nuovo. Così ti lascia raccontare una storia mentre lui si addormenta. Nella sua valutazione, ti darà il punteggio più basso possibile, e questo porrà fine al processo di intervista per te.

Ora supponendo che tu abbia superato la domanda di riscaldamento, che tu - congratulazioni! - fate parte dell'elite che sa come scrivere una funzione ricorsiva, o come dividere una stringa per virgole - allora arriviamo alla "vera" domanda. Di solito li scelgo in modo che riescano a malapena a finirlo nei restanti 35 minuti.

Gli esempi potrebbero includere:

- rimuovere i duplicati da una lista di stringhe che è più grande della memoria disponibile (cioè con ricariche da disco)

- contare il numero di oggetti disgiunti in una bitmap

- implementare un programma che gioca a tic-tac-toe

Sono tutti piuttosto difficili da fare in 35 minuti. La maggior parte delle persone non ci riesce, e non è necessariamente un fallimento se non si arriva al 100%.

Dopo l'intervista, scriviamo un rapporto sull'intervista, che include un punteggio. A proposito, non chiedete come siete andati, non ve lo diranno. Non ci è permesso perché la gente potrebbe farci causa. Quel rapporto va al reclutatore, che poi deciderà se proseguire. Se sì:

Round 3: esattamente lo stesso del round 2, ma con un ingegnere diverso. Se si passa di nuovo: interviste in loco!

Vi facciamo volare in uno dei nostri uffici, dove avrete 3 interviste di 45 minuti, il pranzo, e altre 2 interviste. Questi sono fondamentalmente gli stessi schermi telefonici, ma si arriva a vedere gli intervistatori faccia a faccia.

Se fai completamente schifo, a volte ti accompagnano fuori dopo pranzo, e saltano le ultime due interviste.

Altrimenti: il feedback raccolto va a un comitato di ingegneri senior che guardano il feedback che è stato raccolto da te in 7 ore estenuanti. Lo guardano per 3-5 minuti e decidono se siete assunti o meno.

Se decidono di assumervi, il selezionatore vi chiamerà e vi farà un'offerta. Probabilmente dirai di sì, perché paghiamo molto, molto, molto bene.

Un paio di consigli:

- Questo è probabilmente il consiglio più importante, quindi lo metto per primo: se ti chiediamo di scrivere un programma, NON iniziare subito a scrivere codice. Pensate prima al problema, e DITE ad alta voce cosa state per fare, poi fatelo. Se state andando completamente nella direzione sbagliata, ve lo diremo, e non sprecherete 20 minuti per andarci.

- I reclutatori sono dei completi idioti e probabilmente vi dimenticheranno da qualche parte nel mezzo del processo. Non siate timidi a chiamare il vostro reclutatore se non li sentite dopo (diciamo) una settimana.

- Fate domande se qualcosa non è chiaro durante un colloquio. Vogliamo vedervi al meglio. Se non sei sicuro di cosa sia una domanda, o di cosa intendiamo, chiedi immediatamente - stai giocando contro il tempo. Sì, alcuni di noi cronometrano il tempo che impiegate per una risposta.

- Rendete il vostro CV/Resume breve e dolce. Li guardiamo, ma solo se sono brevi. A meno che tu non sia un professore del MIT, due pagine. Non tre. Due. Metti le tue abilità sul tuo CV/Resume. Ti chiediamo in cosa sei più bravo. Se elenchi ciò che sai fare meglio, ti chiederemo di quello. Se il tuo CV/Resume dice "maestro di algoritmi", aspettati domande sugli algoritmi. Se non è ovvio dal tuo CV/Resume in cosa sei bravo, ti chiederemo quello che ci pare.

- Non mettere la tua esperienza al liceo, nella banda musicale o nelle girl scout sul tuo CV/Resume. A nessuno frega un cazzo e non vi aiuterà. È più probabile che vi danneggi perché vi distrarrà dalle parti che contano.

- Quando vi viene posta una domanda di codifica, non fate i cazzoni pretenziosi e iniziate a scrivere header include, blaterate di "invarianti" o "buone pratiche di programmazione" se non sapete come risolvere il problema. Va benissimo essere un cazzone pretenzioso se si può risolvere il problema con facilità, ma non se non si può.