Testez les consignes de votre exercice de code avant de recruter

Pour tester les consignes d’un exercice à réaliser chez soi, demandez à une personne qui n’a pas lu l’énoncé de suivre les étapes de préparation et de remise du travail prévues pour les candidats. Observez les moments où elle a besoin d’aide, consignez les obstacles involontaires, révisez le dossier, puis recommencez avec une autre personne. Gardez les compétences visées à l’esprit tout au long de l’exercice.

Le 11 octobre, Terence Eden a raconté comment il avait payé des personnes pour essayer de suivre son README. Il proposait 25 € pour une heure, observait les participants pendant qu’ils partageaient leur écran et exprimaient leur raisonnement à voix haute, puis révisait le document entre les séances. Il indique avoir dépensé environ 150 € au total. Cette expérience a révélé un mauvais lien de démonstration, des manipulations de fichiers peu claires, des termes inexpliqués et des sections présentées dans un ordre peu utile.

La discussion sur Hacker News porte sur la documentation logicielle. Eden n’a pas étudié le recrutement. Une équipe qui recrute peut reprendre cette démarche en essayant ses consignes avant de s’appuyer sur le travail des candidats pour les évaluer. Même un énoncé soigné peut masquer une autorisation manquante ou une dernière étape mal définie.

Que testent réellement les consignes de votre exercice à domicile ?

Décrivez la compétence visée avant d’organiser la séance d’essai. Ce repère vous permettra de déterminer si une difficulté fait partie de l’évaluation ou résulte d’un défaut évitable dans son organisation.

Prenons un exercice fictif de développement backend : ajouter un filtre à une petite API et protéger le comportement existant par des tests. Vous pourriez évaluer la façon dont le candidat comprend le code, choisit une modification, traite les cas limites et explique une décision. Ces objectifs d’évaluation sont plausibles s’ils correspondent au travail attendu pour le poste.

L’Office of Personnel Management des États-Unis décrit les échantillons de travail et simulations comme des tâches ressemblant aux activités réelles du poste. Ses recommandations distinguent aussi les compétences nécessaires dès la prise de poste de celles que l’employeur prévoit d’enseigner. Cela donne une question utile pour chaque prérequis : cette exigence correspond-elle à une compétence nécessaire dès l’arrivée ?

Lire du code inconnu peut en faire partie. Connaître la configuration de base de données non documentée de votre entreprise ne découle pas de cet objectif. Le débogage peut aussi être pertinent, mais vous devez décider si réparer un environnement de départ défectueux constitue la tâche de débogage. Une panne cachée modifie ce que l’exercice demande de démontrer.

Placez votre réponse à côté des critères d’évaluation. Pour l’API fictive, vous pourriez écrire : « Nous évaluons la justesse de la solution, le maintien du comportement existant, la pertinence des tests et votre explication des compromis. » Si l’interprétation d’une demande incomplète fait volontairement partie de l’exercice, précisez comment vous évaluerez les hypothèses des candidats.

La séance d’essai vérifie que le dossier permet de mener l’évaluation prévue. Un parcours réussi ne démontre pas que l’exercice prédit la performance professionnelle. Pour la conception de la tâche elle-même, consultez le guide consacré à la structure des exercices de code.

Donnez à une personne extérieure le véritable dossier candidat

Testez ensemble l’invitation, les accès, les consignes et la remise du travail. Envoyer uniquement le dépôt à un collègue laisse de côté les transitions où les candidats peuvent ne plus savoir quoi faire.

Choisissez une personne qui possède les compétences attendues à l’entrée et qui n’a ni rédigé ni relu le sujet. Un développeur d’un autre projet peut convenir. Une personne qui découvre la programmation pourrait révéler un problème de rédaction, mais sa difficulté à installer l’environnement d’exécution devrait être interprétée autrement pour un poste d’ingénieur senior.

Expliquez l’objectif avant de commencer : vous testez le dossier de l’exercice. Si vous recrutez une personne expressément pour cette séance, convenez avec elle du travail et de la rémunération. Le budget d’Eden décrit son expérience ; il ne constitue ni un tarif de référence ni une recommandation sur le nombre de participants. Ne transformez pas un candidat déjà engagé dans le recrutement en testeur d’utilisabilité non rémunéré sans le lui dire.

Donnez à cette personne les mêmes documents et autorisations que vous comptez fournir aux candidats :

• Le message d’invitation et les éventuelles consignes de préparation.
• Le résumé de la tâche, les consignes détaillées et les critères d’évaluation.
• L’accès au dépôt, les données fournies et les identifiants nécessaires.
• Le temps de travail estimé, l’échéance et l’événement qui déclenche le compte à rebours.
• Les règles concernant la documentation, les recherches, la collaboration et l’aide de l’IA.
• Le véritable mode de remise du travail et un contact pour les questions.

