Évaluer un développeur senior : compétences, preuves et processus équitable

Pour bien évaluer un ingénieur logiciel senior, testez le travail, pas le CV. Définissez les compétences dont le poste a besoin, posez à chaque candidat les mêmes questions structurées, notées selon des critères écrits, et observez-le sur une partie réaliste du travail : écrire et tester du code, concevoir un système, relire la modification d'un autre. Des décennies de recherche montrent que les entretiens structurés et les tests propres au poste prédisent bien mieux la performance que les conversations libres, alors que les années d'expérience ne la prédisent presque pas.

Ce guide s'adresse aux CTO, responsables techniques et fondateurs qui recrutent des ingénieurs seniors, en interne ou via un partenaire. Il explique ce qu'est la compétence, ce que disent les preuves, un processus en cinq étapes tenant en une semaine, ce qu'il faut éviter, ce qui change dans les équipes germanophones et comment maintenir le niveau une fois la personne arrivée.

#Ce qu'est la compétence au-delà des années d'expérience

« Senior » sur un CV signifie souvent un nombre d'années. Dans une équipe, cela veut dire autre chose : la personne à qui l'on peut confier un problème flou et qui revient avec une solution qui fonctionne, testée et maintenable, après avoir posé les bonnes questions en chemin. Huit compétences décrivent cette personne. Notez celles qui comptent le plus pour votre poste avant de lire le moindre CV : cette liste devient votre plan d'entretien et votre grille d'évaluation.

Remarquez ce qui manque : des années sur un framework, des certifications, un diplôme. Ce peut être un contexte utile, mais rien de tout cela ne dit si la personne sait faire le travail pour lequel vous recrutez. Exiger un nombre d'années précis (« sept ans de Kotlin ») écarte en outre de solides ingénieurs qui ont appris le langage l'an dernier, après dix ans de bon travail backend.

#Ce que dit la recherche sur les méthodes de recrutement

La synthèse la plus citée de la recherche sur la sélection est celle de Schmidt et Hunter (1998), qui a rassemblé 85 ans d'études sur la capacité des méthodes de sélection à prédire la performance au travail. En 2022, Sackett, Zhang, Berry et Lievens ont revu ces estimations dans le Journal of Applied Psychology. Ils concluent que les corrections antérieures surestimaient la validité, abaissent la plupart des valeurs de 0,10 à 0,20 et placent désormais les entretiens structurés en tête.

Trois leçons en découlent pour recruter des ingénieurs. D'abord, la structure double à peu près la valeur d'un entretien : la même heure, avec les mêmes questions pour tous et des réponses notées selon des critères écrits, est environ deux fois plus corrélée à la performance ultérieure qu'une conversation libre. Ensuite, les meilleurs prédicteurs sont tous propres au poste : entretiens sur le travail réel, tests des connaissances nécessaires, échantillons du travail lui-même. Sackett et ses collègues le soulignent explicitement. Enfin, les années d'expérience ne prédisent presque rien à elles seules ; elles ne devraient donc pas servir de premier filtre.

#Un processus d'évaluation équitable pour les ingénieurs seniors

Le processus ci-dessous couvre les huit compétences en cinq étapes et demande au candidat quatre à six heures au total, réparties sur environ une semaine. Chaque étape a un objectif clair, des questions ou des tâches fixes et une grille que l'intervieweur remplit avant d'en parler à quiconque.

1. Entretien structuré (60 minutes)

Posez à chaque candidat les mêmes cinq ou six questions sur des situations réelles passées, avec des relances prévues à l'avance. « Racontez un incident de production dont vous vous êtes occupé de l'alerte à la correction. Qu'avez-vous changé ensuite ? » mesure le sens des responsabilités. « Décrivez une décision technique contre laquelle vous avez argumenté et perdu. Que s'est-il passé ? » mesure la communication et le jugement. Notez chaque réponse sur une échelle de 1 à 4, avec des exemples écrits de ce qu'est un 2 et un 4, pour que deux intervieweurs entendent la même chose par « solide ».

2. Mise en situation réaliste ou session de pair programming (90 à 120 minutes)

Proposez une petite tâche autonome tirée de votre domaine réel : ajouter une fonctionnalité dans un dépôt préparé, réparer un test qui échoue, étendre un endpoint d'API. Menez-la en direct en pair programming avec l'un de vos ingénieurs, dans l'éditeur du candidat s'il le préfère. Vous voyez comment il lit un code inconnu, pose des questions, teste et explique. Le candidat voit en retour comment travaille votre équipe, ce qui fait aussi partie d'un processus équitable.

