Entretien technique développeur : les questions à poser (guide recruteur)

Un recrutement raté coûte entre 6 et 12 mois de salaire. Pour un développeur à 55 000 € brut annuel, c'est entre 27 500 € et 55 000 € partis en fumée — sans compter le temps perdu, la charge reportée sur l'équipe et les projets qui prennent du retard.

Selon LinkedIn (2023), 75 % des erreurs de recrutement s'expliquent par une mauvaise évaluation technique et comportementale. Le problème n'est pas de trouver des candidats. C'est de poser les bonnes questions pour identifier ceux qui délivrent réellement.

Ce guide vous donne les questions exactes à poser en entretien technique, les formats d'évaluation qui fonctionnent, et une grille de notation pour objectiver vos décisions. Pas de théorie abstraite — des outils concrets testés sur le terrain.

Ce que vous devez réellement évaluer

La plupart des entretiens techniques échouent parce qu'ils évaluent la mauvaise chose. Connaître par cœur la signature d'une méthode ou réciter les principes SOLID ne fait pas un bon développeur. Ce qui compte, c'est la capacité à résoudre des problèmes réels dans un contexte d'équipe.

Voici les 5 dimensions à évaluer en priorité :

• Raisonnement — comment le candidat décompose un problème complexe en sous-problèmes. Cherche-t-il à comprendre le contexte avant de coder ?
• Architecture — sa capacité à penser au-delà du ticket. Comprend-il les implications d'un choix technique sur la maintenabilité, la performance et l'évolutivité ?
• Pragmatisme — sait-il faire des compromis ? Un développeur qui veut tout refactorer avant de livrer une feature est aussi problématique qu'un développeur qui empile du code spaghetti.
• Communication — peut-il expliquer un concept technique à un non-technique ? Les soft skills sont aussi importants que les hard skills. Un développeur qui ne sait pas communiquer ralentit toute l'équipe.
• Ownership — prend-il la responsabilité de ses choix techniques ? Quand un bug arrive en production, est-ce que sa réaction est de chercher la cause ou de chercher un coupable ?

Oubliez les connaissances encyclopédiques. Un bon développeur sait chercher ce qu'il ne sait pas. Ce que vous évaluez, c'est sa façon de réfléchir et de collaborer.

Les meilleures questions techniques à poser

85 % des recruteurs IT utilisent désormais des tests pratiques en entretien (CodinGame 2024). Mais la qualité des questions fait toute la différence. Voici les catégories de questions les plus révélatrices, avec des exemples concrets.

Questions d'architecture

Ces questions révèlent la capacité du candidat à penser système, au-delà de la ligne de code.

• "Tu dois concevoir un système de notifications en temps réel pour 100 000 utilisateurs. Par où commences-tu ?" — On attend : une clarification des contraintes (latence, volume, fiabilité), un choix argumenté entre WebSocket / SSE / polling, une réflexion sur la scalabilité.
• "Notre API monolithique met 8 secondes à répondre sur certains endpoints. Comment investigues-tu ?" — On attend : une approche méthodique (profiling, monitoring, identification du bottleneck), pas une réponse réflexe du type "il faut passer en microservices".
• "Monolithe ou microservices pour une startup de 5 développeurs qui lance son MVP ?" — On attend : du pragmatisme. La bonne réponse est presque toujours le monolithe à ce stade. Un candidat qui pousse les microservices ici manque de recul.
• "Comment gères-tu le versioning d'une API publique utilisée par 200 clients ?" — On attend : une stratégie concrète (URL versioning, header versioning), une réflexion sur la rétrocompatibilité, un plan de dépréciation.

Questions de code review

Montrer du code et demander une review est l'un des exercices les plus révélateurs. Préparez un extrait de 20 à 40 lignes avec des problèmes intentionnels. Imprimez-le ou partagez-le à l'écran.

• "Voici un extrait de code de production. Fais-en une review comme si c'était une PR d'un collègue." — On observe : identifie-t-il les problèmes de lisibilité, les bugs potentiels, les violations de principes ? Est-il constructif dans ses remarques ou cassant ?
• "Ce code fonctionne mais je ne suis pas satisfait. Qu'est-ce que tu changerais et pourquoi ?" — On observe : sa capacité à prioriser les améliorations (sécurité > performance > style), sa justification des changements proposés.
• "Ce code contient 3 erreurs. Trouve-les." — Méthode éprouvée : imprimez du code avec des erreurs stratégiques (off-by-one, race condition, faille de sécurité) et observez le processus de lecture du candidat.

Questions de debugging

Les questions de debugging révèlent la méthode du candidat face à l'inconnu. C'est ce qui sépare un développeur efficace d'un développeur qui tâtonne.

