Comment Préparer un Entretien Technique en 2026

L’écran était partagé. Le chrono tournait. Et moi, je fixais un éditeur vide avec les mains moites sur le clavier, comme si j’avais oublié comment taper.

“Inversez un arbre binaire,” le gars avait dit. Calmement. Comme on demande l’heure.

Je savais le faire. Je l’avais littéralement fait deux jours avant, tranquille, chez moi, avec du café et Spotify en fond. Mais là, avec un inconnu qui me regarde, un chrono dans le coin de l’écran, et ce silence — mon cerveau a décidé que c’était le bon moment pour faire la grève. J’ai tapé class TreeNode. J’ai effacé. J’ai retapé. J’ai re-effacé. Pendant huit minutes.

J’ai pas eu le poste. Évidemment.

C’était il y a six ans. Depuis, j’ai passé une quinzaine d’entretiens côté candidat, et j’en ai fait passer facilement cinquante ou soixante côté évaluateur. Et le truc que j’ai compris — trop tard, comme d’habitude — c’est que la préparation à un entretien technique, c’est un skill à part entière. Ça a presque rien à voir avec être bon au quotidien.

J’aurais aimé que quelqu’un me secoue et me dise ça à l’époque.

Avant de réviser quoi que ce soit

Mon pote Marc, l’année dernière. Je le vois arriver un lundi avec des cernes. “J’ai grindé de la programmation dynamique tout le weekend,” il me dit, fier de lui. Problèmes de sac à dos, sous-séquences, le grand jeu. Trois semaines qu’il faisait ça.

Son entretien ? Un take-home de quatre heures et du pair programming sur leur codebase React.

Il a regardé dans le vide pendant cinq bonnes secondes quand je lui ai demandé comment ça s’était passé.

Trois semaines de DP. Pour du pair programming en React. Je lui en reparle encore. Il aime pas ça.

Va sur Glassdoor. Check Blind. Regarde le blog engineering de la boîte. Certaines entreprises décrivent carrément leur process sur la page Careers. Trente minutes, c’est tout. Trente minutes pour éviter de finir comme Marc.

Ce que tu vas croiser en 2026 :

• Coding en direct — toi, un éditeur partagé, un problème, 30-45 min. Le format qui refuse de mourir.
• Take-home — “ça prend 3-4h.” Non. Prévois le double.
• System design — surtout si t’as 4+ ans. Moins sur ce que tu sais, plus sur comment tu raisonnes.
• Pair programming sur du vrai code — les startups adorent. Proche du vrai boulot, ce qui le rend bizarrement déstabilisant.
• Comportemental — le round que tout le monde zappe et qui élimine dans l’ombre.

Bref. La liste est pas révolutionnaire. Mais au moins maintenant c’est posé.

Le plan (5 semaines, à la louche)

Cinq semaines, une à deux heures par jour. Si t’as moins de dispo, étale sur sept. L’important c’est de pas décrocher en cours de route. La régularité bat tout le reste.

Semaine 1 : l’état des lieux qui fait mal.

Je me souviens de la première fois où j’ai fait ça honnêtement. Cinq problèmes variés, sans aide, sans timer. Juste moi et l’éditeur. Un problème d’arbre que j’aurais résolu au bureau en dix minutes m’a pris quarante-cinq. J’ai senti mon estomac se serrer à chaque minute qui passait.

C’est exactement cette sensation qu’il faut chercher. C’est ton cerveau qui te dit “ici, tu sais pas.” Note-le. C’est là-dessus que tu bosses, uniquement. Si les arbres c’est bon mais la DP te paralyse, lâche les arbres.

En vrai, au début j’ai pas fait ça. Je révisais ce que je savais déjà parce que ça me rassurait. Genre revoir les traversals d’arbres pour la troisième fois. C’est de la procrastination déguisée en révision. Je m’en suis rendu compte au bout de deux semaines. Deux semaines perdues.

Deux problèmes par jour. Lis l’éditorial après, même quand t’as trouvé.

Semaines 2-3 : le moment où ça clique (ou pas).

Y’a un instant — et je peux pas te dire quand il arrive parce que c’est différent pour tout le monde — où tu arrêtes de voir des problèmes individuels et tu commences à voir des formes. “Ah, ça sent la fenêtre glissante.” “Attend, c’est juste un BFS avec un truc en plus.” Ce moment-là, c’est tout l’objectif de ces deux semaines.