3. Échange de conception de systèmes (60 minutes)

Choisissez un système proche de ce que la personne construira : un service de réservation, une chaîne de facturation, un système de notifications. Partez des besoins et laissez le candidat poser ses questions sur la charge, les données et les pannes. Les bons profils seniors parlent d'arbitrages, de modèles de données, de ce qui se passe quand une dépendance tombe et de la façon dont ils livreraient puis feraient évoluer une première version. Notez le raisonnement, pas la ressemblance avec votre architecture.

4. Exercice de revue de code (45 minutes)

Montrez une pull request réaliste de 150 à 300 lignes contenant des problèmes volontaires : un contrôle d'autorisation manquant, un cas limite non testé, un nom trompeur, une requête dans une boucle. Demandez au candidat de la relire comme pour un collègue. Ce seul exercice révèle la qualité du code, les tests, la sensibilité à la sécurité et le ton. Ceux qui trouvent la faille de contrôle d'accès et formulent leurs commentaires avec bienveillance sont rares et précieux.

5. Références (deux appels de 20 minutes)

Parlez à deux personnes que le candidat a désignées, idéalement un ancien responsable et un pair, et uniquement avec son accord. Posez chaque fois les mêmes questions structurées : de quoi la personne était-elle responsable, comment gérait-elle un désaccord, retravailleriez-vous avec elle et dans quel rôle ? Les références changent rarement une décision à elles seules, mais elles peuvent confirmer ou lever un doute issu des autres étapes.

#Notation et décision d'embauche

La plupart des erreurs de recrutement ne viennent pas de mauvais entretiens mais d'une mauvaise réunion de décision, où la voix la plus forte ou la plus haut placée fait le résultat. Trois habitudes l'évitent. Les intervieweurs remettent leur grille avant la réunion et ne parlent pas du candidat entre eux auparavant. La réunion passe les compétences en revue une à une, avec des faits (« a manqué le contrôle d'autorisation, l'a trouvé après un indice ») plutôt que des adjectifs (« semblait brillant »). Et le responsable du recrutement décide par rapport au niveau fixé avant la recherche, pas par rapport aux autres candidats de la semaine.

Tenez le niveau même quand vous êtes pressé. Un poste vacant un mois de plus coûte moins cher qu'un ingénieur senior dont il faut se séparer au bout de six. Si personne n'atteint le niveau, vérifiez d'abord que ce niveau correspond au poste, plutôt que de l'abaisser pour le candidat suivant.

#Ce qu'il faut éviter

• Les énigmes et casse-tête. « Combien y a-t-il de fenêtres à New York ? » en dit peu sur l'ingénierie. Le responsable des ressources humaines de Google de l'époque a qualifié ces questions de « a complete waste of time » (ABC News, 2013), et Highhouse, Nye et Zhang (2018) les décrivent comme dépourvues de preuve de validité et déstabilisantes pour les candidats.
• Les longs tests non rémunérés à faire chez soi. Un test de plus de deux ou trois heures sélectionne sur le temps libre, pas sur la compétence, et beaucoup d'ingénieurs seniors avec un emploi et une famille déclinent. Gardez-les courts et bien cadrés, rémunérez le travail plus long ou remplacez-les par une session de pair programming en direct.
• Les questions d'algorithmique sans rapport avec le poste. Inverser un arbre binaire au tableau mesure l'entraînement aux entretiens. Sauf si le poste implique vraiment ce type de travail, testez les problèmes que la personne aura réellement à résoudre.
• Les discussions non structurées sur le « fit culturel ». Une conversation agréable sans questions fixes est la forme d'entretien la plus faible et la porte d'entrée des biais. Évaluez la collaboration et les valeurs avec des questions structurées, comme le reste.
• Un processus lent. Les bons profils seniors ont généralement plusieurs options. Bouclez l'ensemble en deux semaines environ et expliquez dès le départ ce que comprend chaque étape.

#Langue, collaboration et équité dans les équipes DACH

