Mon guide pour faire un entretien technique efficace

Il n’est pas toujours facile de mener un entretien technique complet et pertinent sans que ça ne devienne un véritable parcours du combattant pour le candidat.

NicolasFz.code
7 min readSep 8, 2020

Hors, beaucoup d’entretiens techniques, pour se montrer efficace, s’étirent énormément en longueur. Si l’on est un candidat sollicité, il peut être difficile de tous les effectuer correctement et il va falloir faire un tri avant même de les commencer. Pour le recruteur, cela signifie qu’avant même le début de ses entretiens, il a déjà perdu des candidats potentiellement intéressants.

Dans ce billet, je vais essayer de vous donner quelques pistes de réflexion pour que vous puissiez mettre en place un entretien technique type qui devrait vous aider à y voir plus clair dans le potentiel de vos candidats, sans toutefois les faire fuir à cause d’un processus de recrutement trop fastidieux.

ATTENTION : Dans ce billet il est question d’entretiens techniques. Je pars donc du principe que le recruteur mis en scène est une personne disposant de bonnes compétences techniques.

Voici donc quels sont les 5 grands axes d’un entretien technique réussi !

1.Vérifier les compétences de base

Il arrive malheureusement de rencontrer des candidats qui se sur-vendent énormément. On peut parfois détecter ce genre de candidat dès la lecture de leur CV — Si par exemple le candidat “maîtrise” beaucoup trop de technologies en comparaison de ses années d’expériences et de ses projets — mais il est toujours important de vérifier que la personne en face de nous possède au minimum les bases des compétences qu’il prétend avoir.

Pour cela, il n’est pas nécessaire de proposer des exercices longs et compliqués. De manière générale un QCM avec, pour chacune des technologies qui vous intéressent, 4–5 questions sur des notions de bases peut déjà permettre de démasquer la plupart des pipoteurs.

Évitez de faire durer cet exercice plus de 30mn. Garder un QCM court vous permet de garder du temps pour entrer dans le détail plus tard, sans pour autant rendre l’entretien trop indigeste.

Pour cette phase, vous pouvez laisser le candidat seul dans une pièce afin d’éviter de lui ajouter la pression d’un regard examinateur. Certaines personnes peuvent perdre leurs moyens lorsqu’elles sont surveillées de près et ce n’est pas, à mon sens, un défaut qui devrait être éliminatoire lors d’un entretien technique.

2.Vérifier le recul du candidat sur les outils qu’il maîtrise

Dans un second temps, il est important de vérifier que le candidat dispose de suffisamment de capacité de réflexion et de recul pour évaluer objectivement les outils ou les technologies qu’il maîtrise.

Pour un développeur il est important de connaitre les forces et les faiblesses de ses outils afin de savoir déterminer quel outil est adapté à chaque problématique.
Après tout, personne ne veut de quelqu’un qui se servirait d’un tournevis pour planter des clous juste parce qu’il maîtrise déjà le tournevis.

Pour vérifier leur recul, je demande donc aux candidats quels sont les points forts et les points faibles leurs outils.

Une grande partie des candidats devraient être capable de vous citer les points forts assez facilement. Après tout, c’est souvent ce qui sert d’introduction dans la plupart des formations. Ce qui est réellement important ce sont les points faibles. Une personne qui est incapable de vous citer les points faibles de ses outils (et il y en a toujours) est généralement un assez mauvais signe et ça devrait vous alerter sur ses capacités de choix technique.

3.Vérifier sa capacité de réflexion

Pour vérifier ce point, vous pourriez faire au plus simple et lui demander de développer un petit programme relativement complexe. Néanmoins c’est un exercice qui prend du temps, qui introduit des biais qui n’existent pas forcément dans le poste (pression, forte contrainte de temps, environnement de travail, choix technologique limité, outils non-adaptés,etc… ) et qui peut décourager certains candidats pourtant talentueux. Ce n’est pas forcément un exercice que je déconseille, mais je pense qu’il est possible de faire tout aussi efficace en moins de temps.

Pour gagner du temps et apprendre un peu plus à connaitre mon candidat, je préfère lui demander de m’expliquer la plus grosse problématique technique auxquelles il a pu faire face et de m’expliquer comment il l’a résolue.

