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.
Avec le recul, c'était une erreur.
01 — ce que je croyais
Je pensais que c'était un jugement.
Un moment où quelqu'un allait tester mes limites, chercher mes failles, décider si je "valais le coup".
En réalité ? 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.
Si tu passes ce cap mental, ça change tout.
02 — le moment où ça bascule
Le déclic est simple.
À partir du moment où tu maîtrises vraiment ce que tu dis, l'entretien devient fluide.
Parce qu'on va te challenger. Toujours.
Pourquoi ce choix ? Pourquoi cette architecture ? Pourquoi pas une autre approche ?
Deux options :
| Tu récites | Tu comprends |
|---|---|
| Tu bloques | Tu échanges |
C'est là que ça devient intéressant.
03 — 1h10 avec un architecte, zéro question de syntaxe
Un entretien qui m'a marqué a duré environ 1h10.
On n'a presque pas parlé de code. On a parlé d'architecture hexagonale, de microservices vs monolithe, de justification des choix, de compromis.
Et surtout : pourquoi.
Pourquoi tu fais ça comme ça ? Qu'est-ce que tu gagnes ? Qu'est-ce que tu perds ?
Il ne cherchait pas "la bonne réponse". Il cherchait à comprendre comment je réfléchis.
04 — la leçon la plus importante
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.
Dans la vraie vie, tu n'as pas toutes les réponses. Mais tu dois toujours avancer.
05 — le trou noir 💀
À un moment, l'architecte me pose une question. Simple.
Mais je ne réponds pas. Trou noir.
Fatigue (j'avais enchaîné deux entretiens le matin). Stress. Un moment off.
Il me dit :
"C'est pas grave."
On passe à autre chose.
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 : les verbes HTTP et leur sémantique, les status codes, la notion de ressources vs actions, même HATEOAS que je ne pensais pas sortir en entretien.
Rien de récité. Juste des concepts que je comprends.
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.
Un entretien, ce n'est pas une machine parfaite. C'est humain.
06 — l'autre expérience : le lead dev
Après une discussion similaire autour de l'architecture, on bascule sur un exercice concret. Un e-commerce. En Java.
Dès le début, il 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.
Lui, il interagit :
*"Tu penses quoi si on fait ça ?" *"T'as rien oublié ici ?"* "Et ce cas-là ?"*
Ce n'est pas quelqu'un qui te regarde coder en silence. C'est une vraie collaboration 🤝
À un moment, j'arrive sur une partie améliorable. Je propose d'isoler une logique pour éviter de toucher à la classe si ça évolue demain. Il le fait directement.
C'était exactement ce que j'avais en tête.
07 — ce qui est vraiment évalué
Après plusieurs entretiens en quelques semaines, j'ai réalisé quelque chose de simple. On parle tous de la même chose : bonnes pratiques, architecture, design, compromis.
Très peu de syntaxe. Très peu de "pièges".
Et la vraie question derrière tout ça :
Est-ce que tu es capable de construire avec quelqu'un, pas juste répondre seul dans ton coin ?
08 — le vrai déclic
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.
Honnêtement, au début… je n'étais pas sûr.
09 — et maintenant ?
Maintenant, je demande à passer des entretiens. Même sans vouloir changer de boîte.
Parce que chaque entretien m'apprend quelque chose, me montre mes limites, améliore ma façon de communiquer.
Chaque entretien me fait progresser plus vite que des semaines de routine.
10 — le truc le plus sous-estimé
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. On évalue ta façon de penser, pas ta mémoire.
pour finir.
Un bon software engineer, ce n'est pas quelqu'un qui récite.
C'est quelqu'un qui comprend un problème, le découpe, propose une solution, et surtout justifie ses choix.
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.