Come Google seleziona i Project Manager

Google pubblica una panoramica del proprio processo di assunzione e i candidati nell'ambito della gestione dei progetti seguono la stessa struttura prevista per tutti gli altri.

• Conversazioni con il recruiter. Una o due conversazioni più brevi, per telefono o video, valutano le competenze essenziali per il ruolo e forniscono informazioni sull'organizzazione e sul team. Prepara un resoconto breve e concreto dei progetti che hai portato a termine e dei cambiamenti che hai apportato personalmente.
• Un piccolo progetto, a seconda del ruolo. Google potrebbe chiederti di completare un piccolo progetto prima dei colloqui, che può spaziare da un caso di studio a esempi di scrittura o codice. Per un Project Manager, la forma più probabile è un caso scritto o un piano, anche se Google non specifica per quali ruoli sia previsto.
• Il panel di colloqui. Questa fase consiste in un panel di colloqui, in video o di persona, con un gruppo variabile di dipendenti di Google. Non sono previsti rompicapi.
• Decisione e offerta. Google riunisce la candidatura e i feedback dei colloqui, considera diversi punti di vista per prendere una decisione sull'assunzione e affida al recruiter la presentazione dell'offerta.

Google non indica quanti colloqui debba sostenere un Project Manager né quanto duri il processo. Screening, caso, colloquio comportamentale, presentazione e colloquio in sede sono categorie di preparazione usate in questa pagina, non i nomi delle fasi di Google.

Google utilizza colloqui strutturati: rubriche chiare, uguali per tutte le persone considerate per il ruolo, applicate a domande aperte e pertinenti alla posizione su come risolvi i problemi, come interagisci con un team e quali sono i tuoi punti di forza. Per un Project Manager è un invito diretto a mostrare il tuo metodo: il piano, l'ipotesi che si è rivelata errata, il compromesso che hai scelto e le persone che hai informato.

In generale, i colloqui per la gestione dei progetti valutano:

• Pianificazione e controllo dell'ambito. Suddividere il lavoro, definirne la sequenza e rifiutare estensioni dell'ambito senza compromettere il rapporto con lo stakeholder.
• Gestione dei rischi e degli stakeholder. Individuare tempestivamente i rischi, segnalare ai livelli superiori quelli giusti e mantenere le persone allineate quando il piano cambia.
• Delivery entro i vincoli. Che cosa hai eliminato, che cosa hai tutelato e come hai verificato la correttezza delle scelte.
• Comunicazione. Aggiornamenti di stato che un dirigente impegnato possa leggere in un minuto e che un ingegnere non trovi fuorvianti.

Gli strumenti di intelligenza artificiale non sono consentiti durante i colloqui di Google, quindi devi essere in grado di ragionare ad alta voce sul piano che descrivi.

Nelle grandi aziende tecnologiche, i ruoli di gestione dei progetti assumono diversi titoli; perciò la panoramica pubblicata del processo costituisce il punto di riferimento, mentre le caratteristiche del ruolo emergono dall'enfasi posta nelle domande aperte. Quanto segue descrive una prassi generale, non una dichiarazione di Google sui formati previsti per i diversi ruoli.

• Rispetto ai colloqui per Product Manager, aspettati meno domande su cosa realizzare e perché, e più domande su come portarlo a termine: dipendenze, tempistiche, rischi e conversazioni necessarie per mantenere tre team orientati nella stessa direzione.
• Rispetto ai colloqui per ruoli di ingegneria, non ci si aspetta che tu scriva codice su una lavagna, ma che comprenda il lavoro tecnico abbastanza da pianificarlo, stimarlo e riconoscere una stima troppo ottimistica.
• Rispetto ad altre aziende, gli elementi pubblicati più importanti sono la rubrica condivisa tra gli intervistatori, il panel variabile e l'assenza di rompicapi. La profondità e la coerenza dimostrate in diverse conversazioni contano più di un unico racconto impeccabile.

Google non pubblica una tempistica. Organizzati in base alle fasi: conversazioni con il recruiter, un possibile piccolo progetto, il panel e il periodo in cui i feedback provenienti da diversi punti di vista conducono a una decisione.

La difficoltà risiede nella concretezza. Le domande aperte sulla delivery invitano a dare risposte generiche, che una rubrica penalizza. Gli intervistatori che valutano tutti gli stessi criteri continueranno a chiederti che cosa hai fatto, quanto è costato e come hai verificato che funzionasse; i candidati preparati arrivano quindi con progetti che possono descrivere al livello delle singole decisioni, anziché limitarsi ai risultati.

Rispecchia la rubrica: risoluzione dei problemi, lavoro di squadra e punti di forza, ciascuno sostenuto da un progetto che sai analizzare nel dettaglio su richiesta.

• Tre esperienze di delivery. Un progetto svolto secondo i piani, uno che ha subito ritardi e uno di cui hai dovuto ridefinire l'ambito. Per ciascuno, conosci il registro dei rischi, i punti decisionali e i valori che hai monitorato.
• Un piano che sai presentare. Esercitati a illustrare in pochi minuti un piano che proceda dall'obiettivo alle tappe fondamentali e ai rischi, quindi a difenderlo quando ti vengono poste domande.
• Prove della gestione degli stakeholder. Un disaccordo tra team che hai risolto e uno che hai segnalato ai livelli superiori, spiegando il ragionamento seguito in entrambi i casi.
• Un possibile progetto prima del colloquio. Se Google richiede un caso o un esempio di scrittura, redigilo come il documento che invieresti davvero a uno sponsor.
• Esercitati a rispondere alle domande. Un colloquio simulato con SubcueAI ti permette di esercitarti ad alta voce con domande aperte sulla delivery prima del vero panel, durante il quale gli strumenti di intelligenza artificiale non sono consentiti.