De cette manière, je connais le niveau relatif du candidat et je sais quelle capacités de réflexions il est capable de mettre en oeuvre pour résoudre un problème.

Mais alors comment déceler les bobards ?

Les plus beau parleurs pourraient mentir ou raconter des exploits réalisés en réalité par des collègues. Pour en avoir le cœur net il faut poser des questions très précises sur la problématique exposée par le candidat. Les pipoteurs ne vont probablement pas savoir y répondre et vont commencer à s’empêtrer dans des explications de plus en plus floues.

A l’inverse, plus les réponses fournies par le candidat seront simples et claires, plus vous pourrez avoir la certitude que le candidat dispose d’une excellente capacité de réflexion
Après tout, pour savoir expliquer quelque chose simplement il faut l’avoir compris !

En complément, vous pouvez également demander au candidat de décrire ses anciens projets en précisant les aspects qu’il approuvait et ceux qu’il désapprouvait. Comme pour les outils qu’il maîtrise, il est souvent instructif de savoir si un candidat dispose de suffisamment de recul sur les projets sur lesquels il a travaillé.

4.Vérifier sa conscience professionnelle

On a trop tendance à penser que quelqu’un de talentueux est forcément professionnel, hors c’est totalement faux.

Ce point va peut-être en faire grincer des dents certains (et je serais ravis d’en discuter en commentaire) mais j’aime demander aux candidats ce qu’ils priorisent entre la qualité de leur code et le fait de tenir une deadline. Cela peut paraître contre intuitif aux plus techniques d’entre vous mais pour moi la bonne réponse à cette question est : Tenir la deadline.

Globalement je suis d’avis que le client se fiche bien de savoir ce qu’il y a en dessous du capot du moment qu’on lui a livré à l’heure quelque chose qui roule correctement. De plus, il est toujours possible de revenir à posteriori sur son programme pour “refactorer” les éléments les plus problématiques.

Vous pouvez également lui demander s’il connait le principe de KISS et de vous l’expliquer s’il affirme que c’est le cas. Ce n’est pas en soi une preuve de conscience professionnelle mais c’est un principe qui va tout de même dans cette direction.

Bien sûr, s’il est possible de faire du code de qualité tout en tenant les deadline c’est absolument ce qu’il faut faire !

Pour vérifier la conscience professionnelle, certains recruteurs préfèrent demander au candidat s’il est prêt à travailler plus longtemps pour terminer un projet. C’est une question que j’évite de poser car cela peut donner au candidat l’impression que les projets sont mal gérés et qu’ils sont systématiquement en retard. En effet, quand je suis le candidat cette question ne manque pas de me rendre suspicieux.

5.Vérifier son égo et sa capacité à travailler en équipe

Il n’existe pas de question magique pour vérifier l’égo d’un personne (ou alors, je ne suis pas au courant). Mais lors de l’entretien vous pouvez néanmoins essayer de contredire le candidat sur plusieurs points d’importance secondaire (évitons par exemple d’affirmer que la technologie sur laquelle il travaille depuis 10 ans ne vaut rien, au risque de se le mettre définitivement à dos).

Lorsqu’on la contredit, un personne avec un léger problème d’égo va rapidement se vexer et camper sur sa position, peu importe vos arguments.

Cela vous permettra également de savoir si votre candidat est prêt a faire des concession si l’équipe prend des décisions qui ne lui conviennent pas.

Comme vous pouvez le voir, tout au long de l’entretien je ne donne pas systématiquement de gros exercices à réaliser (même si cela peu arriver en cas de doutes). En effet, comme vous avez pu le voir, je n’apprécie pas particulièrement ces tests purement technique qui peuvent se révéler extrêmement long pour le candidat et qui ne montrent qu’un aspect très limité de son potentiel — Sa maîtrise technique pure — et qui, à l’inverse, peuvent faire fuir des personnes très talentueuses mais qui manqueraient de temps pour les effectuer.

J’espère que cet article vous a plu. Si vous avez des remarques à ce sujet où que vous désirez partager vos conseils concernant les entretiens techniques, je serais ravis d’en discuter en commentaire !

--

--

NicolasFz.code
NicolasFz.code

Written by NicolasFz.code

Lead Développeur PHP/Symfony, Chargé de recrutement technique

Responses (1)