Questions d'entretien Google pour software engineers

La boucle d'entretien de Google est le processus le mieux documenté du domaine public dans la tech. Algorithmes d'abord, grille structurée, revue par un hiring committee, et une étape de team match séparée qui peut étirer le processus à deux mois. Ce guide décompose ce que chaque tour teste réellement, les patterns de questions que vous verrez et où la plupart des candidats perdent des points — d'après les patterns publics de Glassdoor, les valeurs publiées par Google et le framework du Hiring Committee décrit par Laszlo Bock dans Work Rules.

Le processus d'entretien Google

Les boucles SWE standard ont cinq phases. Phase 1 : screen recruteur (30 minutes, parcours de base, ancrage salarial). Phase 2 : phone screen (45 minutes avec un ingénieur, une question de coding sur un doc partagé — pas d'IDE, pas d'autocomplétion). Phase 3 : onsite (4-5 tours : deux coding, un system design à partir de L4, un Googleyness/comportemental, éventuellement un deep-dive de domaine). Phase 4 : hiring committee (un groupe distinct d'ingénieurs examine les dossiers, personne dans ce comité ne vous a interviewé). Phase 5 : team match (vous passez la boucle dans un pool de candidats, les équipes vous choisissent pour leur effectif ouvert).

Calendrier total : 6 à 10 semaines si tout se déroule sans accroc. Le team match est l'étape imprévisible — de forts candidats ont attendu plus de 6 semaines qu'une équipe les réclame, surtout pendant les gels d'embauche ou dans les orgs moins populaires. Si vous avez une recommandation vers une équipe précise, demandez au recruteur d'accélérer le team match sous condition.

Top 10 des questions techniques à préparer

Voici les patterns de questions auxquels les interviewers Google puisent de façon fiable, d'après les rapports Glassdoor de ces dernières années. La formulation exacte différera ; reconnaissez la forme.

1. Two-pointer sur un tableau trié — trouver des paires, des triplets, la somme la plus proche. Conseil : répétez le moment pivot où vous basculez entre expansion et contraction.
2. Sliding window avec fréquence de caractères — plus longue sous-chaîne avec au plus K caractères distincts, fenêtre minimale. Conseil : un hashmap + deux pointeurs résout 90 % de ces cas.
3. Parcours d'arbre avec état — somme maximale de chemin dans un arbre binaire, variantes du plus petit ancêtre commun. Conseil : récursion post-order où vous renvoyez à la fois une réponse et une contribution au parent.
4. BFS de graphe avec contraintes — word ladder, plus court chemin dans une grille avec obstacles ou limites de carburant. Conseil : l'état dans votre set de visités doit inclure toutes les dimensions de contrainte, pas seulement la position.
5. Programmation dynamique sur intervalles ou grilles — distance d'édition, matching regex, chemins dans une grille. Conseil : définissez l'état en clair avant d'écrire la récurrence.
6. Backtracking avec élagage — N-queens, Sudoku, permutations avec contraintes. Conseil : élaguer tôt est ce qui sépare une réponse qui marche d'une réponse en timeout.
7. Concevoir une structure de données — cache LRU, store clé/valeur borné dans le temps, autocomplétion avec trie. Conseil : clarifiez l'API avant d'implémenter ; demandez quelles opérations doivent être O(1) ou O(log n).
8. Ordonnancement avec heap / priority queue — meeting rooms II, top K éléments dans un flux, fusion de K listes triées. Conseil : un max-heap de taille fixe K est la bonne réponse à la moitié des problèmes de streaming.
9. Parsing de chaîne sous pression — calculatrice de base, nombre valide, décodage de chaîne. Conseil : une pile explicite bat une regex tordue à chaque fois en entretien.
10. Cas limite de manipulation de bits — variantes du single number, comptage de bits, nombre manquant avec XOR. Conseil : répétez les identités XOR jusqu'à ce qu'elles soient réflexes.

Top 5 des sujets de system design (L4 et au-dessus)

1. Store clé-valeur distribué / cache — partitionnement, réplication, compromis de cohérence, gestion des hot keys. Entraînez-vous aux patterns Dynamo et Bigtable.
2. News feed ou timeline classée — fanout-on-write ou fanout-on-read, signaux de ranking, compromis fraîcheur ou personnalisation.
3. Raccourcisseur d'URL à l'échelle de Google — stratégies de génération d'ID, latence de redirection, détection d'abus.
4. Web crawler — politesse, déduplication, priorisation de la frontière d'URL, coordination distribuée.
5. Pipeline d'analytics temps réel — ingestion d'événements, agrégation fenêtrée, données en retard, sémantique exactly-once.

Pour chacun, arrivez avec : un modèle de clarification du problème en 60 secondes, un calcul de capacité au dos de l'enveloppe (QPS, stockage, bande passante), un schéma d'architecture de base en tête, et 2-3 compromis précis à faire émerger quand l'interviewer pousse. Le premier mode d'échec est de sauter au schéma avant de demander quelle échelle compte.

Top 5 des questions comportementales (tour Googleyness)

1. Racontez-moi une fois où vous avez été en désaccord avec un coéquipier. Ils cherchent l'humilité intellectuelle, pas le fait de gagner le désaccord.
2. Décrivez un projet qui a échoué et ce que vous en avez appris. Assumer l'échec proprement est le test — les réponses vagues signalent un report de la faute.
3. Racontez-moi une fois où vous avez dû apprendre quelque chose de nouveau sous pression. L'aisance avec l'ambiguïté est un signal Googleyness central.
4. Décrivez une décision technique que vous regrettez. La conscience de soi, pas la perfection. Les candidats seniors incapables de nommer un regret semblent peu réflexifs.
5. Comment gérez-vous le fait de vous voir assigner un travail hors de votre domaine d'expertise ? Bias for action et curiosité, avec des étapes et des résultats concrets.

Conseils propres à la culture de Google

Les interviewers Google notent selon une grille publique. La grille pondère le processus de résolution de problème aussi lourdement que la réponse finale. Cela signifie que penser à voix haute n'est pas optionnel — les résolveurs silencieux sont pénalisés même s'ils atteignent la bonne réponse. Verbalisez : énoncez vos hypothèses, nommez votre choix de structure de données, expliquez pourquoi vous avez rejeté l'alternative, puis codez. Quand vous bloquez, dites-le à voix haute et décrivez ce que vous tentez. Les interviewers peuvent indiquer une piste dans le cadre de la grille, mais seulement s'ils comprennent où vous en êtes.

Le hiring committee ne vous a jamais rencontré. Votre interviewer rédige un dossier lu comme une pièce de procédure — citations directes, jalons horodatés, décisions signal/no-signal. Le biais du comité est de rejeter en cas d'incertitude. Votre travail à chaque tour est de donner à votre interviewer assez de preuves concrètes pour écrire un dossier confiant. Les esquives vagues n'aident personne.

Un mode d'échec précis : les candidats sur-optimisent. N'écrivez pas prématurément une solution hashmap quand le brute-force suffit pour clarifier. Déroulez le brute-force, nommez sa complexité à voix haute, puis optimisez. Sauter l'étape brute-force donne l'impression que vous avez « reconnu et ressorti une solution apprise par cœur », ce qui constitue un signal d'alarme à partir de L5.

Questions fréquentes