J’ai eu l’occasion de passer pas mal d’entretiens pour des postes d’ingénieur informatique mais j’ai aussi fait passer plus d’une centaine d’entretiens lors de mon dernier job, surtout pour des postes de développeurs et de chefs d’équipe. Cela m’a souvent amené à discuter de comment recruter et comment choisir de bons profils.

Comme c’est un sujet qui m’intéresse particulièrement et que cette semaine j’ai abordé ce sujet dans 3 groupes de discussions différents, il est temps d’écrire une série de tickets à ce propos.

Voici quelques règles permettant à coup sûr de recruter un mauvais ingénieur :

1. Lire son CV avant l’entretien

Lire le CV avant l’entretien est le meilleur moyen d’avoir des préjugés sur la personne, ce qui est particulièrement dangereux car en 30 minutes d’entretien il est difficile de s’en défaire.

Evidemment, si vous devez sélectionner les profils à partir des CV, vous êtes obligés de les lire à un moment ou à un autre. Dans ce cas, il est préférable de prendre tous les CV, sélectionner ceux qui vous intéressent et de laisser passer une semaine avant de commencer les entretiens.

Cela permet d’oublier le contenu du CV et le jour J de se concentrer uniquement sur la personne.

2. Juger sur ses diplômes

C’est sûrement là la plus grosse erreur à commettre. La France est un pays fier de ses écoles d’ingénieurs prestigieuses et aime beaucoup mettre des étiquettes sur les gens. J’ai eu l’occasion de faire passer un entretien à un jeune qui avait passé plus d’un an à chercher activement un job mais qui avait systématiquement des refus car il n’avait jamais réussi à valider un diplôme universitaire. Il est apparu que malgré un CV vide et « aucun » diplôme cette personne était très bonne en tant que développeur. A l’opposé, on a malheureusement pris en stage un étudiant qui était en dernière année d’une grande école en informatique et qui s’est avéré avoir un niveau en informatique très bas. Avec son diplôme on s’était dit qu’il devait forcement connaître un minimum de chose pour en être arrivé là…

3 Le mettre dans une position de stress

Certains pensent qu’il est nécessaire de mettre le candidat dans une position de stress pour voir comment il réagit. Le but étant de savoir s’il pourra gérer efficacement les situations de stress de son futur job. Or, les situations de stress sont censées être rares. De plus, c’est au chef de projet ou au manager d’encaisser ces situations critiques et de trouver des solutions pour que les ingénieurs n’aient pas à subir ce stress qui est souvent contre productif. Tester le candidat face au stress à plus de chance de le bloquer, de le mettre mal à l’aise et de ne pas se montrer sous son meilleur jour. Le jeu en vaut-il la chandelle ? D’autant plus que la majorité des candidats est déjà suffisamment stressée par l’entretien pour ne pas en rajouter. Au contraire, tout faire pour détendre l’atmosphère est une meilleure solution. Un candidat qui se sent bien sera lui-même, et risque même de baisser sa garde et cachera moins ses défauts.

4 Le croire sur parole

Il arrive de rencontrer des personnes qui sont à l’aise pour baratiner et ce n’est pas pour autant qu’ils sont bons. A contrario, il y a des personnes très compétentes qui ne savent pas se vendre (timides, stressées, …). Si la personne parle beaucoup, il est important de la focaliser sur un projet qu’il a bien aimé, et d’approfondir le sujet par des questions de plus en plus précises. Le but est de voir s’il maîtrise réellement le projet en question. Cela permet aussi de discuter de la manière dont il a abordé le problème, pourquoi il a choisi telle ou telle solution…

5 Trop parler


J’ai eu l’occasion d’aller à des entretiens où le recruteur a dû passer plus du 80% du temps à parler de lui, de sa société, de ce qu’il recherchait, de comment il voyait les choses… Autant dire que ce n’est pas avec les 20% restants qu’il a pu en apprendre beaucoup sur moi.
Autant il est important de se présenter et de présenter la société, autant cela ne doit pas durer plus de quelques minutes. Le but de l’entretien est de créer un échange, un dialogue entre deux personnes. C’est uniquement en instaurant un vrai dialogue que l’on arrive à savoir ce que vaut l’autre personne. Moins le recruteur parle, plus le candidat parle et donc plus on en apprendra sur lui.

6 Lui faire passer des tests psychologiques

Mais pourquoi donc ??? Faire passer ce genre de tests est totalement inutile. Je ne remets pas en doute le bienfait des tests, mais franchement… Selon moi, les tests ne montrent qu’une seule chose : si le candidat a déjà passé le test par le passé. Il existe des dizaines de livres contenant tous les tests logiques et psychologiques. Si un candidat connaît déjà le test, il peut sans problème lui faire dire ce qu’il veut.

7 Lui parler de technologie

A part dans de très rares cas où l’on recherche un expert extrêmement calé dans un domaine très précis dans le but de faire du consulting, parler de technologie est une perte de temps. Est-ce que le candidat connaît le C++ ? Si oui, connaît il les templates ? Le polymorphisme ? Les RTTI ? Les trigraphes ? La délégation croisée ? Et après ??? Même s’il ne connait pas le nom ou ce que ça fait, il suffit de l’apprendre ! J’ai eu l’occasion de bosser avec un ingénieur généraliste qui, bien qu’excellent, n’avait qu’une connaissance basique du C++. Il s’est pourtant très vite mis à niveau. Aujourd’hui, il bosse même sur STLPort.

Les technologies évoluent tout le temps, à quoi bon engager quelqu’un qui connaît bien une technologie à un moment donné ? Si on recrute quelqu’un pour du long terme, il est largement préférable de savoir comment il s’adapte aux évolutions technologiques. Est-ce qu’il est capable de se remettre en question ? D’apprendre par lui-même ? De s’auto-former ? De poser des questions quand il ne connaît pas la réponse ?

8 Lui demander d’écrire un programme sur papier

Cela part d’une bonne intention ; savoir s’il est capable de résoudre un problème simple (compter le plus gros palindrome dans une string). Mais en fait non, c’est loin d’être une bonne idée. Matt Gerrans l’explique bien dans cet article (traduction approximative) :

Je n’aime pas quand on me demande d’écrire un programme qui fait X sur un bout de papier. Ne demandez pas au candidat d’écrire un programme sur papier. C’est une perte de temps et de sueur. Les gens n’écrivent pas de programmes sur papier, ils le font avec des ordinateurs en utilisant l’auto-completion, les macros, la documentation, et l’aide contextuelle. Ils y pensent, le refactor, et le récrivent même. Si vous voulez voir le travail d’une personne, demandez-lui d’écrire un petit module ou de mettre en application une certaine interface avant l’entrevue et d’apporter le code sur un PC portable, ou imprimé. Vous pourrez alors le passer en revue et discuter de la conception, du style de programmation, et des décisions qui sont venues. Ceci vous donnera une évaluation beaucoup plus réaliste et plus utile du travail et du style d’une personne.