Utilisez un compte d’essai et des données adaptées à la séance. Si l’exercice exige un environnement particulier, fournissez-le explicitement. Si les candidats peuvent utiliser leur propre ordinateur, essayez la procédure documentée dans un environnement autorisé qui ne contient pas déjà les dépendances de votre équipe.

Avant de poursuivre, demandez à la personne de décrire ce qu’elle pense devoir produire. Consignez cette explication. Une interprétation différente peut révéler une exigence peu claire ou constituer un choix professionnel raisonnable dans la marge de liberté que vous souhaitiez accorder.

Pour une tâche de programmation, faites poursuivre le parcours jusqu’à ce que la personne puisse exécuter les tests de référence, apporter une petite modification pertinente et remettre son travail. Convenez de ce périmètre à l’avance. Vous devez observer le déroulement pratique sans exiger discrètement une solution complète non rémunérée.

Observez où les consignes ne suffisent plus

Consignez ce qui se passe avant d’expliquer ce que vous vouliez dire. Un indice peut être nécessaire, mais le besoin de cet indice fait partie des éléments que vous êtes venu recueillir.

Demandez à la personne d’exprimer son raisonnement à voix haute pendant le travail : quelle consigne elle suit, ce qu’elle attend d’une commande et où elle cherche l’action suivante. Évitez de lui commenter la page. Lorsqu’elle s’arrête, laissez-la expliquer cette pause avant de conclure à un problème.

Une pause pour réfléchir à la logique des filtres peut révéler un raisonnement utile. Une pause parce que le lien « dépôt de départ » ouvre une page inaccessible relève de l’organisation. Distinguez ces observations dans vos notes au lieu de les fondre dans un unique temps de réalisation.

Tenez un bref journal des blocages. Les entrées suivantes sont des exemples inventés pour l’exercice d’API, et non les résultats d’une étude sur le recrutement :

Ajoutez la commande, l’erreur ou la phrase nécessaire pour reproduire le problème. « L’installation était confuse » aide peu à agir. « La commande d’installation attend un nom de base de données absent de l’exemple de configuration » donne un point de départ à la personne chargée de la correction.

Si vous intervenez, notez l’aide apportée. Sinon, le résultat final peut donner l’impression que le dossier suffit alors que la séance a dépendu de vos explications. Considérez les observations à voix haute comme des éléments de diagnostic : être observé et parler à voix haute peut modifier la façon de travailler. Ces observations ne permettent pas d’estimer la performance habituelle des candidats.

Corrigez l’énoncé et testez les modifications

Corrigez la cause la plus précise que vous pouvez identifier, puis essayez le parcours révisé avec une personne qui ne connaît pas votre solution de contournement. La première personne connaît désormais des détails que le prochain candidat ignorera.

Pour l’exercice fictif d’API, le dossier initial indique : « Lancez l’application, ajoutez des filtres et envoyez votre solution. » La version révisée pourrait fournir un environnement d’exécution pris en charge, les commandes d’installation exactes, une commande pour les tests de référence, des exemples de données et le comportement attendu des filtres. Elle préciserait aussi la destination du travail et les critères d’évaluation.

Reliez ces corrections aux observations. Si la personne ne peut pas installer les dépendances, ajouter un paragraphe sur la culture d’entreprise ne résout pas le problème. Si les tests réussissent, mais que la personne ne trouve pas l’action de remise du travail, la correction doit porter sur cette transition.

Vérifiez vous-même les commandes avant une nouvelle séance d’observation. Suivez la procédure depuis une copie fraîche du dépôt, dans l’environnement documenté. Supprimez toute dépendance accidentelle à vos identifiants locaux, à des données en cache ou à une configuration non publiée. Des vérifications automatisées peuvent détecter des liens et des commandes défectueux ; elles ne peuvent pas dire comment une personne interprète « envoyez votre solution ».

Formulez une question précise pour le prochain essai. Par exemple : cette personne peut-elle exécuter les tests de référence avec le seul dossier et expliquer à quel moment son travail est officiellement remis ? Consignez l’observation dans le même journal au lieu de déclarer l’ensemble de l’exercice « validé ».

Retestez tout le parcours après avoir corrigé un blocage qui empêchait d’atteindre les étapes suivantes. Une invitation au dépôt corrigée peut révéler un problème d’installation que la première personne n’avait jamais rencontré. Arrêtez lorsque vous disposez d’assez d’éléments pour traiter les obstacles concrets observés, tout en reconnaissant les limites des environnements et des personnes couverts par vos essais.

Assurez des conditions et des précisions cohérentes pour les candidats

Finalisez le dossier avant d’inviter un groupe de candidats et communiquez les corrections importantes de façon cohérente. Modifier discrètement les exigences peut amener les évaluateurs à comparer des travaux produits dans des conditions différentes.

