Un engineering manager fait deux métiers à la fois, et les questions d'entretien doivent couvrir les deux. Le management d'abord : recrutement, entretiens individuels, progression, situations difficiles. La conduite technique ensuite : delivery, qualité, incidents, dette. Les offres publiées en France décrivent des équipes de huit à dix développeurs, parfois plusieurs squads, la responsabilité du run et des incidents majeurs, et souvent l'adoption des assistants de code IA.
Le tech lead décide de la solution technique, l'engineering manager répond des personnes et de la capacité de l'équipe à livrer. Beaucoup de candidats viennent du poste de tech lead, d'autres de la gestion de projet. Les premiers manquent parfois de pratique sur les retours difficiles, les seconds de recul technique. Vérifiez les deux côtés.
Les réponses toutes faites sur le leadership sont faciles à préparer. Demandez des situations datées : un recrutement raté, un départ, une date manquée, un post-mortem. Faites citer les chiffres suivis, les cinq indicateurs DORA ou le cycle time, et l'usage qui en a été fait. Le PDF propose un cas de 20 minutes sur la reprise d'une équipe en retard.
Les pratiques et repères du poste
Indicateurs DORA
Cinq indicateurs de livraison logicielle publiés par le programme DORA de Google : délai entre commit et production, fréquence de déploiement, taux de déploiements en échec, temps de rétablissement, taux de déploiements non planifiés. Ils décrivent une équipe et son système de livraison, pas une personne.
Cycle time et flux
Le temps entre le début d'un travail et sa mise en production, découpé par étape. Il se lit dans Git et dans l'outil de tickets (Jira, Linear). Un bon manager sait dire où le travail attend.
Scrum et Kanban
Les deux cadres d'organisation les plus répandus. Scrum travaille par sprints avec des engagements, Kanban gère un flux continu avec une limite de travail en cours. Le choix dépend de la part de support et d'imprévu.
Entretiens individuels et grille de progression
Le point régulier entre le manager et chaque développeur, consacré aux blocages, aux retours et à la progression. La grille de progression décrit les attentes par niveau, du junior au staff engineer, et sert aux décisions d'évolution.
Astreinte, incidents et post-mortems
L'organisation du run : rotation d'astreinte, gestion des incidents, objectifs de service (SLO). Après un incident, le post-mortem sans recherche de coupable établit la chronologie, les causes et des actions suivies jusqu'au bout.
CI/CD et revue de code
La chaîne qui teste et déploie le code, et les règles de revue entre développeurs. Le manager ne relit pas tout, il fixe les conventions et surveille la santé de la chaîne : durée, tests instables, taille des pull requests.
Assistants de code IA
GitHub Copilot, Cursor, Claude Code et leurs équivalents. Leur adoption soulève des questions de confidentialité du code, de licences et de charge de revue. Les offres récentes demandent souvent au manager de piloter ce déploiement.
Budget et prestataires
Le manager prépare souvent le budget de son équipe : postes internes, prestataires en régie ou au forfait, outils et licences. Il doit savoir comparer ces coûts et organiser la transmission des connaissances quand une mission se termine.
Le périmètre varie selon la taille de l'organisation. Avec une seule équipe, l'engineering manager reste proche du code et anime souvent les choix techniques avec le tech lead. Avec plusieurs équipes, il encadre des tech leads, porte le recrutement et le budget, et passe plus de temps avec le produit et la direction. Dans les deux cas, il répond de la santé de l'équipe et de sa capacité à livrer sans s'épuiser. Au-dessus, le head of engineering ou le CTO fixe l'organisation d'ensemble et la stratégie technique.
Ce qu'il faut vérifier chez un engineering manager
- Recrutement et intégration des développeurs
- Suivi individuel et progression
- Organisation de la delivery et indicateurs
- Compréhension technique et gestion des incidents
- Arbitrages entre roadmap et dette technique
- Budget, prestataires et parties prenantes
Cinq situations à faire raconter à un engineering manager
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · senior
Le cycle time de l'équipe a doublé en un trimestre. Comment cherchez-vous la cause ?
Une bonne réponseIl découpe le cycle time par étape à partir de Git et de l'outil de tickets : développement, attente de revue, revue, attente de déploiement. Il regarde la taille des pull requests, le nombre de sujets en cours, la file de revues, une CI lente ou instable, les dépendances à d'autres équipes. Il en parle en rétrospective avant d'agir, puis teste une action (limite du travail en cours, pull requests plus petites, délai de revue) et mesure de nouveau.
Signal d'alerte« Je demande à l'équipe d'accélérer », des heures supplémentaires, ou des renforts sans diagnostic.
Question 2 · senior
Un incident a coupé le paiement en ligne deux heures un vendredi soir. Que se passe-t-il dans votre équipe la semaine suivante ?
Une bonne réponseUn post-mortem sans recherche de coupable dans les jours qui suivent : chronologie, délai de détection, causes (souvent plusieurs), ce qui a bien fonctionné, actions avec un responsable et une date. Il regarde la charge de l'astreinte, informe les parties prenantes, et suit les actions jusqu'au bout. Les actions portent sur la détection, les déploiements (feature flags, déploiement progressif) et les tests.
Signal d'alerteChercher qui a poussé le changement, ou décider « plus de déploiement le vendredi » comme seule action.
Question 3 · senior à lead
Le produit veut trois nouvelles fonctionnalités ce trimestre, l'équipe demande du temps pour la dette technique. Comment arbitrez-vous ?
Une bonne réponseIl rend la dette visible par son coût : incidents, lenteur des évolutions sur un module, temps d'intégration des nouveaux. Il la relie aux objectifs du produit, puis propose une règle : une part fixe de capacité, des refontes faites en même temps que les fonctionnalités qui touchent la même zone, ou un chantier dédié avec un résultat mesurable. La décision se prend avec le product manager, par écrit, et se revoit au trimestre suivant.
Signal d'alerte« La dette passe toujours après », ou refuser les fonctionnalités par principe. « On s'en occupera quand on aura le temps. »
Question 4 · senior
Un développeur senior livre bien, mais ses commentaires en revue de code découragent les juniors. Que faites-vous ?
Une bonne réponseIl part de faits : des commentaires précis dans des pull requests, des retours des juniors. Il en parle en entretien individuel avec ces exemples, en décrivant la situation, le comportement et son effet sur l'équipe, et fixe une attente claire avec une date de suivi. Au niveau de l'équipe, il écrit des règles de revue : distinguer ce qui bloque de la remarque de style, proposer une solution. Il reconnaît aussi la valeur technique du senior.
Signal d'alerteNe rien dire parce qu'il livre, un recadrage devant l'équipe, ou un vague « sois plus sympa ».
Question 5 · senior
Vous devez recruter deux développeurs back-end en trois mois. Comment construisez-vous le processus, de la fiche de poste à l'offre ?
Une bonne réponseIl définit le besoin avec l'équipe : niveau, stack, ce que la personne fera les six premiers mois. La grille de critères est écrite avant le premier entretien. Les étapes sont courtes et identiques pour tous : échange, exercice proche du travail réel, rencontre avec l'équipe. Chaque intervieweur note seul avant le débrief, et un développeur de l'équipe participe. Il suit le nombre de candidats à chaque étape pour corriger ce qui coince.
Signal d'alerte« Je me fie à mon ressenti », un test maison de huit heures, ou un processus qui change d'un candidat à l'autre.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Engineering manager : réponses aux questions des recruteurs
Quelle différence entre engineering manager, tech lead et head of engineering ?
Le tech lead porte les choix techniques d'une équipe et code encore beaucoup. L'engineering manager encadre les personnes : recrutement, entretiens individuels, progression, organisation de la delivery. Le head of engineering encadre plusieurs managers et décide de l'organisation de l'ensemble des équipes. Dans les petites structures, une même personne cumule parfois deux de ces rôles. L'offre doit dire clairement lequel vous recrutez et combien de personnes il encadre.
Un engineering manager doit-il encore coder ?
Rarement sur le chemin critique d'une livraison, car ses priorités l'interrompent trop souvent. Il doit en revanche lire du code, comprendre une architecture, discuter une estimation et mener un post-mortem technique. Beaucoup gardent un petit travail technique : outillage, revue, corrections mineures. En entretien, vérifiez qu'il sait poser les bonnes questions à son tech lead plutôt que le nombre d'heures de code par semaine.
Faut-il faire passer un test technique à un engineering manager ?
Pas un exercice de code classique. Une discussion de conception sur un système proche du vôtre, ou la lecture commentée d'une pull request et d'un post-mortem, montre mieux son niveau technique. Ajoutez une mise en situation de management, comme la reprise d'une équipe en retard ou un retour difficile à faire, avec la même grille pour tous les candidats.
Comment vérifier l'expérience de management annoncée sur un CV ?
Demandez combien de personnes la candidate ou le candidat encadrait en direct, depuis quand, et qui a été recruté, promu ou est parti sous sa responsabilité. Faites raconter un retour difficile, avec la date et la suite. Une personne qui a vraiment managé donne des détails, des erreurs et ce qu'elle a changé ensuite. Les prises de références auprès d'anciens collaborateurs complètent utilement l'entretien.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
