Comment créer un test de programmation

What you'll need

• Un espace de travail SkillCort (ou une démo)
• Un exemple réel du code qu'écrit votre équipe — un bug, une petite fonctionnalité, un remaniement
• Un ingénieur expérimenté pour définir la tâche et la grille
• Une décision sur les langages que vous accepterez

Step 1: Préférez une tâche réaliste à une énigme algorithmique

Regardez vos pull requests du dernier mois et choisissez une tâche de la même forme que celles qui reviennent : corriger un bug à partir d'un comportement fautif, étendre une petite fonction pour traiter un nouveau cas, remanier un bloc mal écrit ou écrire une transformation de données. Ces tâches annoncent bien mieux la performance quotidienne que l'inversion d'un arbre binaire.

Dimensionnez-la à 30–45 minutes de travail concentré pour une recrue compétente. Une énigme récompense celui qui l'a répétée ; une petite tâche réaliste récompense celui qui sait lire l'intention existante, faire une modification saine et garder le code compréhensible — ce pour quoi vous recrutez.

Retirez les connaissances propres à un framework ou à l'entreprise, à moins que le poste ne les exige vraiment, et fournissez dans l'énoncé lui-même tout le contexte dont la tâche a besoin. Un bon ingénieur qui n'a jamais touché à votre pile technique doit tout de même pouvoir vous montrer un jugement sain. Testez le savoir-faire, pas la familiarité avec les détails de votre base de code.

• Revient dans votre vraie base de code, pas dans les manuels de préparation aux entretiens
• Admet plus d'une solution raisonnable
• Tient en 30–45 minutes sans exploit
• Lisible par un évaluateur en moins de dix minutes

Step 2: Créez l'item de code dans la bibliothèque d'items

Créez un dossier pour le poste — Ingénieur backend, par exemple — avec des tags pour le domaine de savoir-faire et la difficulté, puis créez un item en utilisant le type d'item code. Les candidats écrivent et modifient le code directement dans la zone de réponse, et les évaluateurs le relisent ensuite sur place.

Amorcez l'item avec un code de départ plutôt qu'un éditeur vide. Une courte fonction avec un bug décrit, ou une ébauche avec un contrat clair, fixe le même point de départ pour tous les candidats et rend leurs modifications directement comparables. Le travail réel ne part presque jamais d'un fichier vide, et le test ne devrait pas non plus.

Step 3: Rédigez l'énoncé à côté de l'éditeur

Utilisez la mise en page à stimulus côte à côte : l'énoncé, les exigences et des exemples d'entrées et de sorties d'un côté, l'éditeur de code à côté. Le candidat ne s'éloigne jamais de la spécification pour écrire la solution — la même forme que le travail à partir d'un ticket dans un IDE.

Rédigez l'énoncé comme se lit un bon ticket : comportement actuel, comportement attendu, contraintes et deux ou trois exemples concrets. Indiquez explicitement ce qui vous importe — « du code qui marche d'abord ; nous lisons aussi pour la clarté » — afin que les candidats optimisent ce que vous noterez réellement. L'ambiguïté de l'énoncé devient du bruit dans les résultats.

Step 4: Construisez une grille qui note plus que la justesse

Une sortie correcte est nécessaire, pas suffisante. Construisez une grille matricielle par niveaux avec trois ou quatre critères — typiquement la justesse, la lisibilité et l'approche, éventuellement le traitement des cas limites — chacun avec des descriptions ancrées de ce qu'est un code solide, acceptable et faible. « Les noms révèlent l'intention, aucun code mort » est notable ; « du code propre » ne l'est pas.

Donnez le poids le plus lourd à la justesse, mais gardez les autres critères réels : une solution qui fonctionne à peine et que personne ne peut maintenir n'est pas un bon signal de recrutement. Lorsque vous rattachez la grille, elle se fige en instantané, si bien que chaque candidat de la session est relu selon un standard identique même si la version en banque évolue ensuite.

Step 5: Assemblez et bornez le temps dans le constructeur

Créez l'évaluation en sections, pages et blocs et importez l'item de code via la fenêtre de sélection. Beaucoup d'équipes ajoutent une courte première section de questions de jugement rapides — lire un diff, repérer le bug dans un extrait, collés rapidement en choix multiple — et placent la tâche de programmation dans sa propre section.

Fixez la durée totale avec du jeu pour la lecture et la réflexion, et utilisez une limite par page sur la page de programmation pour que la tâche ne puisse pas engloutir toute la tentative. Donnez le poids le plus lourd à la section de programmation (par exemple ×3) pour que l'adéquation au poste sur le Decision Board reflète le travail, pas l'échauffement. Rédigez des consignes qui nomment les langages autorisés et ce qui se passe à l'expiration du temps.

Step 6: Prévisualisez, validez la checklist et publiez

Utilisez Preview as candidate et tentez la tâche vous-même, ou mieux, faites-la tenter sans préparation par un ingénieur qui ne l'a pas rédigée. S'il termine en dix minutes, elle est trop facile ; s'il ne parvient pas à terminer dans la limite, assouplissez le périmètre ou le chronomètre. Corrigez l'énoncé partout où il a hésité.

Satisfaites ensuite la checklist de publication — elle bloque Publish tant que la notation, le chronométrage et les consignes ne sont pas complets. Un test de programmation avec une grille manquante ou une limite de temps non éprouvée ne devrait jamais atteindre un candidat, et la checklist fait en sorte qu'il ne le puisse pas.

Step 7: Réglez des contrôles d'intégrité proportionnés aux enjeux

Créez la diffusion avec un nom et une fenêtre temporelle, puis choisissez délibérément les options de sécurité. Pour une présélection de recrutement standard, le blocage du copier-coller et le verrouillage en plein écran avec une limite d'infraction sensée suffisent généralement. L'enregistrement de la webcam, l'enregistrement de l'écran, la détection de second écran et les vérifications d'identité existent pour les sessions réellement à fort enjeu — certification, tours finaux — pas comme réglages par défaut.

Tout ce que vous activez est annoncé à l'étape de consentement et de vérification préalable, avant que le candidat ne commence. Les signaux d'intégrité sont des marqueurs qu'une personne examine en contexte, jamais un motif de refus automatique — une sortie de plein écran peut être une notification, pas une fraude. La proportionnalité évite que de bons candidats ne renoncent face à un filet de surveillance.

Step 8: Relisez le code avec la grille, l'IA en appui

Les évaluateurs relisent chaque rendu avec la grille partagée, en cliquant sur la carte de niveau qui correspond au code pour chaque critère — justesse, lisibilité, approche. Mettre deux relecteurs sur les cas limites ou à fort enjeu garde le standard honnête, et comme tout le monde note avec le même instantané figé de grille, les désaccords apparaissent comme des écarts sur un critère précis plutôt que comme de vagues divergences d'intuition.

L'IA peut rédiger une synthèse du rendu et suggérer des notes au niveau des critères — un premier passage réellement utile sur du code, avec le modèle et sa version journalisés pour la trace. Mais un ingénieur nommé confirme ou corrige chaque note. Ici, l'IA est un appui à la décision, jamais celui qui décide : le jugement dont on répond sur le code d'un candidat est toujours humain.