Sélection
Chaque ingénieur que nous proposons passe deux évaluations en direct de soixante minutes sur un vrai code : l'une sans outils d'IA, l'autre avec ses propres agents. Vous voyez les deux scorecards avant de le rencontrer.
-
01
Étape 1
Examen de la candidature
Du code livré, avec un historique de commits qui montre les itérations, en lien avec le poste et la stack. Pas de projets issus de tutoriels, ni de déclarations sur l'usage d'outils d'IA sans code à l'appui.
-
02
Étape 2
Appel de présentation
Répond à la question posée, pas à celle qu'il avait préparée.
-
03
Étape 3 · Évaluation 1
Évaluation des fondamentaux
Soixante minutes dans une base de code inconnue, outils d'IA désactivés. Cette étape montre si l'ingénieur sait lire un système, trouver le vrai problème et arbitrer seul entre plusieurs options.
Voir la fiche d'évaluation -
04
Étape 4 · Évaluation 2
Évaluation AI-native
Soixante minutes sur de nouveaux tickets, avec ses propres agents en marche. Cette étape montre comment l'ingénieur planifie le travail, vérifie ce que produit l'agent et décide de ce qui peut être livré sans risque.
Voir la fiche d'évaluation -
05
Étape 5
Entretien de direction et références
Pour les postes seniors et au contact des clients : un parcours cohérent devant deux interlocuteurs, confirmé par d'anciens managers.
-
06
Étape 6
Décision
Chaque scorecard est examinée dans son ensemble, avec une justification écrite. La forte impression d'un seul interviewer ne l'emporte pas sur une scorecard qui n'a pas atteint le seuil.
-
07
Étape 7
Sélectionnés pour une shortlist
Les ingénieurs qui réussissent toutes les étapes sont associés à vos postes et à votre stack, et vous recevez leurs scorecards avant de les rencontrer.
Obtenir une liste restreinte
Pourquoi nous avons abandonné les tests à domicile et les exercices de codage
Tous les tests à domicile se ressemblent désormais, car ils sont tous rédigés par des modèles. LeetCode mesure la mémorisation de schémas sous contrainte de temps. Aucun des deux ne révèle les fondamentaux, et aucun ne révèle les compétences avec les agents.
Nous avons donc remplacé les deux par deux évaluations en direct sur un vrai code : l'une sans agents, l'autre avec. Voici les scorecards que nous remplissons pour chaque ingénieur que nous proposons.
Évaluation 1 · Sans outils d'IA
L'évaluation des bases
L'ingénieur reçoit un codebase qu'il n'a jamais vu, quelques tickets dont un bug en production, et soixante minutes pour les traiter. La session se déroule comme une séance de travail ordinaire, sans aucun outil d'IA.
Voir la fiche d'évaluationÉvaluation 2 · Avec outils d'IA
L'évaluation AI-native
L'ingénieur reçoit de nouveaux tickets dans le même type de base de code, avec les outils de code IA qu'il utilise d'habitude. L'évaluation montre ce qu'il fait quand un agent réalise l'essentiel du travail : s'il planifie d'abord, s'il relit ce qui revient et s'il sait expliquer une modification qu'il n'a pas tapée lui-même.
Voir la fiche d'évaluationPourquoi les fondamentaux comptent encore avec les agents
L'ingénieur reçoit un codebase qu'il n'a jamais vu, quelques tickets dont un bug en production, et soixante minutes pour les traiter. La session se déroule comme une séance de travail ordinaire, sans aucun outil d'IA.
Ce à quoi ressemble une bonne pratique
- Lit le flux de données et les modes de défaillance avant de toucher au code
- Traite le bug en production en priorité et peut dire ce qu'il affecte
- Remonte du symptôme à la cause racine
- Ajoute le test qui aurait détecté le bug
Ce à quoi ressemble une mauvaise pratique
- Corrige le symptôme et passe à autre chose
- Traite chaque ticket comme s'il présentait le même niveau de risque
- Peut dire qu'un changement fonctionne, mais pas pourquoi
- Modifie du code partagé sans vérifier qui en dépend
La grille d'évaluation · six critères
Communication
Expose les compromis et dit ce qu'il n'a pas eu le temps de traiter, plutôt que de se taire. Pose des questions quand un ticket est ambigu au lieu de supposer.
Niveau d'anglais
Se fait comprendre et comprend, à l'oral comme à l'écrit. Sait défendre un point de vue et le maintenir face à une question de relance.
Priorisation
L'ordre dans lequel les tickets sont traités est cohérent avec l'urgence indiquée. Le bug en production passe toujours en premier.
Débogage
Trouve les causes racines de manière structurée, du symptôme à la cause, plutôt que par tâtonnement. Teste le correctif avant de le considérer comme terminé.
Hygiène lors des changements de contexte
Garde la trace des tickets ouverts et de leur état au moment du changement de contexte. Reprend une tâche sans avoir à tout relire.
Compréhension technique
Montre sa maîtrise de la stack, des flux complexes de l'application et du terminal. Lance l'application et examine la base de code avant de modifier quoi que ce soit.
Les agents construisent tout ce que vous leur donnez
L'ingénieur reçoit de nouveaux tickets dans le même type de base de code, avec les outils de code IA qu'il utilise d'habitude. L'évaluation montre ce qu'il fait quand un agent réalise l'essentiel du travail : s'il planifie d'abord, s'il relit ce qui revient et s'il sait expliquer une modification qu'il n'a pas tapée lui-même.
Ce à quoi ressemble une bonne pratique
- Consigne par écrit les hypothèses, les contraintes et les cas limites
- Signale tout changement touchant aux données, à l'authentification ou à la facturation
- Examine le diff et demande à l'agent pourquoi il a choisi cette approche
- Laisse quelque chose de réutilisable derrière lui
Ce à quoi ressemble une mauvaise pratique
- Le même niveau de revue pour une modification de texte et pour une migration
- « L'agent l'a fait » comme explication
- Reformule ses prompts au lieu de corriger le contexte
- Accepte un plan qui duplique ce qui existe déjà dans le dépôt
La grille d'évaluation · six critères
Vérification des sorties de l'IA
Détecte les API hallucidées, la logique subtilement erronée ou les failles de sécurité dans le code généré avant sa mise en production, plutôt que de lui faire confiance parce qu'il compile.
Orchestration des outils
Sait quand confier le travail à l'agent (scaffolding, code générique, tests) et quand coder manuellement (logique inédite, cas limites délicats), et fait tourner les deux en parallèle dans des worktrees.
Développement piloté par les spécifications
Décompose un ticket vague en éléments suffisamment petits pour que l'outil les exécute correctement, plutôt que de lui soumettre d'un coup l'ensemble de la demande ambiguë.
Ingénierie du prompt et du contexte
Configure le prompt et le contexte de la tâche pour que l'outil produise un résultat utilisable en une ou deux passes, au lieu de reformuler indéfiniment la même demande vague.
Débogage accéléré par l'IA
Utilise l'agent pour l'analyse des causes racines, le tri des logs et les stack traces, sans faire l'impasse sur l'étape de reproduction et de compréhension de la défaillance.
Hygiène lors des changements de contexte
L'hygiène du changement de contexte est notée de nouveau ici, avec des agents en cours d'exécution. Un bon ingénieur sait ce que fait chaque agent, revient au bon agent et ne laisse pas les notifications décider des changements.
Ce qui distingue les ingénieurs seniors des ingénieurs rapides
Elles ne tiennent pas dans une scorecard. Nous les repérons donc au fil des deux évaluations.
01
Jugement face au risque
Un changement de texte, un refactoring à faible risque et une migration de paiement ne méritent pas la même attention. Les bons ingénieurs accélèrent sur le premier et ralentissent vraiment sur le troisième. Les agents produisent les trois à la même vitesse et avec la même assurance.
Pendant l'évaluation
Le candidat lit-il le diff de migration ligne par ligne et survole-t-il le changement de texte ? Soulève-t-il la question du rayon d'impact avant nous ?
02
Responsabilité
Si vous fusionnez, vous en êtes responsable. Les tests, l'observabilité, le déploiement et le débogage après la mise en production font partie du travail, que le code ait été écrit par une personne ou par un agent.
Pendant l'évaluation
« L'agent l'a fait » n'est pas une explication que nous acceptons lors d'une évaluation, et votre équipe ne l'acceptera pas non plus lors d'une revue d'incident.
03
Effet de levier
Les meilleurs ingénieurs terminent le ticket et laissent le dépôt mieux préparé pour le prochain agent : une commande réutilisable, un CLAUDE.md plus précis, un test qui détecte toute une catégorie de bugs et pas seulement un cas isolé.
Pendant l'évaluation
Ce qu'ils ont produit pendant l'heure a-t-il facilité le ticket suivant, ou ont-ils laissé le dépôt exactement dans l'état où ils l'ont trouvé ?
Livre blanc
The Next 10X Engineer
Pourquoi les meilleurs ingénieurs écrivent désormais moins de code, et comment les distinguer des autres.
Quatorze pages rédigées par Bo Wesdorp, notre CTO : ce qu'est le métier aujourd'hui, ce que signifie AI-native, pourquoi l'ancien processus de recrutement ne fonctionnait plus, et les deux grilles d'évaluation complètes.
Questions fréquentes
Si la vôtre n'est pas ici, nous sommes disponibles pour vous aider.
Contactez-nousPubliez-vous votre méthode d'évaluation ?
Oui. Les deux évaluations, ce qui distingue une bonne réponse d'une mauvaise, et les douze critères des deux scorecards figurent sur cette page et dans le livre blanc The Next 10X Engineer.
Puis-je consulter les résultats d'un candidat ?
Oui. Chaque ingénieur présélectionné est accompagné des deux grilles d'évaluation complétées. Vous les consultez avant de rencontrer qui que ce soit.
Qui mène les évaluations ?
Des ingénieurs seniors, qui développent chaque jour des logiciels en production avec ces outils, mènent les deux évaluations. Les recruteurs ne notent pas les candidats.
Pourquoi ne pas recourir à un test à domicile ou à un test de code ?
Tous les tests à domicile sont aujourd'hui rédigés par des modèles, et les tests de type LeetCode mesurent la mémorisation de schémas sous contrainte de temps. Aucun des deux ne révèle ni les fondamentaux ni les compétences avec les agents.
Consultez les fiches d'évaluation avant de rencontrer qui que ce soit
Indiquez-nous le rôle. Nous vous envoyons des ingénieurs identifiés avec les deux grilles d'évaluation complétées dans un délai de cinq jours ouvrés.
ISO 27001Certifié