• "Un client signale que l'application est lente depuis ce matin. Aucun déploiement récent. Que fais-tu dans les 10 premières minutes ?" — On attend : vérifier les métriques (CPU, mémoire, I/O), les logs, les dépendances externes, la base de données. Pas "je redémarre le serveur".
• "Un bug apparaît uniquement en production, jamais en staging. Comment procèdes-tu ?" — On attend : une analyse des différences d'environnement (données, volume, config, dépendances), une approche d'isolation du problème.
• "Après un déploiement, le taux d'erreurs 500 passe de 0,1 % à 5 %. Le rollback est-il ta première action ?" — On attend : un raisonnement nuancé. Le rollback est souvent la bonne première action, mais le candidat doit expliquer quand il choisirait de fix forward à la place.

Questions sur les choix passés

Le deep dive sur un projet réel est irremplaçable. Il permet de vérifier que le candidat a réellement fait ce qu'il revendique sur son CV.

• "Parle-moi du projet dont tu es le plus fier techniquement. Pourquoi cette stack ? Qu'est-ce que tu changerais avec le recul ?" — Un bon candidat assume ses erreurs passées et explique ce qu'il en a tiré. Un candidat qui dit "je ne changerais rien" manque d'esprit critique.
• "Tu as choisi [technologie X] sur ce projet. Quelles alternatives as-tu envisagées et pourquoi les as-tu écartées ?" — On évalue la rigueur du processus de décision. Un choix technique sans analyse comparative est un red flag.
• "Quel est le plus gros échec technique que tu as vécu ? Qu'est-ce qui a mal tourné et comment as-tu réagi ?" — Les développeurs qui n'ont aucun échec à raconter n'ont probablement jamais pris de décision technique significative.

Les questions comportementales indispensables

Les compétences techniques ne suffisent pas. Un développeur brillant qui ne sait pas travailler en équipe, gérer un conflit ou communiquer clairement sera un problème, pas une solution. Voici les questions situationnelles à intégrer dans chaque entretien.

• "Tu es en désaccord technique avec un collègue senior sur l'architecture d'une feature critique. Comment gères-tu la situation ?" — On cherche : de la maturité. Le candidat argumente avec des faits, propose un POC, accepte de se tromper. Pas d'ego, pas de "j'ai raison parce que j'ai plus d'expérience".
• "Raconte-moi une fois où tu as dû livrer un projet avec une deadline très serrée. Comment as-tu priorisé ?" — On évalue : la capacité à couper le scope intelligemment, à communiquer les risques en amont plutôt qu'à faire des nuits blanches en silence.
• "Tu identifies une dette technique importante dans le code. Le product owner refuse d'allouer du temps pour la traiter. Que fais-tu ?" — On évalue : le pragmatisme. Le bon développeur quantifie l'impact business de la dette technique et propose un plan de remédiation progressif.
• "Comment expliques-tu un concept technique complexe à un interlocuteur non technique — un product manager ou un CEO ?" — On observe en direct : le candidat utilise-t-il des analogies, des schémas, des exemples concrets ? Ou noie-t-il son interlocuteur sous le jargon ?
• "As-tu déjà mentoré un développeur junior ? Comment t'y es-tu pris ?" — On cherche : une approche structurée (pair programming, code reviews régulières, montée en compétence progressive), pas juste "je répondais à ses questions".
• "Ton dernier déploiement a causé un incident en production. Le CTO te demande un post-mortem. Comment le structures-tu ?" — On évalue : la culture blameless, la capacité à documenter factuellement, à proposer des actions correctives concrètes.

Les formats d'évaluation qui fonctionnent

Le format de l'évaluation compte autant que les questions. Voici les approches qui produisent les meilleurs résultats en recrutement technique.

Pair programming

Le pair programming est le format le plus naturel et le plus révélateur. Le candidat code en binôme avec un membre de votre équipe sur un problème réaliste — pas un algorithme abstrait, mais un cas proche de votre quotidien.

Avantages : vous observez la communication en temps réel, la capacité à recevoir du feedback, le style de code naturel du candidat. Durée recommandée : 45 minutes à 1 heure. Préparez un environnement de développement fonctionnel à l'avance pour ne pas perdre 20 minutes en setup.

Code review live

Plus pertinent que n'importe quel exercice algorithmique. Présentez une PR réelle (anonymisée) ou un extrait de code préparé. Demandez au candidat de la reviewer comme s'il était dans votre équipe.

Ce que vous observez : la lecture de code (souvent négligée alors qu'un développeur passe plus de temps à lire du code qu'à en écrire), la qualité des remarques, le ton employé. Un bon reviewer identifie les problèmes importants sans s'attarder sur le style cosmétique.

