Votre processus d’entretien vous ment. CTF, LeetCode, trivia — les LLM de pointe les réussissent désormais. Même la communauté sécurité l’admet : les formats CTF ouverts se font laminer par des modèles généralistes. Et ce n’est pas que la sécurité — des lieux de recherche comme arXiv durcissent leurs politiques, avec des suspensions d’un an rapportées pour des auteurs qui déversent du contenu généré par IA sans supervision. Le signal que vous pensiez obtenir via des puzzles standardisés a disparu.
Si vous recrutez des ingénieurs seniors — aux US ou en nearshore — vous n’avez pas besoin d’un meilleur puzzle. Vous avez besoin d’un processus qui mesure les deux seules choses qui prédisent encore les résultats à l’ère des agents : comment un humain conçoit avec ses outils (IA comprise), et comment il se comporte sous de vraies contraintes systèmes.
Ce qui a changé (et pourquoi votre boucle doit changer)
- Les LLM de pointe résolvent désormais de façon fiable les problèmes « cannés ». Ils déroulent des casse‑têtes en bytecode, inversent des chaînes en assembleur et régurgitent des solutions canoniques avec de légères variantes. Ce n’est pas de la triche ; c’est le nouveau baseline.
- Les gatekeepers réagissent. Voir la couverture du durcissement d’arXiv contre la sur‑utilisation d’IA par des auteurs. Les institutions déplacent la ligne de « l’IA est une nouveauté » à « l’IA est un outil ; votre jugement est le produit ». Votre processus d’entretien doit évoluer de la même façon.
- L’environnement des candidats est saturé d’IA. Les IDE auto‑suggèrent, les navigateurs embarquent des assistants, et les téléphones servent de sidecars. Si votre boucle suppose une isolation de l’IA, elle mesure des compétences de musée.
Cela ne veut pas dire que vous devez hausser les épaules et laisser un bot passer votre pré‑qualification. Cela signifie que vous devez reconcevoir le processus pour capter le jugement, la pensée systèmes et la collaboration — en modélisant explicitement l’IA comme partie de la toolchain.
Un cadre de décision pour des entretiens robustes à l’IA
Avant les tactiques, décidez de votre posture sur l’usage de l’IA pendant les entretiens. Il n’y a que trois positions cohérentes.
1) Interdire l’IA pendant l’évaluation
Quand choisir : Vous recrutez pour de la recherche noyau en sécurité, des compilateurs, du code critique pour la sûreté, ou des rôles où la provenance et l’auteur individuel sont non négociables.
Avantages : Protocole clair. Auteurs plus faciles à attribuer.
Inconvénients : Réalisme moindre. Vous rejetterez de très bons ingénieurs qui excellent avec des outils. Vous incitez aussi à l’usage clandestin et aux comportements adversariaux.
Comment le rendre équitable : Fournissez un environnement de dev instrumenté, hors‑ligne, avec documentation et manpages complètes. Énoncez l’interdiction explicitement et expliquez pourquoi. Gardez les tâches courtes (≤ 90 minutes) pour éviter la « fatigue d’outils ».
2) Autoriser l’IA avec transparence
Quand choisir : La plupart des équipes produit et plateforme. Vous vous attendez à ce que les ingénieurs utilisent des assistants mais vous voulez voir leur jugement et leur boucle de vérification.
Avantages : Signal réaliste. Vous observez comment les candidats rédigent des prompts, critiquent, testent et intègrent.
Inconvénients : Vous devez instrumenter pour les étapes de vérification et le « trust but verify », pas seulement le code final.
Comment le rendre équitable : Demandez aux candidats de raconter comment ils ont utilisé l’IA. Notez la validation, pas l’évitement de l’IA. Laissez à disposition des tests unitaires locaux et des linters. Interdisez de coller des prompts confidentiels de l’entreprise dans des outils externes.
3) Exiger l’IA
Quand choisir : Rôles explicitement centrés sur des workflows agentiques, la navigation de codebase avec assistants, ou des outils internes où la maîtrise de l’IA est un multiplicateur clé.
Avantages : Vous testez la compétence moderne exacte : orchestrer l’IA pour produire du travail utile avec un haut niveau de confiance.
Inconvénients : Vous pouvez écarter d’excellents ingénieurs low‑tooling. Offrez une voie alternative pour des profils exceptionnels.
Comment le rendre équitable : Standardisez sur un assistant fourni, avec la même fenêtre de contexte et les mêmes plugins pour tous les candidats. Évaluez l’ingénierie de prompts, l’usage du retrieval et la conception de garde‑fous.
Arrêtez de noter des puzzles. Évaluez l’ingénierie.
Voici la boucle que nous déployons pour des candidats seniors aux US et au Brazil qui construisent des backends SaaS et IA de production. Elle est robuste à l’IA car elle mesure comment quelqu’un construit, raisonne et vérifie — outils inclus. Temps total pour le candidat : 3 heures. Temps total du panel : ~3,5 heures. Délai cible jusqu’à l’offre : 7 jours ouvrés.
Étape 1 : étude d’architecture de 30 minutes (tableau blanc, pas d’IDE)
- Prompt : « Concevez une chaîne d’ingestion et d’inférence minimale et résiliente pour des événements JSON en streaming à 5K/s, avec 99,9 % de disponibilité quotidienne et un plafond de coût de X $/jour. Supportez le backfill et l’idempotence. »
- Ce que vous notez : SLIs/SLOs clairs, stratégie de backpressure, choix de stockage chaud/tiède, effets exactly‑once, domaines de défaillance et raisonnement coût sous pics de trafic. Si le candidat saute directement vers des logos techno, ramenez‑le vers les budgets d’erreur et le flux de données.
- Posture IA : Sans objet. Il s’agit de pensée systèmes sous contraintes.
Étape 2 : 60 minutes de compréhension de dépôt et demande de changement
- Setup : Un repo épuré mais non jouet (1–3 services, 3–5K LOC) avec des bords manquants et un readme exact à 80 %. Fournissez un seul ticket : « Ajouter un endpoint pour X, idempotent et limité en débit, avec migration et rollback. »
- Environnement : Un devcontainer éphémère avec tests, linters, et un assistant optionnel et instrumenté. Enregistrez uniquement : exécutions de tests, diffs git, et historique de commandes du terminal. Aucune frappe clavier ni capture d’écran ; respectez la vie privée.
- Ce que vous notez : Stratégie de navigation, test‑first (ou test‑last, mais explicite), aptitude à trouver les coutures du changement, contrôles de sûreté (migrations, feature flags) et un diff borné. Bonus pour stabiliser un test flaky/instable ou améliorer un stub de doc.
- Posture IA : Autoriser avec transparence. Demandez : « Montrez une suggestion que vous avez acceptée et une que vous avez rejetée. Pourquoi ? » Vous mesurez le jugement, pas l’aversion.
Étape 3 : 45 minutes de drill incident prod
- Setup : Un bac à sable circonscrit avec un service à faible trafic qui contient un bug latent (fuite de ressource, course, ou cache stampede). Fournissez des logs, des métriques (snapshots Grafana) et un runbook ultra simple avec des trous.
- Prompt : « Vous êtes d’astreinte. Il est 11:07 AM ET. Le taux d’erreur est passé de 0,2 % à 3 % sur le write path. La page a sonné. Traitez le problème. »
- Ce que vous notez : Discipline d’hypothèses, expériences testables, usage de l’observabilité, communications claires (« Je fais un rollback dans 60 secondes sauf si X »), et containment. Correctif de code optionnel ; stabilisation obligatoire.
- Posture IA : Autorisez des assistants avec garde‑fous pour lire des stack traces ou de la doc, mais notez avant tout la boucle guidée par hypothèses et la discipline de rollback.
Étape 4 : 45 minutes de pairing avec un futur coéquipier
- Setup : Un vrai bug issu de votre backlog, cadré pour tenir dans la session. Votre ingénieur prend le lead 50 % du temps.
- Ce que vous notez : Style de collaboration, négociation des frontières (« on met un stub et on y revient »), et hygiène de code review. C’est ici que l’adéquation culturelle apparaît sans théâtre de la culture.
- Posture IA : Au choix du candidat. S’il fait appel à l’IA, observez comment il garde le binôme engagé et vérifie les changements.
Rubrique : arrêtez de moyenner des impressions
Définissez des pondérations et tenez‑vous‑y. Voici une répartition pragmatique pour des rôles backend ou plateforme seniors :
- Raisonnement systèmes (Étape 1) : 25 %
- Navigation codebase et changement sûr (Étape 2) : 35 %
- Jugement opérationnel (Étape 3) : 25 %
- Collaboration (Étape 4) : 15 %
Fournissez des ancrages précis, par exemple « Idempotence : 0 = pas mentionnée, 1 = mentionnée mais erronée, 2 = correcte au niveau du handler, 3 = correcte de bout en bout avec protection contre les replays et ID de déduplication. » Évitez les fourre‑tout du type « présence senior ».
Instrumentez pour des preuves, pas pour de la surveillance
Vous n’avez pas besoin de spyware pour que cela fonctionne. Vous avez besoin d’une traçabilité que vous pouvez discuter avec un candidat et revoir en interne.
- Collectez : diffs git, messages de commit, exécutions et couverture de tests, historique de terminal, et une courte réflexion post‑tâche (« Qu’avez‑vous essayé ? Qu’est‑ce qui vous a surpris ? Que feriez‑vous avec 2 heures de plus ? »).
- Ne collectez pas : frappes clavier, vidéo d’écran, ou historique de navigation. Outre les mines antipersonnel de la vie privée, rien de tout cela ne prédit la performance au travail aussi bien que diff + tests + narration.
- Signalez le code à « forme IA » : de gros diffs collés instantanément avec un style inhabituel sont un signal pour questionner la vérification et la compréhension. Traitez‑le comme une occasion de coaching, pas un traquenard.
Concevez des tâches où l’IA peut aider — sans pouvoir tout porter
De bonnes tâches ressemblent au travail réel de votre équipe, sous de vraies contraintes. Elles comportent aussi des éléments qui forcent le jugement humain :
- Ambiguïté à conséquences : Un readme qui ment sur un point petit mais crucial. Le candidat doit le remarquer, tester et corriger.
- Couplage caché : Une migration qui casse un job aval sans feature flag. Le candidat sait‑il anticiper et étager les changements ?
- Falaises de performance : Une approche naïve passe les tests mais explose à 10× la charge. Proposez un petit harnais de charge pour l’exposer.
- Archéologie de docs : Docs volontairement incomplètes. Inspirez‑vous de ce playbook d’archéologie du code : demandez au candidat d’inférer l’intention depuis le code, pas depuis des tutoriels.
À l’inverse, évitez les puzzles à solution canonique unique qu’un assistant peut déverser en bloc. Si vos testeurs internes peuvent le résoudre en moins de 5 minutes avec un prompt générique, mettez‑le à la poubelle.
Spécificités nearshore : Brazil et la réalité d’un recrutement distribué
Brazil vous offre 6–8 heures de recouvrement avec US Eastern and Central time, un vivier profond de devs seniors, et des taux typiquement 20–30 % sous le marché US. Votre boucle doit être aussi exigeante pour les candidats nearshore que pour ceux aux US, avec deux ajustements pratiques :
- Clarté de langue : Gardez des tâches en anglais clair, mais évitez des prompts lourds en culture ou argot. Si votre domaine produit est spécialisé, incluez un court glossaire au début.
- Parité de plateforme : Vérifiez que votre environnement éphémère tourne à l’identique sur les machines des candidats à travers OS et réalités de bande passante. Si vous fournissez un IDE dans le navigateur, testez‑le depuis São Paulo et Porto Alegre avec 2–5 Mb/s en upload.
N’ajoutez pas de cerceaux supplémentaires pour le nearshore. L’objectif, c’est la parité et la prédictibilité, pas de prouver sa valeur via la bureaucratie.
Maths de coûts et de débit (pour défendre cela auprès de votre CEO)
Supposez que le coût total moyen de votre panel est de 200–300 $/heure charges comprises aux US, et 90–150 $/heure en nearshore pour les ingénieurs qui participent aux entretiens. Une boucle classique en trois tours (recruteur, puzzle de code, conception système) consomme souvent 5–6 heures de temps panel par candidat et produit un taux onsite → offre de 10–15 %, avec beaucoup de faux négatifs pour les seniors.
La boucle robuste à l’IA ci‑dessus :
- Temps panel : ~3,5 heures par candidat (0,5 + 1,0 + 1,0 + 1,0), planifié serré.
- Temps candidat : 3 heures, tout en signal dense.
- Taux de passage attendu : 20–30 % onsite → offre pour des pipelines seniors bien sourcés.
- Réduction des faux négatifs : Nous observons systématiquement 25–40 % de « refus regrettés » en moins après rétro‑calibration, parce que vous cessez d’écarter des ingénieurs efficaces avec outils.
Même une amélioration de 10 % du taux de réussite s’amortit en 1–2 trimestres de productivité avancée du bon recrutement. Et ce, avant de compter les gains de NPS candidat (qui se traduisent par de meilleurs taux d’acceptation) quand vous supprimez des tours de puzzles éreintants.
Conformité, éthique et confiance des candidats
La transparence compte. Publiez votre politique IA dans l’invitation à l’entretien :
- Indiquez clairement si l’usage de l’IA est interdit, autorisé avec transparence, ou requis selon les étapes.
- Listez exactement quelles télémétries vous collectez et pendant combien de temps (p. ex., 30 jours). Promettez la suppression et tenez parole.
- Interdisez de coller des éléments confidentiels de l’entreprise dans des outils externes. Si vous autorisez l’IA, fournissez un assistant « jardin clos » ou imposez un contexte local uniquement.
Si votre juridique est nerveux, ne basculez pas par défaut vers la surveillance. Par défaut, limitez‑vous à des preuves à but précis et à une réflexion post‑tâche. Il est difficile de tricher sur la compréhension, surtout quand vos tâches sont complexes mais bornées et vos questions spécifiques.
Plan d’implémentation : 30/60/90
Jour 0–30 : Remplacez les puzzles par des tâches « produit »
- Forkez un service interne et réduisez‑le à un exercice de 3–5K LOC. Semez une migration, un test flaky, et une falaise de perf.
- Levez un devcontainer éphémère et un fallback IDE navigateur. Intégrez les tests et un petit harnais de charge.
- Rédigez la grille de notation avec ancrages. Faites trois pilotes avec vos propres seniors. Éliminez toute tâche qu’un LLM peut réussir en moins de 5 minutes.
Jour 31–60 : Publiez la politique IA et l’instrumentation
- Décidez, étape par étape, de la posture IA (interdire, autoriser, exiger). Publiez‑la.
- Instrumentez pour capturer diffs, tests, historique de terminal, et un court formulaire de réflexion. Pas de frappes clavier, pas de capture d’écran.
- Formez les interviewers à la nouvelle grille. Calibrez avec des dry‑runs enregistrés.
Jour 61–90 : Mesurez et itérez
- Suivez onsite → offre, temps jusqu’à décision, et taux d’acceptation. Demandez à chaque refus d’offre : le process était‑il équitable et pertinent ?
- Revoyez 10 boucles échouées aléatoires par mois. Identifiez les dérives de grille et les prompts ambigus. Corrigez‑les.
- Introduisez une variante par trimestre (p. ex., autre classe de bug à l’Étape 3) pour éviter le sur‑apprentissage et le risque de fuite.
Hygiène sécurité et IP pour des boucles où l’IA est autorisée
- Confidentialité : N’exposez jamais de vrais secrets ni de données de production. Utilisez des fixtures synthétiques ou nettoyées. Faites tourner tout jeton d’exemple après chaque session.
- Choix de modèle : Si vous fournissez un assistant, préférez une instance auto‑hébergée ou hébergée par un fournisseur avec des contrôles stricts de rétention des données. Coupez l’entraînement sur prompts et complétions.
- Notes de provenance : Si vous acceptez un take‑home, exigez un court CHANGELOG avec attributions (« J’ai utilisé l’assistant X pour Y ; j’ai copié Z depuis la doc ABC »). Cela encourage une divulgation honnête et donne du contexte aux relecteurs.
Et pour les rôles purement sécurité et les CTF cassés ?
Oui, l’IA de pointe a percé des trous dans les formats CTF ouverts. Si vous recrutez des ingénieurs sécurité, cessez de traiter les médailles CTF publiques comme un proxy de profondeur. Construisez des labs privés et étagés qui exigent de la planification du raisonnement, pas de l’exploitation par rappel de motifs :
- Niveau 1 : Recon et exploitation basiques contre des vulnérabilités connues et patchées. Time‑boxed. L’IA aidera — tant mieux.
- Niveau 2 : Service inconnu avec un défaut logique qui ne se révèle qu’à travers la corrélation de trafic et l’analyse de timeline de logs. Notez le journal d’enquête.
- Niveau 3 : Exercice blue‑team : proposez des garde‑fous (rate limits, règles IDS, canaris) et déployez‑les. Beaucoup d’attaquants ne savent pas défendre.
Encore une fois : mesurez le jugement, pas des payloads mémorisés.
Le point méta
La position d’arXiv est un miroir : ils n’interdisent pas les outils ; ils exigent de la gérance. Faites de même. Les candidats capables de tirer parti de l’IA tout en préservant justesse, coût et sûreté livreront plus de valeur, plus tôt. Ceux qui se cachent derrière des outils ou les rejettent d’emblée auront du mal. Votre boucle d’entretien devrait distinguer ces deux profils en trois heures, pas en trois semaines.
Points clés
- Les puzzles standard sont des signaux obsolètes ; les LLM les réussissent. Mesurez plutôt le jugement d’ingénierie sous de vraies contraintes.
- Choisissez une posture IA explicite par étape — interdire, autoriser, ou exiger — et publiez‑la aux candidats.
- Utilisez une boucle de 3 heures : étude d’architecture, demande de changement sur repo, drill d’incident, et session en binôme. Notez avec des grilles de notation à ancrages.
- Instrumentez pour les diffs, les tests et l’historique de terminal — pas les frappes clavier ni la capture d’écran. Respectez la vie privée ; obtenez un meilleur signal.
- Concevez des tâches où l’IA aide sans porter seule. Forcez le jugement humain via ambiguïtés, couplages et falaises de performance.
- Pour le nearshore (Brazil), visez la parité : anglais clair, environnements testés sur plateformes, et 6–8 heures de recouvrement avec US ET/CT.
- Attendez‑vous à 20–30 % d’onSite → offre pour des rôles seniors et 25–40 % de faux négatifs en moins en dépassant les puzzles.