Préparer un entretien technique de développeur : la méthode d'un recruteur

Nous menons des entretiens techniques toute l'année, côté recruteur. Et nous voyons la même chose se répéter : la plupart des candidats qui échouent n'échouent pas par manque de niveau. Ils échouent parce qu'ils préparent le mauvais examen — ils révisent des algorithmes quand on va leur parler d'architecture, ils récitent quand on attend qu'ils raisonnent à voix haute.

Ce guide est la préparation que nous ferions à votre place. Il existe d'ailleurs en version miroir côté recruteur : les questions qu'on vous posera y sont détaillées une par une — lisez les deux, vous saurez exactement ce qui vous attend.

Ce qu'un entretien technique évalue vraiment

Désamorçons le malentendu principal : l'entretien technique n'évalue pas si votre code est parfait. Un évaluateur expérimenté regarde quatre choses, dans cet ordre d'importance :

1. Le raisonnement — comment vous décomposez un problème que vous ne connaissez pas.
2. La communication — votre capacité à expliquer ce que vous faites pendant que vous le faites.
3. Les arbitrages — savez-vous dire « cette solution est plus simple mais ne tiendra pas la charge » ? Les trade-offs sont le marqueur le plus fiable de la séniorité.
4. L'honnêteté technique — ce que vous faites face à une question dont vous ignorez la réponse.

Le code exact, la syntaxe, le nom précis d'une méthode : tout cela pèse beaucoup moins que ces quatre signaux. Préparez-vous en conséquence.

Les quatre formats, et comment préparer chacun

Le live coding. Un exercice résolu en direct, sous observation. Ce qui est évalué n'est pas la vitesse mais la démarche : reformulez le problème avant d'écrire une ligne, annoncez votre approche, pensez à voix haute, testez votre solution vous-même à la fin. Préparation : des exercices chronométrés en conditions réelles — en parlant à voix haute, seul face à un écran, ce qui est plus inconfortable qu'on ne le croit et se travaille.

Le take-home. Un projet à rendre sous quelques jours. Le piège est inverse : personne ne vous regarde, donc tout se joue sur ce que vous rendez. Un README qui explique vos choix, des commits propres, des tests sur les cas critiques valent mieux qu'une fonctionnalité de plus. Et pendant l'entretien de restitution, attendez-vous à défendre chaque choix : c'est là que le take-home se gagne ou se perd.

Le system design. Concevoir une architecture au tableau — de plus en plus fréquent dès le niveau confirmé. Il n'y a pas de bonne réponse unique, il y a une bonne démarche : cadrer les besoins (volumétrie, latence, contraintes) avant de dessiner, partir simple, complexifier seulement quand une contrainte l'exige, et nommer les limites de votre propre design avant qu'on ne vous les fasse remarquer.

Les questions techniques conversationnelles. Le format le plus courant en France, souvent mené par un lead ou un CTO. Ça ressemble à une discussion, c'est une évaluation : chaque « et pourquoi ce choix ? » teste la profondeur derrière le mot-clé. La règle : ne mentionnez jamais une technologie dont vous ne pouvez pas soutenir trois questions de suite.

La préparation en sept jours

En une semaine, à raison d'une à deux heures par jour, vous couvrez l'essentiel :

• J-7 — Renseignement. Stack de l'entreprise, produit, process d'entretien (souvent public sur leur site ou leurs offres). Vous préparez un examen précis, pas un examen générique.
• J-6 — Votre propre parcours. Relisez vos deux derniers projets comme un examinateur : pourquoi ces choix, qu'est-ce qui a mal tourné, que referiez-vous autrement. C'est la matière de la moitié des questions.
• J-5 — Les fondamentaux de votre stack. Pas de la théorie exhaustive : les mécanismes que vous utilisez tous les jours sans plus savoir les expliquer. C'est exactement là que les questions frappent.
• J-4 — Exercice en conditions réelles n°1. Chronométré, à voix haute.
• J-3 — Le pitch et les questions classiques. « Présentez-vous » en deux minutes orientées vers le poste ; un échec technique et ce que vous en avez tiré ; pourquoi ce poste.
• J-2 — Exercice en conditions réelles n°2, sur le format attendu (live coding ou design selon ce que J-7 vous a appris).
• J-1 — Rien de nouveau. Relire ses notes, préparer la logistique, dormir. Réviser une notion nouvelle la veille produit de la confusion, pas de la maîtrise.

Face à une question dont vous ignorez la réponse

Ça arrivera — c'est même souvent volontaire : certains évaluateurs poussent jusqu'à la limite de vos connaissances précisément pour voir ce qui s'y passe. La méthode, en trois temps :

1. Dire ce que vous savez : « Je n'ai jamais utilisé X en production, mais si ça fonctionne comme Y, alors… »
2. Raisonner à voix haute à partir de ce point d'appui — c'est le raisonnement qui est noté, pas la réponse.
3. Conclure honnêtement : « Voilà comment je chercherais la réponse. »

Ce qui élimine, ce n'est jamais l'ignorance d'un point précis. C'est le bluff — un évaluateur technique détecte une réponse inventée en quelques secondes, et un seul bluff détecté jette le doute sur tout le reste de l'entretien.

Les questions que vous posez comptent aussi

La fin d'entretien — « avez-vous des questions ? » — est encore de l'évaluation. « Non, tout est clair » est la pire réponse possible. Trois questions qui signalent un profil sérieux :

• « Comment se passe une mise en production chez vous ? » — vous vous projetez dans le concret.
• « Qu'est-ce qui distingue quelqu'un qui réussit dans l'équipe ? » — vous pensez intégration, pas seulement embauche.
• « Quelle est la principale dette technique du moment ? » — vous savez que tout système en a une, et la réponse vous renseigne autant qu'elle les évalue.

Évitez de poser en premier les questions salaire et télétravail : elles sont légitimes, mais leur place est en fin de process ou avec le recruteur, pas au premier entretien technique.

Parler rémunération sans vous saborder

Une seule règle à ce stade : arrivez avec une fourchette, jamais un chiffre sec, et sachez la justifier par le marché. Notre calculateur salaire & TJM vous donne une base par stack, séniorité et ville. Si la question tombe en entretien technique, une réponse calme — « ma fourchette est X-Y, à affiner selon le périmètre » — clôt le sujet sans vous engager.

Le jour J

De la logistique, mais elle élimine des candidats chaque semaine : lien de visio testé, micro correct, environnement de code prêt si live coding, et cinq minutes d'avance. En visio, prévenez d'emblée si votre connexion est instable — l'annoncer est professionnel, le subir en silence est pénalisant.

Dernier point, le plus important : l'entretien est bilatéral. Vous évaluez aussi l'entreprise — la qualité des questions qu'on vous pose, la façon dont on traite vos réponses, ce que le « et si vous échouez ? » déclenche chez votre interlocuteur. Un process d'entretien bâclé est une information sur ce que sera le quotidien.

S'entraîner contre un vrai recruteur

Tout ce qui précède se travaille seul, sauf une chose : les conditions réelles. La pression d'un inconnu qui vous évalue, le pitch qui déraille, la question qui déstabilise — ça ne se simule pas face à un miroir.

C'est ce que nous proposons avec le coaching entretien d'embauche : une simulation complète avec un recruteur tech, un feedback direct sur ce qui a fonctionné et ce qui vous coûte des points, et la préparation de la négociation salaire ou TJM. Vous vous entraînez contre l'examinateur, avant l'examen.