Take-home (max 2 heures)

Le take-home a sa place, mais avec des règles strictes. Maximum 2 heures — jamais plus. Les tests de 4 heures ou plus font fuir les bons profils qui ont un emploi, une vie personnelle et d'autres process en cours.

Définissez clairement le scope, fournissez un brief écrit précis, et prévoyez un débrief de 30 minutes pour discuter des choix du candidat. Le take-home sans débrief ne sert à rien : vous évaluez un livrable, pas un process de réflexion.

System design (pour les seniors)

Pour les profils seniors et lead, l'exercice de system design est incontournable. Proposez un cas concret : "Conçois le système de réservation d'un site comme Doctolib" ou "Architècte un pipeline de traitement de données temps réel".

L'objectif n'est pas d'obtenir la solution parfaite. C'est d'observer le raisonnement : le candidat pose-t-il les bonnes questions ? Identifie-t-il les trade-offs ? Sait-il schématiser clairement ses idées ? Durée : 45 minutes à 1 heure.

Ce qu'il faut arrêter de faire

Les entretiens algorithmiques type LeetCode sont de plus en plus critiqués par les développeurs — et à juste titre. Inverser un arbre binaire ne prédit en rien la capacité à livrer un produit de qualité en équipe. Voici les pratiques à abandonner.

• Les exercices LeetCode en live — ils mesurent la préparation aux exercices algorithmiques, pas la compétence professionnelle. Les meilleurs développeurs de votre équipe échoueraient probablement à ces tests sans préparation.
• Les QCM techniques — savoir que "HTTP 418 signifie I'm a teapot" ne dit rien sur la capacité à concevoir une API robuste. Les QCM évaluent la mémoire, pas la compétence.
• Les marathons de 6+ entretiens — au-delà de 3 entretiens, vous ne gagnez pas en signal, vous perdez en candidats. Les meilleurs profils ont d'autres options et abandonnent les process trop longs.
• Les tests techniques de 4 heures ou plus — c'est irrespectueux du temps du candidat. Vous pouvez évaluer tout ce dont vous avez besoin en 2 heures maximum. Un candidat qui accepte un test de 8 heures n'a probablement pas beaucoup d'alternatives.
• L'absence de feedback — ne pas donner de retour après un entretien technique est la meilleure façon de détruire votre marque employeur. Un email de 3 lignes avec les raisons du refus prend 5 minutes et fait une différence énorme.

Grille d'évaluation type

Sans grille structurée, l'évaluation repose sur le ressenti — et le ressenti est biaisé. Voici une grille en 6 critères notés sur 5 à utiliser après chaque entretien technique.

• Résolution de problèmes : /5 — décomposition du problème, approche méthodique, gestion de l'ambiguïté
• Architecture et design : /5 — vision système, choix techniques argumentés, compréhension des trade-offs
• Qualité de code : /5 — lisibilité, nommage, gestion des erreurs, tests
• Communication : /5 — clarté des explications, capacité à vulgariser, écoute active
• Pragmatisme : /5 — sens des priorités, capacité à faire des compromis, orientation résultat
• Ownership et autonomie : /5 — prise de responsabilité, proactivité, capacité à challenger constructivement

Score total : /30. Seuil recommandé : minimum 20/30, avec aucune note en dessous de 3. Un score excellent en technique mais faible en communication est un signal d'alerte, pas un feu vert.

Chaque évaluateur remplit sa grille indépendamment avant le débrief collectif. Cela évite le biais d'ancrage où le premier à parler influence les autres.

À retenir

L'entretien technique n'est pas un examen. C'est une conversation professionnelle structurée. Voici les 5 points essentiels :

1. Évaluez le raisonnement et la méthode, pas les connaissances encyclopédiques
2. Utilisez des scénarios réalistes : code review, debugging, architecture — pas des exercices algorithmiques déconnectés
3. Les soft skills ne sont pas optionnels — un développeur qui ne communique pas est un développeur qui coûte cher
4. Respectez le temps des candidats : 3 entretiens maximum, tests de 2 heures maximum, feedback systématique
5. Objectivez vos décisions avec une grille d'évaluation remplie par chaque évaluateur indépendamment

Un bon process d'entretien technique attire les bons développeurs autant qu'il les filtre. Les meilleurs candidats évaluent votre entreprise pendant que vous les évaluez.

Vous voulez structurer vos entretiens techniques et ne plus perdre de bons candidats ? Chez Novera Talent, nous concevons et menons les évaluations techniques avec vous — de la grille aux questions, en passant par le débrief. Parlons-en.