L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

Au cours d'une récente discussion sur xp-france au sujet du recrutement de membres d'une équipe XP a été inévitablement évoqué la question de l'utilisation de tests techniques au cours de la procédure de recrutement.
Je reviens ici sur cette pratique qui me parait essentielle car elle permet d'en dire bien plus long sur une personne que la stricte évaluation des compétences techniques.
Il convient premièrement de clarifier ce que l'on entend par 'test technique'. Certaines sociétés font passer aux candidats des QCM contenant des questions plus ou moins débiles corrigées par un "ingénieur" commercial qui n'a probablement jamais vu une ligne de code de sa vie. J'ai eu, il y a fort longtemps, la chance de passer par là en tant que candidat et de me rendre compte à quel point une telle pratique est contre-productive : j'étais loin de connaître la réponse à toutes les questions mais j'étais sûr de moi sur une d'entre elles -- ce que j'ai pu vérifier en rentrant chez moi par la suite. Le problème c'est que la feuille de résultat qu'avait le gars entre les mains disait le contraire. J'ose à peine imaginer comment les choses peuvent se passer dans un tel cas si le candidat est un expert sur les questions techniques posées. Quelle chance a la société de recruter ce candidat quand il verra l'incompétence de ses interlocuteurs ?

Tout ça pour dire que les tests techniques sont un outil à manier avec précaution si on veut en retirer des informations pertinentes. Il faut savoir répondre aux attentes du candidat tout comme il faut savoir mettre le candidat en condition pour répondre au mieux aux attentes du recruteur. A ce titre, l'état de stress du candidat ne doit pas être agravé. Certaines personnes pensent d'ailleurs que cela suffit à justifier la non-utilisation de tests techniques.

En ce qui me concerne, j'ai toujours pris la précaution d'annoncer au candidat :

• qu'il y aurait une phase de test technique (annoncé dès le début de l'entretien donc largement avant le début de cette phase)


• que les tests techniques ne servent pas à tester des connaissances brutes mais à voir la façon de réagir du candidat face à tel ou tel problème


• que ne pas savoir résoudre un test ne porte pas forcément préjudice : les méthodes employées pour le résoudre, les questions que l'on se pose sont tout aussi importantes

Ceci étant acquis voici le genre de test que l'on peut poser à un candidat. En l'occurrence il s'agit de C++.


Que fait ce programme ?

#include <iostream>
#include <memory>

class A
{
public:
  ~A() { std::cout << 'A' << std::endl; }
};

class B : public A
{
public:
  ~B() { std::cout << 'B' << std::endl; }
};

void main()
{
  std::auto_ptr<A>( new B );
}


Je n'ai jamais posé ce test là (et je ne peux pas divulguer la plupart des tests que j'ai posés car je n'en suis pas l'auteur) mais je peux aisément prédire les diverses réactions que pourront avoir les candidats.

Certains d'entre eux resteront bloqués sur l'unique ligne de la fonction principale. L'auto_ptr n'est pas quelque chose de très bien connu pour 2 raisons :

• les vieux de la vieille du C++ connaissent généralement les notions de pointeurs intelligents mais ont souvent utilisé des classes faites maison pour les gérer


• les diplomés récents ont généralement fait beaucoup plus de java que de C++ et ont une facheuse tendance à écrire du C++ comme s'ils écrivaient du java

D'autres candidats ne se bloqueront pas sur cet auto_ptr qu'ils ne maîtrisent peut être pas. Ils verront immédiatement que le programme affiche quelque chose et, sans prendre le temps de lire correctement ce qui est écrit, une partie d'entre eux jouera à la roulette russe :

• - "Le programme affiche 'A'"


• - "Vous en êtes sûr ?"


• - "Non il affiche 'B'"

Dans une équipe de développement qui se veut agile, on attend des membres qu'ils soient ouverts à la communication. En particulier, ils ne doivent pas craindre que quelqu'un d'autre en sache plus (un des principes de l'egoless programming). Un tel travers peut, par exemple, porter préjudice à la programmation par paire : le co-pilote qui ne veut pas montrer sa méconnaissance d'un problème ne jouera pas le rôle de "revue en temps réel" que l'on attend (entre autres) de lui.
Ces divers blocages et comportement approximatifs peuvent être un bon moyen d'amener le candidat à poser des questions pour montrer qu'il cherche toujours à avoir une compréhension suffisante des problèmes qu'il rencontre en allant vers les autres sans craindre de montrer ce qu'il ne connait pas. Ils peuvent aussi, à l'inverse, montrer à quel point le candidat se repose trop sur son compilateur et son debugger pour éviter d'avoir à réfléchir sur ce que d'autres personnes ont écrit. Une telle attitude est un frein à la propriété collective de code car elle donne plus d'importance aux outils qu'aux interactions avec les autres membres de l'équipe.

Loin de moi l'idée que la mise en situation d'un candidat face à un test technique résout tous les soucis de sélection mais elle permet sans aucun doute de se faire une idée sur les capacités d'abstraction, de prise de recul par rapport à la machine et d'ouverture aux autres dans l'activité de conception d'un logiciel.