Conservez ensemble l’invitation, les consignes, la révision du dépôt de départ et la grille d’évaluation dans le document ou le dépôt déjà utilisé par votre équipe. Notez quelle version a été envoyée à chaque candidat. Il s’agit d’une pratique proposée pour organiser l’exercice, et non d’une affirmation selon laquelle la gestion des versions suffit à rendre une évaluation équitable.

Les recommandations de l’EEOC américaine sur les tests de recrutement et les procédures de sélection abordent la pertinence de l’objectif, l’organisation, la notation et la validation. Une séance avec une personne qui découvre les consignes constitue une vérification pratique. Elle ne remplit pas toutes ces obligations et ne démontre pas la conformité juridique.

Supposons qu’un candidat signale que les données fournies ne peuvent pas être chargées. Confirmez le problème, informez les autres candidats concernés de la correction et envisagez d’ajuster leurs échéances. Si le défaut a empêché quelqu’un de produire des éléments évaluables, examinez son effet avant de considérer le résultat manquant comme une insuffisance de compétence.

Distinguez les précisions logistiques des conseils sur la solution. « Le dépôt des fichiers se fait sur cette page » peut être communiqué à tous. Une discussion qui fournit une approche pour résoudre le problème central modifie l’aide reçue et doit être consignée à l’intention des évaluateurs.

Une fois les travaux remis, préservez le lien entre le dossier reçu et l’évaluation. L’évaluateur doit connaître les critères communiqués, y compris toute ambiguïté volontaire. Les questions posées ensuite en entretien sur une solution qui satisfait les critères relèvent d’une autre étape ; consultez l’entretien après la réussite de l’exercice.

Rendez les consignes accessibles à la personne qui les lit

Observez aussi la façon dont les personnes parcourent et lisent le dossier. Même une commande correcte reste difficile à utiliser si elle apparaît uniquement dans une capture d’écran ou sous un titre sans rapport.

Le tutoriel du W3C WAI sur les titres explique comment des titres structurés et explicites facilitent la navigation et la compréhension. Dans un exercice, des titres comme « Installation », « Comportement attendu » et « Remise du travail » donnent des repères utiles. Vérifiez le document tel qu’il est affiché, y compris les PDF ou les pages du dépôt que vous distribuez.

Fournissez les commandes sous forme de texte sélectionnable et copiable. Donnez aux liens des intitulés qui identifient leur destination. Vérifiez que les consignes importantes restent lisibles sur les appareils et dans les formats de document pris en charge. Si la page de remise du travail utilise des commandes d’interface, incluez leur utilisation au clavier dans la séance au lieu de supposer que la lecture de l’énoncé couvre toute l’expérience.

Proposez un moyen de contact avant le début de l’exercice. Dans ses recommandations américaines sur les candidats à l’emploi et l’ADA, l’EEOC explique que les employeurs peuvent décrire le processus de recrutement et demander si les candidats ont besoin d’un aménagement pour ce processus. Traitez les demandes par un canal privé approprié, sans inclure de détails sur le diagnostic médical dans les notes d’évaluation partagées.

Un essai avec une personne couvre son expérience. Il ne démontre ni l’accessibilité pour tous les utilisateurs ni une conformité complète aux WCAG. Pour la rédaction elle-même, le guide précédent sur les consignes claires pour les candidats traite des attentes, des échéances et des accusés de réception. Cette séance apporte des éléments sur la capacité d’une personne à suivre réellement le parcours configuré.

Conservez les consignes testées avec votre exercice dans Kit

Utilisez le véritable parcours candidat pour le dernier essai. Les champs et les aperçus vous aident à préparer le dossier ; suivre le parcours montre ce que ces réglages produisent en pratique.

Dans Kit Hiring, un exercice de code peut utiliser un dépôt GitHub privé créé à partir de votre modèle. Sa configuration comprend les consignes, le temps de travail estimé et les paramètres de durée. Le candidat connecte GitHub et reçoit une invitation au dépôt. L’acceptation de cette invitation déclenche le compte à rebours de l’exercice. La page candidat affiche ensuite les consignes et l’action de remise du travail ; une échéance finale ultérieure ferme la période autorisée en remettant automatiquement le travail.

Une mise en situation démarre autrement. Le candidat peut d’abord lire le résumé, puis cliquer sur Démarrer la tâche pour afficher l’énoncé privé et lancer le compte à rebours. Il dépose son résultat et reçoit un accusé de réception. Précisez ces différences lorsque vous testez votre propre tâche ; la documentation sur l’expérience candidat décrit les deux parcours.

Kit fournit le parcours de l’exercice. Votre équipe organise la séance avec une personne extérieure, consigne les blocages et décide quelles corrections préservent l’évaluation. Donnez à une personne qui n’a pas lu l’énoncé l’invitation que vous comptez envoyer, observez la préparation jusqu’à la remise du travail, puis corrigez et retestez les obstacles reproductibles. Faites-le avant que le premier candidat ait à les découvrir pour vous.