L'intérêt de réaliser des tests d'embauche intelligents

Le 03 novembre 2006 à 00h10 | Publié sous | 11 commentaires

Ce billet fait suite à un certain nombre d’expériences malheureuses et conversations survenues ces deux dernières années, dont les plus récentes entre autres avec Mathieu Pillard. Rendons à César ce qui est à César, je râle suffisamment quand on ne me le fait pas.

Je ne sais pas si vous avez remarqué la quantité de gens qui se présentent à des entretiens d’embauche – ou que des sociétés de service peu scrupuleuses vous présentent comme les plus fines gâchettes de la profession – sans avoir jamais développé une ligne du langage dont ils se prétendent pourtant spécialistes. Je me souviens un jour avoir entendu un commercial tentant de vendre un stagiaire technicien réseau au CV maquillé comme une voiture volée en tant que développeur PHP expérimenté. Il clamait à qui voulait bien l’entendre : “Il a déjà fait un site perso en HTML, le PHP c’est facile, n’importe quel imbécile peut en faire, il y a suffisamment de documentation et d’exemples sur Internet, il fera l’affaire”. Deux semaines plus tard, le garçon se faisait dégager de la mission avec pertes et fracas.

C’est sans doutes à cause de ce genre d’anecdote que je crois fermement qu’un simple entretien technique ne suffit pas à déterminer le niveau réel d’un développeur. Un test pratique représente la solution à la fois la plus efficace et la plus intéressante, pour peu, évidemment, qu’il soit mené intelligemment.

Il y a deux ans, j’avais assisté à la mise en place d’une batterie de tests techniques à destination des postulants avec la philosophie de laquelle j’avais du mal à m’accorder.

Dans un premier temps, le candidat devait, en deux heures de temps, développer une petite application simple en PHP, comme un carnet d’adresses, une interface de vente de voitures, ou un annuaire simple. Il s’agissait avant tout de tester ses capacités de “machine à pisser du code”, plus que son degré de réflexion et d’abstraction. Curieusement, sur parfois une trentaine de candidats présentés par des sociétés de service, seuls deux ou trois pouvaient prétendre à passer la seconde partie du test. Seconde partie qui consistait en l’intégration d’un nouveau module dans une application effroyablement compliquée, bourrée de bugs aléatoires, codée avec les pieds par un unijambiste parkinsonien, et reposant sur un moteur de template interne non documenté. Pendant ce temps, certains membres de l’équipe passaient derrière le courageux postulant, regardaient son travail et émettaient des réflexions pas toujours très agréables à son propos. Après ma sortie, je me suis sincèrement demandé s’ils cherchaient un développeur ou un mélange entre Mac Gyver et un bonze tibétain pour les capacités de concentration en milieu particulièrement hostile.

Je trouvais cette manière de faire critiquable sur deux points :

Le premier projet était un exercice d’école basique, sans aucun lien ni dans l’esprit ni dans le domaine fonctionnel avec ce que le postulant aurait à développer par la suite. Malgré le peu de réussite, j’aurais aujourd’hui tendance à dire qu’il était trop facile, et ne correspondait pas aux contraintes techniques de la mission (php objet, javascript omniprésent, ajax partout pour des contraintes de bande passante). Le second projet était particulièrement difficile, trop même, et l’application à reprendre très loin de la moyenne des projets développés au sein de cette équipe. D’autant que l’utilisation du template maison nécessitait quelques jours de formation et d’adaptation en internet.

En un mot, le test visait à recruter des techniciens purs, capables de pondre, de lire et de reprendre du code très rapidement, mais sans aucune méthode ni réflexion, même si les développeurs rapides savent aussi souvent réfléchir à leur code. Cela va bien pour des applications simples, jetables, mais en aucun cas pour des projets complexes et destinés à évoluer dans le temps.

