Préparer un entretien technique de développeur, étape par étape

Un recrutement de développeur ne se joue pas en un seul entretien technique. C’est une suite d’étapes, chacune menée par une personne différente, avec ses propres critères : le recruteur vérifie l’adéquation au poste, le lead technique votre façon de raisonner, l’équipe votre manière de travailler avec elle. Se préparer efficacement, c’est savoir à quelle étape on se trouve et ce qu’elle cherche à mesurer. Cet article décrit le parcours le plus courant en France, la façon de réviser selon le type d’employeur, et le rôle que joue votre CV dans les questions qu’on vous posera.

Les étapes d’un recrutement de développeur

Le nombre d’étapes varie selon la taille de l’entreprise et le niveau du poste, mais la structure se retrouve presque partout.

1. L’appel de qualification. Un recruteur, interne ou en cabinet, vous appelle pour une vingtaine de minutes. Il vérifie votre disponibilité, vos attentes de rémunération, votre stack et votre intérêt pour le poste.
2. L’entretien avec le manager ou le lead technique. C’est souvent le premier échange technique. Il porte sur votre parcours, vos projets récents et quelques questions de fond sur la stack.
3. L’exercice technique. Selon l’entreprise, il prend la forme d’un test en ligne chronométré, d’un exercice à faire chez soi, d’une séance de live coding ou de pair programming, ou, pour les postes confirmés et seniors, d’un entretien de conception de système.
4. La restitution ou l’entretien d’équipe. Vous rencontrez deux ou trois membres de l’équipe, présentez votre exercice ou discutez d’un problème réel. On évalue autant la collaboration que la technique.
5. L’échange final. Avec un CTO, un directeur technique ou un responsable RH : culture d’entreprise, projet à moyen terme, conditions de l’offre.

Dans une startup, les étapes 2 à 4 peuvent se tenir dans la même demi-journée. Dans un grand groupe ou une ESN, l’ordre change parfois : l’entretien RH vient en premier, et un entretien client s’ajoute lorsque vous êtes recruté pour une mission précise.

Ce que chaque étape évalue

Chaque interlocuteur a une grille, explicite ou non. Connaître la sienne permet de répondre à la bonne question.

Le recruteur évalue l’adéquation : le poste correspond-il à votre niveau, votre stack, vos attentes et votre calendrier ? Il ne vous fera pas coder, mais il notera si vous savez expliquer simplement ce que vous faites. Préparez une présentation de votre parcours en deux minutes, compréhensible par une personne non technique, et une fourchette de rémunération réaliste.

Le lead technique évalue la profondeur. Il cherche à savoir si vous comprenez ce que vous utilisez, ou si vous appliquez des recettes. Ses questions partent souvent d’un point de votre CV et descendent d’un niveau à chaque réponse : « Pourquoi PostgreSQL plutôt qu’une base documentaire ? Comment avez-vous choisi vos index ? Que se passe-t-il quand deux transactions modifient la même ligne ? »

L’exercice technique évalue votre méthode autant que le résultat. Un code qui fonctionne mais qu’on ne peut pas relire, sans test et sans explication des choix, est rarement bien noté. À l’inverse, une solution incomplète mais structurée, dont vous expliquez les limites, peut suffire.

L’entretien d’équipe évalue la collaboration : comment vous réagissez à une remarque sur votre code, comment vous posez une question, comment vous découpez un problème avec quelqu’un d’autre. Les futurs collègues se demandent surtout s’ils ont envie de relire vos pull requests.

L’échange final évalue la motivation et l’alignement sur le long terme. C’est aussi le moment où se négocie l’offre.

De plus en plus d’entreprises formalisent ces grilles : mêmes questions pour tous les candidats, critères notés séparément, décision prise à plusieurs. Si vous voulez comprendre cette logique de l’autre côté de la table, la méthode de l’entretien structuré telle que la pratiquent les recruteurs 🔗 explique comment ces grilles sont construites et pourquoi elles réduisent les biais.

Réviser selon le type d’entreprise

On ne prépare pas un entretien de la même façon pour une ESN, une startup ou un grand éditeur de logiciels. Les attentes diffèrent sur trois points : le type d’exercice, le niveau de détail attendu et la place de l’autonomie.

En ESN

Les ESN recrutent souvent pour des besoins clients précis. L’entretien technique est généralement plus court et porte sur les fondamentaux de la stack demandée : programmation orientée objet, frameworks du marché (Spring, Angular, .NET), SQL, tests unitaires. Un questionnaire technique écrit ou un test en ligne est fréquent. Révisez les bases de votre langage principal, les principes SOLID, les patrons de conception courants, et soyez prêt à expliquer comment vous vous adaptez à un nouvel environnement client.

En startup ou en scale-up

Les startups cherchent des développeurs capables de livrer vite et seuls sur un périmètre. L’exercice est souvent un cas proche de leur produit, à faire chez vous ou en live coding. Révisez la conception d’API, la modélisation d’une base relationnelle, les tests et le déploiement. Préparez aussi des exemples de situations où vous avez pris une décision technique sans tout le contexte, et ce que vous en avez appris.

Chez un grand éditeur ou une entreprise tech internationale

Les processus y sont plus longs et plus standardisés. On y trouve des exercices d’algorithmique (structures de données, complexité), des entretiens de conception de système pour les profils confirmés et des entretiens comportementaux structurés. Révisez les structures de données classiques (tables de hachage, arbres, graphes), l’analyse de complexité, et entraînez-vous à raconter vos expériences selon un schéma situation, action, résultat.

Si l’exercice prend la forme d’un projet à rendre, notre article sur le test technique à la maison détaille ce que l’équipe regarde en corrigeant.

Quel que soit le type d’employeur, relisez l’offre ligne par ligne et listez les technologies et les pratiques citées : ce sont les thèmes les plus probables de l’entretien.

Votre CV, point de départ des questions

Beaucoup de candidats révisent des listes de questions génériques et oublient la source la plus probable des questions : leur propre CV. Le lead technique l’a sous les yeux. Il va s’en servir.

Relisez donc votre CV comme le ferait un interviewer, ligne par ligne, et préparez une réponse à trois questions pour chaque élément :

• Qu’avez-vous fait exactement ? Votre part personnelle, pas celle de l’équipe.
• Pourquoi l’avez-vous fait ainsi ? Les options écartées et la raison du choix.
• Que feriez-vous différemment aujourd’hui ? Une question presque systématique chez les leads, qui mesure votre recul.

Chaque technologie listée dans vos compétences doit pouvoir tenir cinq minutes de discussion. Si ce n’est pas le cas, retirez-la avant d’envoyer votre CV, ou précisez votre niveau. Notre article sur la présentation de sa stack technique détaille comment éviter ce piège dès la rédaction.

Chaque chiffre doit aussi pouvoir être expliqué. « Temps de réponse ramené de 1,8 s à 0,4 s » appellera immédiatement la question : mesuré comment, sur quel endpoint, avec quelle charge ? Le modèle de CV de développeur junior montre des chiffres de ce type, précis et défendables.

Un CV clair facilite aussi la conduite de l’entretien : l’interviewer retrouve vite l’expérience dont il veut parler. Un éditeur de CV qui gère pour vous la mise en page vous laisse vous concentrer sur le contenu, et produit un document que les logiciels de recrutement lisent sans erreur. Vous pouvez reprendre le vôtre dans l’éditeur avant de postuler.

Parler d’un projet en profondeur

Presque tous les processus comportent une question du type : « Parlez-moi d’un projet dont vous êtes fier. » C’est la question la plus prévisible, et pourtant la plus souvent ratée, parce que le candidat reste en surface.

Choisissez un projet à l’avance, avec trois critères : vous y avez joué un rôle central, il comporte au moins une vraie difficulté technique, et vous pouvez en parler sans enfreindre une clause de confidentialité. Préparez ensuite votre récit en couches successives.

1. Le contexte en trente secondes : le produit, l’équipe, l’objectif.
2. Votre rôle : ce que vous avez conçu, codé, décidé.
3. L’architecture : les composants principaux et la façon dont ils communiquent. Entraînez-vous à la dessiner au tableau ou dans un outil de schéma en ligne.
4. La difficulté : un problème de performance, de cohérence des données, d’intégration ou de migration, et la façon dont vous l’avez résolu.
5. Le résultat et le recul : ce que le projet a changé, ce qui reste imparfait, ce que vous changeriez.

L’interviewer vous interrompra pour creuser. C’est bon signe : il cherche la limite de votre connaissance. Quand vous l’atteignez, dites-le clairement (« Je n’ai pas travaillé sur cette partie, mais je suppose que… ») plutôt que d’improviser. Un lead préfère largement une limite assumée à une réponse inventée.

Pour un profil senior, ajoutez une dimension : comment avez-vous impliqué l’équipe, documenté les décisions, accompagné les autres développeurs ? Le modèle de CV de tech lead illustre la façon de présenter ces responsabilités sans perdre de vue la technique.

Les questions à poser à l’équipe

La fin de chaque entretien vous laisse la parole. Ne la gaspillez pas avec des questions dont la réponse figure sur le site de l’entreprise. Les bonnes questions montrent votre intérêt et vous donnent des informations utiles pour décider.

Quelques questions qui fonctionnent bien avec une équipe technique :

• Sur la livraison : comment se passe une mise en production ? À quelle fréquence ? Qui peut déployer ?
• Sur la qualité : comment sont organisées les revues de code ? Quelle place pour les tests automatisés ?
• Sur la dette technique : quelle est la partie du code dont l’équipe est la moins fière, et y a-t-il un plan pour la traiter ?
• Sur l’astreinte et les incidents : qui est appelé quand la production tombe ? Comment sont faits les retours d’expérience ?
• Sur l’intégration : à quoi ressembleront mes trois premiers mois ? Quand pourrai-je livrer mon premier changement ?
• Sur l’équipe : comment sont prises les décisions d’architecture ? Comment le produit et la technique travaillent-ils ensemble ?

Notez les réponses. Elles vous serviront à comparer deux offres, et elles nourriront votre échange final si vous avancez dans le processus.

Questions fréquentes

Combien de temps faut-il pour préparer un entretien technique ?

Cela dépend de votre familiarité avec la stack et du type d’exercice. Pour un poste proche de votre quotidien, quelques soirées suffisent souvent : relire votre CV, réviser les fondamentaux de la stack de l’offre et répéter le récit d’un projet. Pour un processus avec algorithmique ou conception de système, prévoyez plusieurs semaines d’entraînement régulier.

Faut-il connaître par cœur les questions classiques ?

Non. Réciter une définition apprise se voit tout de suite, et l’interviewer posera une question de suivi. Mieux vaut comprendre les concepts au point de les expliquer avec vos mots et de les relier à une situation que vous avez vécue.

Que faire si je bloque pendant un exercice ?

Dites-le à voix haute et expliquez où vous en êtes : ce que vous avez compris, ce que vous essayez, ce qui coince. L’interviewer peut vous débloquer avec un indice, et il note surtout la façon dont vous réagissez à une difficulté.

Peut-on refuser un exercice technique à la maison trop long ?

Vous pouvez demander s’il existe une version plus courte ou proposer un autre format, comme une session de pair programming. Beaucoup d’entreprises acceptent d’en discuter, surtout pour un profil confirmé. Si elles refusent, c’est aussi une information sur leur culture.