Rédiger un bon quiz technique

1. Décider ce que le quiz doit mesurer

Partez du poste, pas d'une banque de questions. Pour « Développeur fullstack React/.NET », listez deux ou trois compétences que le quiz peut vérifier seul, avant l'entretien : une notion de base du langage, la lecture d'un morceau de code, un petit problème à résoudre. Ce qui demande une discussion (conception, travail en équipe) a sa place en entretien, pas dans un questionnaire.

Dans Candidia, le quiz est une étape du parcours d'entretien. Vous pouvez saisir les questions à la main ou demander à l'IA d'en proposer d'après le poste et, quand elle existe, le résumé de la phase source du quiz. Les questions proposées ne partent jamais seules : vous les relisez, les gardez, les réécrivez ou les supprimez avant d'enregistrer.

2. Garder peu de questions, une par critère

Chaque question doit mesurer une seule chose. Si vous ne savez pas dire quel critère elle éclaire, retirez-la. Un quiz court se termine, se corrige et se compare ; la suggestion de Candidia vise d'ailleurs entre 5 et 8 questions au total, avec au plus deux exercices de code. Mélangez les formats selon ce que vous voulez voir : le QCM vérifie des connaissances précises et se corrige automatiquement, l'exercice de code montre comment le candidat raisonne et écrit.

3. Graduer la difficulté

Commencez par des questions accessibles : elles mettent le candidat en confiance et écartent les profils clairement hors sujet. Placez les plus exigeantes ensuite. Pour un QCM, une seule option est correcte parmi plusieurs ; écrivez des mauvaises réponses plausibles, mais jamais ambiguës, sinon la question départage la chance plutôt que la compétence.

4. Écrire des énoncés clairs, sans piège

Un énoncé se comprend à la première lecture : un contexte court, une consigne, un résultat attendu. Évitez les doubles négations et les formulations qui testent la lecture plus que la compétence. Pour un exercice de code, donnez le langage et précisez ce que le programme reçoit en entrée et doit afficher en sortie.

Chaque exercice de code se corrige avec des cas de test (une entrée et la sortie attendue). Vous pouvez en rendre jusqu'à deux visibles : le candidat voit alors un exemple « Entrée → Sortie » sous l'énoncé. Au moins un cas doit rester caché, sinon un candidat pourrait écrire les sorties attendues en dur sans résoudre le problème. Les cas cachés ne lui sont jamais montrés. Si vous partez d'une proposition de l'IA, relisez aussi les sorties attendues des cas de test : elles ne sont pas vérifiées avant de vous être proposées.

5. Prévoir un temps réaliste

Vous pouvez fixer une limite de temps par question, ou la laisser vide. Testez-vous sur chaque question : si vous mettez beaucoup de temps à répondre en connaissant la solution, Camille Rivoire n'y arrivera pas non plus dans le temps prévu. Côté candidat, le fonctionnement est annoncé avant de commencer : une question à la fois, sans retour en arrière une fois la question validée, avec un temps et une échéance globale comptés par le serveur, pas par le navigateur. Prévenez simplement votre candidat avant l'envoi du lien.

6. Relire la correction, puis noter

Le candidat reçoit un lien et répond sans créer de compte ; Candidia ne l'envoie pas par e-mail, c'est vous qui le lui transmettez. Aucun score ne lui est affiché. À la soumission, les QCM sont corrigés automatiquement. Le code est corrigé en tâche de fond : il est exécuté contre les cas de test, visibles et cachés, et produit un score suggéré, jamais additionné au score des QCM. Le recruteur le lit, le confirme ou l'ajuste lui-même : la machine propose, c'est vous qui validez et qui notez.

Erreurs fréquentes

• Empiler des questions : le quiz devient long, la qualité de réponse baisse et le tri se complique.
• Poser une question qui ne se rattache à aucun critère du poste.
• Rédiger un énoncé ambigu ou un piège de formulation plutôt qu'un vrai problème.
• Rendre tous les cas de test visibles, ce qui permet de contourner l'exercice.
• Envoyer des questions proposées par l'IA sans les relire, sorties attendues comprises.
• Traiter le score suggéré du code comme une décision au lieu de le confirmer ou de l'ajuster.