Plus le temps passe, et plus j’envisage le test d’embauche pour les développeurs comme un mélange intelligent de plusieurs éléments avec des coefficients différents :

  • Une partie purement technique, afin d’évaluer la connaissance du langage, sur 10 points. Le candidat doit développer quelque chose de simple, mais avec des contraintes particulières, notamment en termes de sécurité, de rapidité ou d’utilisabilité, toutes ces contraintes étant clairement exprimées dans l’énoncé de l’exercice.
  • Une partie méthodologie et compréhension sur 20 points. Celle-ci se traduit par une revue de code. Le code est revu avec le candidat qui explique sa démarche, et justifie ses choix.
  • Une partie “freestyle”, sur 5 points, qui récompense les candidats ayant dépassé les consignes de base afin d’offrir une application plus sexy, plus agréable à utiliser, ou fonctionnellement plus riche.

L’idée derrière cela est de laisser leur chance à des éléments parfois moins bons techniquement, mais intelligents, capables de réfléchir et d’évoluer avec une bonne tournure d’esprit, pour de les mélanger à des équipes plus expérimentés et leur permettre de parfaire leur technique. Parce qu’une équipe projet n’est pas seulement un investissement pour l’immédiat.

Commenter »

  1. mat about 4 hours later:

    Ca me rappelle quelquechose… Mais quoi ? :-)

  2. Frederic de Villamil about 8 hours later:

    Mat : ton horreur quotidienne probablement. Je te l’ai pourtant suffisamment dit : rejoins nous !

  3. thecaptain about 8 hours later:

    Hello Fred,

    Entièrement d’accord avec toi sur ce qui est des tests d’embauche ! Parfois c’est vraiment n’importe quoi… les gens ne veulent pas perdre de temps à préparer des tests donc ils prennent un truc au bol ou déjà existant loin de la réalité :( On avait eut un sujet à ce propos sur le forum flash de Media-Box où pour évaluer les qualités d’un candidats, on parlait de lui faire développer un truc simple sur une journée, réutilisable et demandant un peu de réflexion avant d’attaquer le code :)

    @++

  4. JMF about 9 hours later:

    J’ai expérimenté ce genre de test il y a quelques mois et je suis à présent totalement convaincu de leur utilité.

    J’ai d’ailleurs écrit un billet à ce propos qui raconte comment une prétendue “experte PHP” a été mise devant son incompétence par ce test.

    http://www.durcommefaire.net/2006/04/05/522-de-la-difficulte-de-recruter-un-developpeur

    PS : Ce n’est pas de la publicté déguisée pour mon blog. L’histoire est un peu longue et comme le billet existe déjà, je ne voyais pas l’intérêt de le copier/coller ici.

  5. Frédéric de Villamil about 10 hours later:

    TheCaptain : comme je l’expliquerai dans la version complétée de cet article – des idées de compléments et d’éclaircissements me sont venues ce matin – je ne pense pas qu’il faille passer plus d’une heure et demi sur le test, relecture de code comprise. On voit assez vite ce que peut faire le gars, et s’il répond aux exigences demandées. D’autant que le capital humain est souvent plus difficile à appréhender que le capital technique. Maintenant, des tests courts ne sont pas forcément envisageables en flash, je ne connais pas du tout ce domaine.
    En revanche, je suis parfaitement d’accord pour intégrer les développeurs en leur faisant développer quelque chose d’utile sur un à deux jours et basé sur le framework ou l’environnement maison.

    JMF: je ne considère pas ça comme un spam mais comme un trackback manuel, puisque les miens sont désactivés.

  6. Baptiste about 13 hours later:

    Je suis complètement d’accord avec toi sur le fond, mais noter les candidats je trouve ça déplacé… Tu embauches quelqu’un en fonction de ce que tu sens qu’il est capable de faire, en fonction bien sûr du test que tu lui fais subir, mais en fonction d’une note…

  7. Frederic de Villamil about 13 hours later:

    Baptiste : il ne s’agit pas d’une notation au sens scolaire du terme, mais du poids que tu attribues à chaque partie du test. C’est la raison pour laquelle je parle de coefficient. Et comme je l’explique dans le billet, la note purement technique est très loin de tout faire. L’appréciation humaine rentre énormément en ligne de compte, avec au bout, la grande question : au delà de ses compétences, est-ce que je me sens de faire bosser cette personne ?

  8. Benoit Perrotin 1 day later:

    Outre le fait de faire passer un entretien technique, tu pourrais effectuer comme plusieurs ssii comme Cadextan des formulaires à questions randomisées sur les connaissances visées par le développeur.

  9. mat 2 days later:

    Poser des questions, c’est un peu naze je trouve. Chez nous, on fait un test, on laisse l’acces à internet. Si un mec est bloqué il peut donc s’adapter en cherchant sur le net. Si il est capable de s’adapter ou si il réussit le test sans ca, ca revient au meme, ca montre qu’il est pas bete :-)

  10. Frédéric de Villamil 2 days later:

    Benoît : je ne veux pas savoir ce qu’il sait faire, pour ça, le test de code me suffit, mais comment il le fait. Comme le dit Mat, les connaissances pures se trouvent sur le web (ou dans le man), ce n’est donc pas le plus important.

    Un mec qui connaît toutes les fonctions PHP sur le bout des doigts mais qui est incapable de te résoudre les problèmes que tu lui soumets ne sert à rien.

  11. Pierre about 1 year later:

    Recruter LA bonne personne, compétente, impliqué, motivé et débrouillarde et difficile de nos jours.

    J’ai dut monter une équipe et travailler avec des programmeurs à peine sortie de l’école. Et bien c’est pas toujours ça. Ils ont de la rigueur sur les choses qu’ils ont déjà fait mais alors pour ce qui est de faire que ça marche à 100% et non pas à 90% c’est pas gagné ! Je ne comprend pas comment un développeur digne de ce nom peut ne pas tester ce qu’il code et corriger les erreurs les plus grosse avant de faire tester par quelqu’un d’extérieur (qui auras forcément une autre vision).

    J’ai aussi eu le cas d’un script à reprendre et à améliorer, c’est à dire vérifier que ce qui était en place était bon et fonctionnait tel que le cahier des charges le préciser, et ensuite ajouter des fonctionnalité tout en respectant l’architecture. Dans ce cas il n’y as eu aucun respect de l’architecture et encore moins de l’ergonomie générale de l’application (c’était du web). Il m’ont rajouté des informations sur un formulaire au début alors qu’elle était totalement secondaire sans se soucier un instant de l’utilisabilité d’un tel formulaire.

    Autre chose, quand ils étaient devant quelque chose qu’il connaissait ils étaient efficace, et produisait un code à peu prés potable (je dit à peu prés parce que je suis en ce moment même en train de repasser derrière et de faire un nettoyage monstre …), mais alors dés qu’une difficulté se présenté il ne savait plus comment réagir. ils essayait de se refiler la tache, de me poser la question (au cas ou je m’en soit pas rendus compte que je faisait le taff à leur place), quand je leur ai dit qu’internet existait et que les forums de développeur peuvent aider il ont pas été foutu de faire marcher quelque chose que j’ai réussi à faire marcher. Personnellement je pense pas être au dessus du lot, juste plus exigeant et que quand je programme je souhaite que ça marche, peut être que leurs volontés étaient pas assez fortes.

    Bilan : trois mois de boulot et un constat : une perte de temps malgré l’apport de plusieurs bonnes idées et d’un certains travail mais avec un arrière gout d’inachevé qui ne passe pas.

    Voilà c’est du vécu, la prochaine fois je serait plus exigeant sur les capacité des recrues à programmer correctement, à être exigeants avec eux même et à avoir une capacité d’adaptation et de résolution de bug efficace.

    Pierre

Laisser un commentaire

Merci de vous exprimer dans un français correct. Les commentaires déplacés, injurieux et le spam seront supprimés.

Les trackbacks sont fermés pour cause de spam.