Beaucoup d'équipes techniques en Allemagne, en Autriche et en Suisse travaillent en anglais alors que l'entreprise autour d'elles parle allemand. Déterminez la langue dont chaque partie du poste a réellement besoin et exprimez-la avec les niveaux du Cadre européen commun de référence pour les langues (CECRL) plutôt qu'avec « courant ». Un ingénieur dans une équipe anglophone n'a parfois besoin de l'allemand que pour le quotidien ; celui qui anime des ateliers avec des utilisateurs germanophones ou lit des spécifications en allemand en a besoin bien davantage. Évaluez la langue là où elle compte, par exemple en menant l'échange de conception de systèmes en allemand.

Les habitudes de travail comptent autant que la langue. Dans les équipes DACH, on attend souvent que les décisions soient écrites, validées puis tenues, et une critique directe en revue de code est normale. Demandez en entretien structuré comment le candidat gère un relecteur en désaccord et comment il documente une décision.

En Allemagne, un processus structuré est aussi votre meilleure protection. Selon la loi générale sur l'égalité de traitement (AGG), si un candidat écarté apporte des indices laissant présumer une discrimination fondée sur un motif protégé, c'est à l'employeur de prouver qu'il n'y en a pas eu (§ 22 AGG). Des questions écrites, des grilles et des décisions étayées le rendent possible. Les réclamations doivent être formulées par écrit dans les deux mois suivant la réception du refus, et l'indemnité d'un candidat qui n'aurait de toute façon pas été retenu est plafonnée à trois mois de salaire (§ 15 AGG).

Deux usages locaux concernent les références. En Allemagne, les salariés ont droit à un certificat de travail écrit à leur départ (Arbeitszeugnis), qui doit légalement être clair et ne contenir aucun message codé (§ 109 GewO) ; dans la pratique, ses formules toutes faites se lisent pourtant encore comme une échelle de notes, prenez-le donc comme un contexte, pas comme une preuve. Et ne contactez des référents qu'avec l'accord du candidat, de préférence des personnes qu'il a lui-même désignées, car vous collectez des données personnelles à son sujet.

#Maintenir le niveau après le premier jour

L'entretien fixe un plancher ; les habitudes quotidiennes de l'équipe fixent le vrai niveau. Un bon ingénieur dans une équipe sans revue, sans tests ni documentation finira par écrire du code comme tout le monde. Quatre habitudes maintiennent le niveau là où vous avez recruté.

• Une revue de code pour chaque modification. Les recommandations publiques de Google indiquent qu'un relecteur doit approuver une modification dès qu'elle améliore nettement la santé globale du code, même si elle n'est pas parfaite, et que les commentaires qui aident à apprendre sont toujours bienvenus. Cet équilibre garde la revue rapide et en fait un outil d'apprentissage.
• Du pair programming les premières semaines. Faites travailler la nouvelle recrue avec une personne expérimentée sur de vrais tickets. Cela transmet le savoir non écrit d'une base de code plus vite que n'importe quel document et vous montre tôt si le recrutement fonctionne.
• Les tests font partie du « terminé ». Une modification sans tests du comportement qu'elle ajoute n'est pas terminée. Des contrôles automatiques dans le pipeline en font une règle d'équipe plutôt qu'un débat personnel.
• Une documentation tenue à jour. Une courte vue d'ensemble de l'architecture, des registres de décisions pour les choix coûteux à défaire et des runbooks pour la production. Les nouveaux ingénieurs devraient les mettre à jour pendant leur intégration, ce qui est aussi le meilleur test de leur niveau.

Faites honnêtement le point sur le recrutement après le premier mois puis après le troisième, sur les mêmes compétences que celles évaluées. Si quelque chose ne fonctionne pas, dites-le tôt : c'est plus juste pour la personne comme pour l'équipe.

#Liste de contrôle pour recruter un ingénieur senior

#Comment nous choisissons nos ingénieurs chez Bespoke IT

Chez Bespoke IT, ce sont les ingénieurs qui construisent nos propres produits qui examinent chaque profil que nous proposons, et non un recruteur qui cherche des mots-clés dans un CV. Avant toute signature, vous rencontrez l'ingénieur lors d'une séance de travail sur votre propre problème et, si cela ne colle pas, nous proposons l'ingénieur suivant. Il travaille dans votre dépôt, avec vos outils et vos rituels. Découvrez notre offre de renfort d'équipe, estimez le coût d'une équipe ou dites-nous qui vous cherchez. Si vous hésitez entre une équipe junior plus nombreuse et une équipe senior plus restreinte, notre article sur pourquoi une équipe de développement senior examine les arbitrages.