L'entretien de code chez Meta : format, éditeur partagé et entraînement

Le rythme est le même pour l'entretien téléphonique et les tours onsite chez Meta : de brèves présentations, un énoncé collé dans un éditeur partagé, et le chronomètre démarre en pratique. Vous clarifiez les contraintes, expliquez une approche, écrivez du code en verbalisant, et exécutez le tout à la main sur des cas de test. Avec deux exercices dans une même session, un candidat solide boucle le premier en moins de vingt minutes pour laisser une vraie marge au second.

Les éditeurs sont volontairement dépouillés : souvent sans exécution, sans autocomplétion, avec une coloration syntaxique minimale. Ce n'est pas de la radinerie : ce qui est noté, c'est votre raisonnement, et un bouton d'exécution brouillerait la question de savoir quel raisonnement a produit le correctif. Attendez-vous à être votre propre interpréteur, en parcourant les indices et les cas limites à voix haute.

La place de ces entretiens dans le processus complet de Meta est détaillée sur le guide des processus d'entretien par entreprise.

La peur, ici, c'est généralement le silence : ce qui se passe dans les notes du recruteur pendant que vous réfléchissez. La réponse honnête, c'est que ces notes suivent des signaux, et que le silence les prive de matière. La justesse et la vitesse ne sont que la moitié visible. L'autre moitié, c'est la communication : avez-vous cadré le problème avant de coder, avez-vous formulé le compromis qui a guidé votre approche, et avez-vous testé votre propre code sans qu'on vous le demande.

C'est pourquoi s'entraîner en verbalisant vaut mieux que bachoter en silence. Un candidat qui résout un peu moins de problèmes, mais qui pense à voix haute, nomme la complexité, et se corrige lui-même, produit un profil de signaux plus complet qu'un candidat silencieux. Les propres conseils de préparation de Meta le disent d'ailleurs : ce format est conçu pour récompenser un raisonnement visible.

L'outil d'entretien simulé propose des sessions chronométrées, avec deux exercices, où l'on verbalise en direct : c'est la répétition la plus proche du véritable éditeur partagé.

La préparation de dernière ligne droite porte sur la fidélité au format, pas sur de nouvelles théories. Résolvez les exercices dans un éditeur simple, coloration syntaxique désactivée ou minimale, dites chaque solution à voix haute même seul, et limitez les sessions à quarante-cinq minutes avec deux exercices pour rendre cette densité normale. Réhabituez-vous à suivre le code à la main, car l'éditeur ne l'exécutera pas pour vous.

Une ingénieure infrastructure à dix jours de son onsite est un cas typique. Elle a passé ses soirées sur des paires d'exercices chronométrées, s'est enregistrée pour repérer ses silences, et a consacré son dernier week-end à une simulation complète d'un onsite entier. Le jour J, l'éditeur, le rythme et la verbalisation lui étaient déjà familiers, si bien que son attention est allée entièrement aux exercices ; la transcription sur sa propre machine se contentait de garder les contraintes du recruteur bien en vue pendant qu'elle travaillait.

Des limites honnêtes s'appliquent toujours : un éditeur partagé en direct est une surface visible des deux côtés, les tours enregistrés ou surveillés sont hors du périmètre de tout outil d'assistance, et un minutage aussi serré signifie que seule votre aisance personnelle peut vraiment faire la différence. Ces limites sont réunies sur la page détectabilité.