Questions d'entrevue pour ingénieur sénior qui fonctionnent vraiment
On this page
La séniorité, ce n’est pas des années sur un CV. C’est du jugement : savoir quels coins couper, lesquels ne jamais couper, et comment décider avec de l’information incomplète. On ne peut pas tester le jugement avec des questions pièges, alors chaque question ci-dessous demande au candidat de raisonner sur de vraies décisions. Pour chacune, vous obtenez la question, ce qu’elle révèle, et à quoi ressemblent les réponses fortes et faibles.
Jugement d’architecture
« Décrivez-moi un système que vous avez conçu. Que changeriez-vous aujourd’hui? »
Cette question révèle si la personne a pris des décisions délibérées ou hérité de choix par défaut. Une réponse forte nomme les contraintes (taille de l’équipe, échéance, charge attendue), explique ce que les contraintes excluaient, et offre un regret précis (« je n’aurais pas séparé le service de facturation si tôt, ça a doublé notre complexité de déploiement sans bénéfice à cette échelle »). Une réponse faible récite la pile (« on a utilisé React, Node et Postgres ») sans raisonnement et sans regrets.
« Quand choisiriez-vous un monolithe plutôt que des microservices? »
Forte : une réponse arrimée à la taille de l’équipe et à la maturité opérationnelle, qui privilégie le monolithe par défaut et nomme la douleur précise qui justifie de séparer. Faible : une réponse dogmatique dans un sens ou dans l’autre, ou de vagues appels à la « scalabilité » sans chiffre à l’appui.
Compromis sous contraintes
« Parlez-moi d’une fois où vous avez livré quelque chose en sachant que ce n’était pas la meilleure solution technique. »
Tout vrai sénior l’a fait. Les réponses fortes montrent un compromis conscient : quelle était l’échéance ou le besoin d’affaires, quelle dette a été prise, comment elle a été contenue, et si la personne est retournée la corriger. Les réponses faibles prétendent que ce n’est jamais arrivé, ou décrivent des coins coupés sans plan de confinement ni suivi.
« Votre équipe veut réécrire un module central. Comment évaluez-vous ça? »
Forte : demande ce que la réécriture rapporte en termes mesurables, considère un chemin incrémental (patron étrangleur, module par module) et pèse le coût du gel des fonctionnalités. Faible : de l’enthousiasme pour la réécriture elle-même, ou un non réflexe sans cadre pour décider.
Débogage et profondeur opérationnelle
« Quel est le bogue le plus difficile que vous ayez pourchassé? Racontez-le-moi étape par étape. »
La question au signal le plus fort de cette liste. Les réponses fortes montrent une méthode : reproduire le problème, réduire l’espace de recherche par moitiés, remettre en question les hypothèses, lire le code source d’une dépendance quand la documentation mentait. L’histoire a des culs-de-sac, parce que le vrai débogage en a. Les réponses faibles sont courtes, vagues, ou finissent par « quelqu’un d’autre l’a trouvé » sans aucune leçon tirée.
« Un point d’accès en production est devenu 10 fois plus lent depuis la semaine dernière. Que faites-vous en premier? »
Forte : commence par ce qui a changé (déploiements, forme du trafic, croissance des données), consulte les métriques et les traces avant de toucher au code, et formule une hypothèse avant d’agir. Faible : saute directement à « ajouter de la cache » ou « augmenter la capacité » sans diagnostic.
Collaboration et influence
« Parlez-moi d’un désaccord technique avec un collègue. Comment ça s’est terminé? »
Forte : la personne peut énoncer équitablement la position de l’autre, décrire comment la décision a été prise (prototype, données, déférence au responsable), et parfois elle a perdu et s’est ralliée quand même. Faible : elle avait raison, l’autre personne était difficile, et l’histoire n’a pas de fin ou une fin amère.
« Comment révisez-vous une grosse demande de tirage d’un ingénieur junior? »
Forte : sépare les problèmes bloquants des préférences, explique le pourquoi de chaque commentaire, et sait quand travailler en binôme plutôt que commenter. Faible : décrit du pinaillage de style, ou admet laisser passer les grosses demandes de tirage sans les lire.
Gérer l’ambiguïté
« Vous recevez une demande de fonctionnalité d’une ligne d’un fondateur : “ajouter le soutien des équipes”. Que se passe-t-il ensuite? »
Forte : une liste de questions pointues (que possède une équipe, qui peut inviter, qu’est-ce qui change pour la facturation et les permissions), puis une première tranche mince pour valider avant de bâtir le modèle complet. Faible : commence immédiatement à concevoir des tables de base de données, ou attend passivement un devis complet.
Comment mener l’entrevue
Choisissez cinq à six questions couvrant au moins quatre des thèmes ci-dessus, pas toutes. Laissez chaque réponse se dérouler et demandez « pourquoi » deux fois avant de passer à la suite, parce que le deuxième pourquoi est là où les réponses répétées s’épuisent. Prenez des notes sur le raisonnement, pas sur les conclusions : un candidat peut avoir une opinion différente de la vôtre et démontrer quand même un excellent jugement pour y arriver.
Le raccourci
Ces questions fonctionnent, mais bien les mener exige des intervieweurs calibrés et de vraies heures par candidat. Un réseau vérifié a déjà mené cette évaluation avant que vous voyiez un profil, alors votre entrevue peut se concentrer sur l’adéquation avec votre produit et votre équipe. Peu importe la voie choisie, embauchez le raisonnement, pas le CV.
Questions fréquentes
Les entrevues d'ingénieur sénior devraient-elles inclure du code en direct?
Un court exercice pratique est utile, mais pour les postes séniors, la conversation sur les décisions passées compte davantage. La valeur d'un ingénieur sénior, c'est le jugement sous contraintes, et on le teste en sondant les vraies décisions qu'il a prises, pas en le regardant inverser un arbre binaire.
De combien de rondes d'entrevue un ingénieur sénior a-t-il besoin?
Deux à trois rondes ciblées suffisent : une conversation technique en profondeur, un exercice pratique ou une session de conception de systèmes, et une sur la collaboration et le style de travail. Plus de rondes ajoutent des coûts et des abandons de candidats sans ajouter de signal.
Quel est le plus grand signal d'alarme dans une entrevue d'ingénieur sénior?
Aucun échec assumé. Un candidat qui ne peut nommer ni une décision ratée, ni un bogue qu'il a causé, ni un compromis qu'il regrette n'a soit jamais porté de vraie responsabilité, soit ne sera pas honnête avec vous quand ça comptera.