Pourquoi les Bons Ingénieurs Échouent aux Entretiens Techniques

Tu fais tourner des systèmes en prod depuis des années. T’es le pompier qu’on appelle le vendredi soir quand tout crame. Tes PRs passent en revue sans accroc, ton archi tient la route.

Et pourtant, ton dernier entretien technique ? Raté.

Le truc c’est que t’es pas seul. Loin de là. Et non — c’est pas un problème de compétence.

Le format est cassé, pas toi

Voilà un truc que peu de gens admettent ouvertement : les entretiens techniques mesurent ta capacité à passer des entretiens. Pas grand-chose d’autre.

Au boulot, tu navigues dans une codebase que tu connais par coeur. T’as du contexte, des collègues, le droit de googler, un debugger. En entretien ? Problème inconnu, 40 minutes, quelqu’un qui te fixe pendant que tu tapes sur un éditeur sans autocomplétion. Pas de git log, pas de Copilot, rien.

C’est un peu comme juger un chirurgien sur sa capacité à opérer… debout dans un bus. Les contraintes n’ont rien à voir avec la réalité du métier.

Franchement, je trouve qu’on devrait arrêter de faire semblant que ce format évalue correctement les gens. Mais bon — c’est le jeu, et il faut savoir y jouer.

Tes muscles algo ont fondu (et c’est normal)

Soyons honnêtes une seconde. La dernière fois que t’as implémenté un BFS à la main, sans librairie, c’était quand ? Pendant tes études, probablement.

Et c’est tout à fait logique. Au quotidien, les frameworks font l’algorithmique pour toi. Tu vas pas recoder un tri fusion quand Array.sort() existe. Le problème, c’est qu’en entretien on te demande exactement ça — le truc que t’as pas fait depuis cinq ans.

La bonne nouvelle ? T’as pas besoin de tout reprendre de zéro. Une dizaine de patterns couvrent la grande majorité des questions : sliding window, two pointers, BFS/DFS, un peu de programmation dynamique, binary search sur des cas vicieux. Reconnaître le pattern, c’est déjà 70 % du chemin. Le reste, c’est de la mécanique.

Parler en codant — le skill invisible

Celui-là, il est traître.

T’as l’habitude de bosser seul. En silence. Avec ta musique, ton terminal, tes pensées qui fusent sans que t’aies besoin de les verbaliser. Normal, c’est comme ça qu’on est productif.

Sauf qu’en entretien, le silence te tue. L’évaluateur voit un écran qui bouge et aucune idée de ce qui se passe dans ta tête. Résultat ? “Le candidat n’a pas démontré sa capacité de raisonnement.” Alors que le raisonnement était là — juste pas visible.

J’ai vu des seniors brillants se faire recaler pour ça. Des gens qui avaient la bonne solution, hein. Mais qui l’ont codée sans un mot.

Le remède est bête : entraîne-toi à résoudre des problèmes en expliquant chaque étape à voix haute. Oui, tu vas te sentir ridicule les premières fois. Après trois ou quatre sessions, ça coule tout seul. Et ça change tout dans le regard de l’évaluateur.

Le piège de l’élégance (ou pourquoi les juniors scorent parfois mieux)

Là, opinion un peu piquante : ton expérience joue contre toi sur la gestion du temps.

Un junior face à un problème ? Il balance une solution brute-force en cinq minutes, O(n²), pas jolie, mais fonctionnelle. Ensuite il optimise. Pendant ce temps, toi, tu cherches la solution élégante d’emblée. Tu veux la complexité optimale du premier coup parce que t’as ta fierté de dev senior. Et tu finis par manquer de temps.

La méthode qui marche — et je parle d’expérience — c’est de commencer moche. Brute-force en deux minutes. Décris l’approche naïve. Puis identifie le goulot, propose une optimisation, implémente la version améliorée. Même si t’atteins pas l’optimal, t’as montré ta progression de pensée. Et ça, c’est exactement ce qu’on veut voir de l’autre côté de la table.

Ta méthode de prépa en 4 semaines

Si t’es un dev confirmé qui reprend la prépa après des années en poste, voilà un plan réaliste.

Première semaine — le diagnostic. Fais 10 problèmes variés, chronomètre, verbalise tout. Le but c’est pas de performer. C’est d’identifier où tu galères : algo pur, gestion du temps, communication, stress ?

Deuxième semaine — combler les trous. Prends tes 3-4 patterns les plus faibles et creuse. Trois problèmes bien compris valent mieux que quinze survolés — je le pense sincèrement.

Troisième semaine — simulation réelle. Deux ou trois mock interviews avec des pairs ou sur une plateforme. System design inclus. Et le comportemental aussi — un “no hire” comportemental est éliminatoire dans pas mal de boîtes, même si personne en parle.

Quatrième semaine — consolidation. Révise tes notes, affine tes anecdotes STAR, fais une dernière simulation. Et repose-toi la veille. Sérieusement. Le sommeil fait plus que deux heures de LeetCode la nuit d’avant.

FAQ

Est-ce que rater un entretien technique veut dire que je suis un mauvais dev ?

Non. Point. Le taux de réussite dans les grosses boîtes tech tourne autour de 20-30 %. Des ingénieurs brillants se plantent, ajustent leur prépa et décrochent le poste quelques semaines plus tard. L’entretien mesure ta préparation au format, pas ta valeur en tant qu’ingénieur.

Combien de temps de prépa pour un dev expérimenté ?

Quatre semaines à raison d’une heure par jour, c’est un bon rythme. Si t’es pressé, deux semaines intenses peuvent suffire — mais honnêtement, c’est mieux d’étaler. Le cerveau a besoin de temps pour que les patterns s’ancrent.

Faut-il vraiment parler à voix haute pendant l’entretien ?

Oui. Sans hésiter. Un candidat qui communique avec une solution moyenne battra presque toujours un candidat silencieux avec du code parfait. L’évaluateur note ton raisonnement autant — voire plus — que ton résultat final.

Les entretiens de system design sont-ils différents pour les seniors ?

Très. On attend de toi que tu poses les bonnes questions, que tu fasses des compromis explicites, que tu anticipes les problèmes de scaling. Là, ton expérience joue en ta faveur — à condition que tu structures ta réponse au lieu de partir dans tous les sens.

Prêt à reprendre le contrôle de ta prépa ? Rejoindre la communauté →