Les entretiens techniques ne sont pas ce que tu crois. Après plusieurs échanges avec des architectes et tech leads, j’ai réalisé que ce n’est pas un test — c’est une discussion. Voici ce que j’aurais aimé comprendre plus tôt.
Je veux te raconter quelque chose que j’ai mal compris pendant longtemps.
Les entretiens techniques.
Pas ceux qu’on fantasme. Pas ceux qu’on redoute. Ceux qu’on vit vraiment.
Parce que pendant presque 3 ans dans la même boîte, j’ai fait une erreur simple : je ne passais pas d’entretiens.
Pas pour changer de job. Juste pour me tester. Me confronter. Comprendre comment les autres pensent.
Et avec le recul, c’était une erreur.
Je pensais que c’était un jugement.
Un moment où quelqu’un allait tester mes limites, chercher mes failles, et décider si je “valais le coup”.
En réalité, j’ai découvert quelque chose de beaucoup plus intéressant :
Un entretien technique, c’est une discussion gratuite avec quelqu’un qui a souvent plus d’expérience que toi.
Un architecte. Un tech lead. Un senior avec des années de recul.
Et si tu arrives à passer un cap mental, ça change tout.
Le déclic est simple.
À partir du moment où tu maîtrises ce que tu dis — vraiment — l’entretien devient fluide.
Parce que forcément, on va te challenger.
Toujours.
Pourquoi ce choix ? Pourquoi cette architecture ? Pourquoi pas une autre approche ?
Et là, deux options :
C’est là que ça devient intéressant.
Un des entretiens qui m’a marqué a duré environ 1h10.
On n’a presque pas parlé de code.
On a parlé de :
Et surtout : pourquoi.
Pourquoi tu fais ça comme ça ? Qu’est-ce que tu gagnes ? Qu’est-ce que tu perds ?
À aucun moment il ne cherchait “la bonne réponse”.
Il cherchait à comprendre comment je réfléchis.
J’ai compris un truc ce jour-là :
Une bonne réponse avec une mauvaise démarche ne passe pas. Une réponse imparfaite avec une bonne démarche est beaucoup plus intéressante.
Et ça change tout.
Parce que dans la vraie vie, tu n’as pas toutes les réponses.
Mais tu dois toujours avancer.
À un moment, l’architecte me pose une question.
Simple. Mais je ne réponds pas.
Trou noir.
Fatigue. (J’avais déjà enchaîné deux entretiens le matin.) Stress. Et peut-être juste… un moment off.
Et là, il me dit un truc simple :
“C’est pas grave.”
On passe à autre chose.
Et quelques minutes plus tard, sans prévenir, je réponds à cette même question… mais dans un autre contexte.
On parle d’API REST.
Et là, ça sort naturellement :
Rien de récité. Juste des concepts que je comprends.
Et là, il me dit :
“C’est exactement ce que j’attendais tout à l’heure.”
Ce n’était pas un problème de compétence.
C’était un problème de contexte. De fatigue. De timing.
Et ça, c’est important de le comprendre.
Un entretien, ce n’est pas une machine parfaite.
C’est humain.
Après une discussion assez similaire à la première — autour de l’architecture, des choix techniques, des bonnes pratiques — on finit par basculer sur quelque chose de plus concret.
Un exercice type e-commerce. En Java.
Et là encore, même schéma.
Dès le début, le lead dev pose le cadre :
“Ce qui m’intéresse, c’est ta démarche.”
On code ensemble.
Même IDE. Je réfléchis à voix haute.
Et lui, il ne reste pas passif. Il interagit :
Ce n’est pas quelqu’un qui te regarde coder en silence.
C’est une vraie collaboration.
À un moment, on arrive sur une partie améliorable.
Je propose une idée simple : isoler une logique pour éviter de toucher à la classe si ça évolue demain.
Il prend l’initiative. Il le fait directement.
Et c’était exactement ce que j’avais en tête.
Encore une fois, ce n’est pas la syntaxe qui est évaluée.
C’est :
Et surtout :
est-ce que tu es capable de construire avec quelqu’un, pas juste répondre seul dans ton coin.
Après plusieurs entretiens en quelques semaines, j’ai réalisé quelque chose de simple :
On est tous en train de faire la même chose.
On parle :
Très peu de syntaxe. Très peu de “pièges”.
Beaucoup de réflexion.
Le vrai tournant, c’est quand je me suis posé une question inconfortable :
Est-ce que je suis capable de tenir une vraie discussion technique avec quelqu’un que je ne connais pas ?
Pas coder. Pas exécuter un ticket.
Mais expliquer. Justifier. Défendre une idée.
Et honnêtement, au début… je n’étais pas sûr.
Maintenant, je demande à passer des entretiens.
Même sans vouloir changer de boîte.
Parce que chaque entretien :
Et surtout :
chaque entretien me fait progresser plus vite que des semaines de routine.
Dire :
“Je ne sais pas.”
Mais ne pas s’arrêter là.
Ajouter :
“Par contre, je réfléchirais comme ça…”
C’est ça qui fait la différence.
Parce qu’encore une fois :
on évalue ta façon de penser, pas ta mémoire.
Tout ça rejoint une idée que j’ai déjà partagée.
Un bon software engineer, ce n’est pas quelqu’un qui récite.
C’est quelqu’un qui :
Le reste ?
Ça s’apprend.
Ce post reflète mon retour d’expérience après plusieurs entretiens techniques en peu de temps. Pas une vérité absolue — juste une prise de recul que j’aurais aimé avoir plus tôt.
Ces articles reflètent mes choix d'architecture sur des projets réels. Les retours et axes d'amélioration sont les bienvenus.