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.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: