L’offre d’emploi, c’est le corrigé de ton entretien

Tu veux savoir ce que font 90 % des devs avant un entretien ? Ils survolent l’offre, balancent le CV, puis grindent LeetCode pendant trois semaines. Au hasard. Et après, surprise : ça coince le jour J.

J’ai fait exactement pareil pendant des années. Jusqu’au moment où je me suis retrouvé de l’autre côté de la table.

Ce que j’ai compris en faisant passer des entretiens

Le truc c’est que les questions d’entretien ne tombent pas du ciel. Le hiring manager prend la fiche de poste, souligne les compétences clés au marqueur, et distribue les blocs entre intervieweurs. Chacun prend un morceau. C’est mécanique.

Quand j’ai réalisé ça, ma façon de préparer les entretiens a complètement changé. L’offre n’est pas un texte administratif qu’on lit une fois avant d’oublier — c’est littéralement le plan de l’entretien, à peine maquillé.

Alors oui, personne n’écrit noir sur blanc “on va te poser une question sur Kafka”. Mais les indices sont partout si tu sais les décoder. Quelques traductions du jargon RH :

• “Environnement à forte croissance” = questions sur la scalabilité. Garanti.
• “Équipe autonome” = on évalue ta capacité à décider seul, sans filet
• “Collaboration avec le produit” = comment tu parles à des non-techniques
• “Legacy et modernisation” = migration, dette technique, refactoring stratégique
• “Culture d’excellence technique” = code reviews, standards, RFCs — ils vont creuser

Et un détail que peu de gens remarquent : l’ordre des compétences dans l’offre est rarement aléatoire. Si “Go” apparaît avant “Kubernetes”, c’est Go qu’on va évaluer en profondeur. Un mot qui revient trois fois dans le texte ? C’est un néon clignotant.

Arrête de préparer “les entretiens en général”

Là je vais dire un truc un peu à contre-courant. La préparation généraliste, celle où tu fais 200 problèmes algorithmiques sans savoir ce qu’on va te demander — c’est du temps gaspillé. Enfin, pas totalement gaspillé. Mais le ratio effort/résultat est mauvais.

Ce qui marche vraiment, c’est de préparer cet entretien-là. Celui qui correspond à cette offre-là.

Concrètement : prends l’offre, lis-la phrase par phrase, et extrais chaque compétence dans un tableau. Genre ça :

Pour chaque compétence technique, prépare trois angles. D’abord les connaissances pures — “Quelle différence entre un Deployment et un StatefulSet ?” Le filtre rapide. Ensuite la conception — “Comment tu designerais un pipeline d’observabilité pour 50 microservices ?” Là, c’est ton vécu qui parle. Et enfin l’anecdote terrain — “Raconte un incident de prod diagnostiqué grâce au monitoring.” Si t’en as pas, ça se voit immédiatement.

Pour le comportemental, format STAR. Une anecdote par compétence, minimum. Leadership ? Un moment où t’as défendu une décision impopulaire. Communication ? Une situation où t’as vulgarisé un truc complexe pour un non-tech.

Le plan de bataille (sans te mentir)

Franchement ? La partie la plus dure, c’est l’honnêteté avec toi-même. T’as ta matrice de compétences. Maintenant, classe chaque ligne dans une zone.

Zone verte — tu maîtrises. 30 minutes de rafraîchissement, c’est plié. Résiste à l’envie de passer trois jours dessus pour te rassurer (je sais, c’est tentant).

Zone orange — tu connais le sujet mais t’es rouillé. Ou bien t’as jamais eu à l’expliquer clairement. Compte 2 à 4 heures de boulot ciblé.

Zone rouge — un vrai trou. Jamais pratiqué, ou c’est trop loin. Là, 6 à 10 heures. Avec des exercices concrets, pas juste de la doc.

Si t’as deux semaines devant toi : semaine 1, attaque les rouges. Je sais que ça paraît bizarre — ton instinct te dit de consolider ce que tu sais déjà. Mais c’est sur les rouges que le ROI est le plus fort. Monte un mini-projet, résous des problèmes réels. La théorie seule ne tient pas deux minutes face à un intervieweur qui creuse.

Semaine 2, tu passes aux oranges et tu rafraîchis les vertes. Le plus important à ce stade : entraîne-toi à répondre à voix haute. La différence entre savoir quelque chose et savoir l’expliquer sous pression… elle est énorme.

Ah, et renseigne-toi sur le format. Glassdoor, LinkedIn, ou demande directement au recruteur. Coding interview, system design, live debugging, pair programming — ça change complètement ton allocation de temps.

Les questions qui prouvent que t’as bossé

Fin de l’entretien. “T’as des questions ?” La plupart des candidats lâchent un truc générique et passent à côté d’une opportunité en or.

Toi, tu sors tes questions tirées de l’analyse de l’offre. “L’offre mentionne une modernisation du système de paiement — vous en êtes où dans cette migration ?” Ou encore : “Vous cherchez de l’expertise en observabilité, quels outils vous utilisez et c’est quoi les frustrations aujourd’hui ?”

Ce genre de questions transforme l’entretien en vraie conversation. L’intervieweur se dit “OK, cette personne a compris notre contexte”. C’est un avantage massif par rapport à ceux qui demandent “c’est quoi une journée type ?”.

L’offre est vague ? Creuse ailleurs.

Parfois l’offre est écrite à la va-vite, pleine de phrases bateaux. Ça arrive. Mais l’information existe quand même — il faut juste aller la chercher.

Profils LinkedIn de l’équipe. Blog technique de la boîte. Contributions open source. Talks en conférence. Chaque source te donne des indices sur ce qui compte vraiment pour eux. L’offre d’emploi contient 70 à 80 % des sujets qui vont tomber en entretien. Le reste, tu le trouves dans cet écosystème.

Prépare cet entretien, pas “les entretiens”. La différence se voit. Et les recruteurs la sentent tout de suite.

Envie de structurer ta préparation ? Découvre nos outils →

Questions fréquentes

Combien de temps il faut pour analyser une offre d’emploi correctement ?

Honnêtement, entre 30 minutes et une heure. La première lecture prend 10 minutes, mais c’est le tableau de compétences qui demande du temps. Faut relire, croiser les infos, prioriser. C’est un investissement ridicule comparé aux dizaines d’heures que tu vas passer à préparer — autant les passer sur les bons sujets.

Et si l’offre liste 15 compétences techniques ?

Personne ne les évalue toutes. Concentre-toi sur les 5 premières et celles qui reviennent plusieurs fois. Le reste, c’est souvent du remplissage ou du “nice to have” que le recruteur a ajouté par prudence.

Ça marche aussi pour les entretiens en startup ?

Ouais, et c’est même encore plus vrai en startup. Les offres sont souvent plus courtes, plus directes. Chaque mot compte davantage. Par contre, en startup, creuse bien le contexte autour — blog, GitHub, articles du CTO. L’offre seule suffit rarement.

Tu recommandes quoi comme format pour le tableau de compétences ?

Un tableur simple, même un Google Sheet. Trois colonnes : compétence, type, priorité. Pas besoin de sur-ingénierer le truc. L’important c’est de le faire, pas de le faire dans le bon outil.