Créer une plateforme de test ou d'examen chronométrer en ligne

Bonjour,
je suis actuellement entrain de coder un site de recrutement (codeigniter) et j’ai déjà fini. mais un autre bloc viens de s’ajouter, un bloque qui nous permet d’évaluer tout ceux qui voudrons postuler à une offre, si l’utilisateur passe le test d’un temps précis donné et qu’il réussi, il pourra postuler à des offre dans le cas contraire non!!! donc je suis à la recherche d’un bloc de code ou de script ou n’importe quelle autre chose qui pourra m’aider à aller vite vu que je ne connais pas comment y arriver!!
merci à vous!

Un timer en Javascript ca peut pas faire l’affaire ?

  • tu met a jour le temps écoulé dans la session d’évaluation coté serveur via des appels Ajax à intervale régulier.
  • côté frontend, tu gère en Javascript (si page SPA ou sinon template serveur si MVC classique) le blocage de la page lorsque le temps est écoulé.

Merci @Joris mais j’ai pas du front end et du backend, c’est du codeignierter, donc je sais .

dis le deuxieme point, comment je le fais concretement? bloqué la page
merci
comment je gere la recharge de la page pour qu’il ne le recommence pas!!?

t’a des bout de code sous la main pour illustrer chaque partie? je suis un peu pratique là!!
merci

Si le temps imparti est dépassé dans ton objet Evaluation,
alors au lieu de renvoyer la page web de l’evaluation, ton CodeIgniter renvoit une page web qui contient juste un message informant l’utilisateur que le temps est écoulé et qu’il ne peut pas postuler.
Du coup c’est même encore plus simple que de le gérer en Javascript.
Et il peut recharger la page autant qu’il veut, ca change rien.

Ok merci à toi, @joris je vais l’essayer, si j’ai de souci je reviens!

Juste une question en dehors de la technique : on est d’accord que “évaluer sur la vitesse de code dans une condition de stress” est UNE compétence, mais pas forcément la plus souhaitable et la plus vérifiable ?

  • d’excellent-e-s devs seront disqualifié-e-s car trop lent-e-s
  • de mauvais-e-s devs pourront “tricher” (copier-coller de code, appel à un-e ami-e)
  • si quelque chose se passe mal techniquement on élimine aussi les gens

Ça me fait penser à 3 situations absurdes :

  • si ton entreprise veut embaucher une personne, dans un marché tendu comme le nôtre, noter la vitesse c’est se tirer une balle dans le pied : vous avez besoin de la personne, elle a besoin de vous, vous allez bien travailler ensemble… et on la refuse pour questions de rapidité ?

  • si je me mettais à récompenser la “vitesse” de mon médecin, ça veut dire que je finis avec des tonnes de médicaments, de béquilles et d’ablations (performance rapide), pas une connaissance précise du patient ni de la prévention long terme (qualité dans le bon contexte).

  • je n’ai jamais eu de cas où il faut “livrer vite sans se poser de question” et j’ai vu trop de projets souffrir ou mourir pour cause de “on a claqué tout l’argent à faire très vite ce qu’on sait faire mais on s’est jamais posé de questions”.

J’aimerais presque évaluer la compétence inverse : quand je te demande un truc simple, je veux “un bon mix” entre “je réfléchis et je demande au/à la chef les bonnes questions et le contexte minimal” et “je ne remets pas tout en cause : le/la chef prend 10mn pour déléguer 2h de travail, mais pas 2h d’explication pour 10mn de travail”.

1 « J'aime »

EDIT : je n’avais pas bien compris la question puisque le message précédent était une réponse à la vrai question (que je n’avais pas vu, en fait). Du coup, ici c’est un avis à la question « est-ce que évaluer la vitesse seule est une métrique pertinentes ». Désolé pour le H.S. par ailleurs s’il y a lieu, je file !

Une grille de lecture intéressante est celle apportée par les conclusions tirés de diverses expériences en psychologie cognitive.

De ce que j’en est compris, il est important de distinguer la « compétence » qui est ce que tu sais faire de la « performance » qui est ce que tu peux faire. Le lien entre « compétence » et « performance » est fait grâce au « contexte ».

Ici dans un « contexte de stress » il est sûr que les « performances » seront moins bonnes que dans un « contexte de non stress ». Cependant, en fonction des individus, certaines performances seront meilleures que d’autres.

D’après ce que tu expliques : tu préférerais faire des évaluation pour dégager une personne aux performances équilibrés entre tous les contextes possibles plutôt que tout miser sur quelque contexte qui semble important (résistance au stress) alors que les tâches d’un développeur demande bien plus que cela pour être faites correctement.

Dans tous les cas, je pense qu’il est souhaitable d’aménager l’environnement (processus, planning, etc.) pour réduire le contexte « stress » plutôt que de chercher des individus qui y résiste bien un temps si l’on souhaite les garder dans la durée.

Du coup pour répondre à la question que je devine car elle n’est pas clairement posée, de mon avis, le temps est une métrique pratique pour cadré l’exercice (plage horaires, estimations) mais bien entendu, seule, ne vaut pas grand chose.

Je laisse cette vidéo qui explique la nuance entre compétence et performance et qui donne des idées pour savoir comment évaluer les compétences au lieu des performances (ou l’inverse donc).

Ce post amène un débat très intéressant autour des critères de recrutement.
Je suis moi-même loin d’être convaincu par la pertinence de mesurer uniquement la vitesse à coder.
Sauf si le recruteur cible précisément un codeur purement exécutant.

Mais surtout la discussion s’intéresse plus au POURQUOI qu’au COMMENT initial.
Ce débat mérite d’être déplacé et continuer de vivre dans un post qui lui soit dédié.

Oui mais pas que :)

Autant je n’oblige pas quelqu’un d’être super rapide s’il est bon partout ailleurs, autant je n’oblige personne à être “bon partout”.

C’est un bon conseil pour vous en entretien et dans votre vie : soyez au courant de vos faiblesses et tentez de les gérer, mais mettez en avant vos forces et utilisez-les au mieux. (débats bonus : “comment se vendre en entretien”, “qui cherchez-vous quand vous cherchez la Nième personne de votre équipe” et “comment rédiger une bonne annonce et faire passer un bon entretien”)

C’est aussi un excellent conseil pour un manager (ou juste “la seule manière de survivre en tant que manager”) : il faut connaître les forces et les faiblesses de chacun, essayer de pallier les faiblesses (caricature : quand il faut parler au client, mettre l’asocial en binôme avec quelqu’un de sociable) et essayer de jouer sur les forces (caricature : mettre le sociable toujours en frontal avec le client et l’asocial sur des tâches complexes où il peut dépoter sans trop devoir parler aux gens).

C’est à la fois plus facile parce que tu as plein de gens dans ton équipe (tu peux répartir), et difficile parce que maintenant il faut gérer les sensibilités de chacun.
(débat bonus : comment rester “juste et cohérent” alors que tu parles à chacun de manière différente, comment “utiliser le style d’échange adapté à chacun-e” alors que tu veux rester juste et cohérent avec toutes et tous)

1 « J'aime »
Human Coders - Le centre de formation recommandé par les développeur·se·s pour les développeur·se·s