Fenêtre glissante, deux pointeurs, BFS/DFS, binary search on answer, templates de DP. Cinq à huit problèmes par pattern, difficulté croissante.

Tiens un petit log. Deux phrases après chaque problème : ce que t’as raté, pourquoi. Le mien s’appelait notes-entretien.md. Très original, je sais.

Ça prend deux minutes. L’effet sur ta rétention est complètement disproportionné.

Semaine 4 : system design et le round que personne prépare.

System design : apprends les briques de base. Load balancers, cache, queues de messages, SQL vs NoSQL. Puis entraîne-toi sur trois systèmes. URL shortener. Chat. Fil d’actualité. Le piège c’est de réciter une archi apprise par coeur. L’évaluateur va challenger chaque choix pour voir si tu comprends pourquoi.

Comportemental : cinq histoires, format STAR. Un problème technique dur. Un conflit. Un échec. Un projet que t’as porté. Sois honnête. Un échec bien raconté impressionne toujours plus qu’une histoire de héros où tout se passe bien.

Petite parenthèse. Je pensais que le comportemental c’était du remplissage. Et puis j’ai vu trois ingénieurs solides se faire recaler uniquement là-dessus. Trois. Des gens qui avaient cartonné le coding. Éliminés parce qu’ils racontaient leurs projets comme une liste de courses. Ça m’a fait changer d’avis vite fait. Fin de la parenthèse.

Semaine 5 : tu arrêtes de réviser et tu joues le match.

Cette semaine vaut plus que les quatre précédentes. Sérieusement.

Deux ou trois mock interviews. Avec un vrai humain. Quelqu’un qui va te couper, te demander “et la complexité ?”, et rester silencieux pendant que tu galères. Pas un chatbot.

Et tu parles. Tout le temps. “Bon, là je me dis qu’un hashmap pourrait marcher, mais le problème c’est l’espace…” Dis-le. Même si la pensée est pas finie. Surtout si la pensée est pas finie.

Là où ça casse (je l’ai vu de l’intérieur)

Scène que j’ai vécue probablement trente fois côté évaluateur :

Un candidat reçoit le problème. Il lit. Il hoche la tête. Et puis… rien. Cinq minutes. Huit minutes. Le curseur bouge un peu. Il réfléchit — probablement correctement. Mais moi, de l’autre côté, je vois un écran qui se remplit lentement et un visage concentré. Je sais rien de son raisonnement. Et quand le temps est écoulé, je peux pas lui donner de points pour une réflexion que j’ai jamais entendue.

J’ai recalé des gens comme ça. Des gens que je soupçonnais d’être compétents. Ça m’embêtait. Mais quand t’as rien à évaluer…

L’autre tueur, c’est d’abandonner après cinq minutes. Tu check la solution, tu te dis “ah oui c’est logique”, et t’as rien appris. Le vrai apprentissage commence après vingt minutes de galère, quand t’as envie de jeter ton clavier par la fenêtre. C’est inconfortable. C’est le but.

Et le troisième : foncer sur les problèmes “hard” en sautant les mediums. L’ego. Je l’ai fait. Et puis un medium avec un twist m’a bloqué en entretien réel. Leçon apprise.

Les trucs qu’on me demande toujours

Combien de temps ça prend ? Ça dépend d’où tu pars. Si tu résous des problèmes régulièrement, quatre semaines. Si t’as pas touché un algo depuis la fac, six à huit. La régularité. Toujours la régularité. Une heure par jour bat huit heures un dimanche.

Pour le langage, utilise celui que tu maîtrises le mieux. Python est populaire en entretien, mais personne va te recaler parce que tu codes en Java. Par contre, connais la lib standard. Rien de plus frustrant que de perdre cinq minutes à chercher comment trier un dictionnaire. C’est bête mais ça m’est arrivé.

“Je bloque pendant l’entretien, je fais quoi ?” Tu verbalises. “Là, je suis bloqué, voilà ce que j’ai essayé.” Un candidat qui communique à 70% de la solution impressionne plus qu’un candidat muet à 100%.

Et non, les entretiens c’est pas pareil partout. Grosses boîtes = algo + system design. Startups = take-homes, pair programming. Certaines autorisent l’IA maintenant — mais elles évaluent comment tu la pilotes, pas si tu sais copier-coller.

J’aurais pu mieux organiser cette section. Tant pis, on fait avec.

Prêt à t’y mettre ? Rejoindre l’accès anticipé →