Recruter un backend sans lui demander d'inverser un arbre binaire
Un exercice tiré du produit, corrigé à deux, avec une grille écrite avant l'entretien. Ce qui change, et ce que ça coûte.
Je n'ai jamais eu besoin d'inverser un arbre binaire en production. J'ai eu besoin, souvent, de comprendre pourquoi une requête mettait huit secondes, et de le corriger sans casser le reste.
Ce sont deux compétences différentes. Une seule des deux prédit ce qui va se passer une fois la personne dans l'équipe.
Ce que teste réellement un exercice d'algorithmique
Il teste la préparation. Quelqu'un qui a passé trois mois sur des plateformes d'entraînement réussira ; quelqu'un qui maintient du code depuis cinq ans échouera peut-être.
Le signal est donc inversé pour un poste où on cherche justement de l'expérience de maintenance.
L'exercice que j'utilise
Un problème réellement rencontré, réduit à quatre heures. Par exemple :
Voici une API qui expose une liste de factures. Elle met 8 secondes à répondre en production sur un compte de 40 000 lignes. Le code, le schéma et un jeu de données sont fournis. Trouvez la cause, corrigez-la, expliquez votre raisonnement.
Ce que ça révèle, et qu'un algorithme ne révèle pas :
- Est-ce que la personne mesure avant de modifier, ou est-ce qu'elle devine ?
- Est-ce qu'elle regarde le plan d'exécution de la requête ?
- Est-ce qu'elle corrige la cause ou ajoute un cache par-dessus ?
- Est-ce qu'elle écrit un test qui échoue avant sa correction ?
- Est-ce qu'elle sait dire « je ne sais pas, voilà comment je chercherais » ?
La dernière ligne est celle qui compte le plus. Un développeur qui bluffe en entretien bluffera en revue de code.
Quatre heures, payées
L'exercice est plafonné et rémunéré. Deux raisons, et aucune n'est morale.
La première : un exercice non plafonné avantage ceux qui ont du temps libre. On sélectionne alors sur la situation personnelle, pas sur la compétence.
La seconde : un exercice payé est un exercice qu'on peut exiger sérieux. On ne demande pas un travail gratuit puis on s'étonne d'une copie bâclée.
La grille est écrite avant
Avant de publier l'offre, j'écris ce qui sera évalué et comment. Cinq critères, chacun noté de 0 à 3, avec une description de ce que vaut chaque niveau.
Écrire la grille après avoir lu les copies revient à choisir la personne qu'on préférait, puis à justifier. C'est exactement ainsi qu'on recrute les mêmes profils que soi.
Deux relecteurs, séparément
Chaque copie est corrigée par deux personnes qui ne se parlent pas avant d'avoir noté. Quand les notes divergent de plus d'un point, la discussion qui suit est la partie la plus utile du processus : elle révèle un désaccord sur ce qu'on attend du poste.
La question finale
Je termine toujours par la même :
« Racontez-moi une décision technique que vous regrettez. »
Une réponse honnête décrit un contexte, un arbitrage et une conséquence. Une réponse évasive — « j'aurais dû mieux documenter » — indique soit peu d'expérience, soit peu de recul. Les deux comptent.
Ce que ça coûte
Ce processus prend environ six heures de mon temps par candidat retenu en phase finale. C'est cher.
C'est aussi moins cher qu'un recrutement raté, qui coûte entre trois et six mois entre l'intégration, la constatation et la séparation — sans compter ce que ça fait à l'équipe.
À lire ensuite
Une deadline se négocie sur le périmètre, jamais sur la qualité
Ce qu'on sacrifie quand on accepte de livrer plus vite, et pourquoi ce n'est jamais la partie qu'on croit.
Tenir une base de code qu'on n'a pas écrite
Ce qu'on fait les trois premières semaines quand on hérite d'un système en production, avant de toucher à une seule ligne.
FastAPI en production : ce qui compte vraiment
Cinq réglages qu'on ne voit dans aucun tutoriel et qui font la différence entre une API qui tourne et une API qu'on peut exploiter.