L'épineux problème des questionnaires d'embauche

On lit souvent un peu tout et surtout n’importe quoi à propos à propos des entretiens d’embauche dans les NTIC, et le sujet des tests techniques n’est évidemment pas en restes. Entre les adeptes du test pratique comme seul déterminant possible de la valeur d’un candidat et les zélotes du QCM de 200 questions à réaliser en trente minutes, difficile de faire son choix. Toutes proportions raisonnables gardées, l’un et l’autre ont pourtant leurs avantages. Le test pratique vous permet de voir en peu de temps comment travaille votre candidat. Cependant, 3 requêtes dans une base de données ne garantissent pas la qualité du travail sur le long terme, ni les capacités de reprise d’une application complexe, ancienne, et développée par plusieurs personnes. Le QCM vous assure que votre développeur a un profil purement technique et qu’il a bien appris par coeur fr.php.net. Mais un développeur n’est pas (seulement) un pisseur de code, et rien ne vous garantit qu’il sera capable de réfléchir le jour où il sera confronté à un problème vraiment sérieux. Sans compter qu’on ne peut pas demander la même chose à quelqu’un qui sort de l’école et à un senior avec 10 ans d’expérience.

Ces derniers temps, j’ai pas mal réfléchi à ce que pourrait être le questionnaire technique “idéal”. Complément du test technique, il “idéal” pourra être donné aussi bien au junior qu’au senior, et me renseigner à la fois sur sa maîtrise du langage et sur ses capacités à réfléchir. Le candidat ne devra pas passer plus d’une demi-heure dessus, et il devra comporter une dizaine de questions très ouvertes afin de s’adapter à tous les niveaux. Un exemple de ce qu’on pourra y trouver serait comment vous connectez-vous à une base de données MySQL ? Cette question a ceci d’intéressant qu’elle appelle aussi bien la réponse mysql_pconnect() / mysql_select_db() que des considérations sur les librairies d’abstraction de base de données.

Dans tous les cas, une fois posé le principe, le plus difficile est de trouver les questions poser.

Je ne dirais pas que KDE est bon à jeter, mais dans le doute, ils ont même prévu un Konqui recyclable

Si cet article vous a plu, n'hésitez pas à me suivre sur Twitter.

4 commentaires sur L'épineux problème des questionnaires d'embauche »

1. 

   Par Sly le 12 mars 2007 à 15h08 :

   
   

   A l’epoque ou les ecoles d’ingenieur se battaient pour recruter les etudiants, j’en ai reperee une avec un systeme de concours original. J’y suis pas alle et je me rappelle plus, mais c’etait sympa.

   Le matin, un prof faisait un cours sur un concept qu’aucun élève n’était censé avoir vu. Quelques notions, questions et éventuellement exos. L’après-midi, le concours se basait sur ce cours du matin.

   Tu peux réviser autant que tu veux, c’est même pas la peine. On recherche des gens intelligents et qui comprennent vite, pas des bachoteurs ! Ton problème est le meme, que ton candidat bachote son code ou le man PHP.

   C’est peut etre difficile a organiser en entreprise, mais a mon avis le resultat vaut le temps qu’on y passe. Par exemple, donner a quelqu’un du code d’un langage qu’il ne connait pas. Ou demander d’expliciter ce que fait un code avec des variables non explicites (ce que fait Sun dans ses pubs de recrutement).

   Ou encore, on adapte l’idée du domaine universitaire au technique, comme j’ai fait durant les premiers jours de mon stage : on te montre du code buggué dans un langage/framework que tu ne connais pas, et on voit si tu as assez de culture pour - deviner ce que ca fait - deviner comment le langage/framework fonctionne - comprendre le message d’erreur - comprendre d’ou vient l’erreur [1] - utiliser le code existant pour inferer le fonctionnement.

   Ca a plusieurs avantages. Déjà, voir le candidat qui panique là-dessus (désolé monsieur, j’ai juste imprimé le man PHP dans le revers de ma veste), et celui qui se calme et aborde le problème d’une manière qui te plait. Ca montre aussi celui qui apprend vite. Le [1] permet aussi de voir les gens avec une expérience en prog. Il y a des bugs “classiques” (genre une mauvaise init, un dangling else, un test mal fait…) qui reviennent un peu partout.

   Pour l’adapter a un informaticien, je dirais par exemple de lui filer du code Lisp. Il y a peu de lisp-hackers. Et si ton candidat en est-un, c’est pas grave qu’il soit avantagé, c’est certainement une preuve qu’il est geek, curieux, intelligent, et ouvert à plusieurs paradigmes de programmation :)

2. 

   Par FlorentG le 14 mars 2007 à 11h25 :

   
   

   Je suis aussi chaud pour le “code dans un langage inconu.” Tu files un bout de code, soit buggé, soit auquel il faut ajouter une fonctionnalité, un bout de manuel, et hop !

   Pisser de la ligne, tout le monde peut faire, mais réagir face à une situation inconnue qui demande de s’auto-former en un temps extrêmement court, ça sera plus dans le domaine de quelqu’un de compétent.

   Après aussi, le coup de la connexion à mysql pourrait arriver en second exo.

   Je donnerais un énoncé du genre “Connectez-vous à une base mysql, sélectionnez des données et affichez-les.” On verra tout de suite le gars qui rajoute un bête “or die(mysql_error())” après la connexion, et celui qui fera une gestion d’erreur un peu plus poussée… Pour l’affichage, on fera la distinction entre celui qui affiche un bête tableau html, et celui qui aura pensé à mettre un doctype :)

   J’ai un pote (qui passe par ici parfois) qui a fait un entretien, et il lui ont donné pour mission de faire une petite gestion de commentaire (style pour un blog) : ajout, prévisualitation, permalien et tout. A faire en 45 minutes, histoire de voir ce que le mec pouvait débiter, et jusqu’où ça pouvait aller dans la perfection (réutilisabilité, sécurité, etc.)

3. 

   Par Frédéric de Villamil le 14 mars 2007 à 11h49 :

   
   

   Florent: un pack de Kro que ton pote a postulé chez Téléfun pour être développeur de Skyblog

4. 

   Par Sophie Januel le 19 mars 2007 à 20h07 :

   
   

   Si tu complète la trame du test, je suis prête à t’enrôler comme “décrypteur analyste” j eme charge des tests de personnalitéet autres MBTI ;)

Trackbacks sur L'épineux problème des questionnaires d'embauche

Les trackbacks sont fermés pour cause de spam.