« Recruteurs, vous avez (sûrement) tout faux« . Ainsi pourrait-on résumer le dernier post de blog de Laurie Voss, Chief Technology Officer (CTO) de la start-up éditrice du logiciel npm, repris par le site Quartz. L’auteur, se fondant sur ses propres expériences, met en garde les responsables RH contre les 5 erreurs les plus répandues desquelles naissent les mauvais recrutements. Et propose des moyens de s’en prémunir.
DON’TS.
1 – N’embauchez pas un développeur sur les compétences qu’il détient déjà
Penser qu’un développeur effectuera les mêmes tâches avec les mêmes compétences pour lesquelles vous souhaitez le recruter dans 5 ou 10 ans est une erreur. D’ici là, qui sait si l’entreprise n’aura tout simplement pas changé son cœur de métier ? Évitez donc de trop vous concentrer sur ce point précis. Pensez potentiel.
2 – Ne testez pas les aspects techniques n’importe comment
La plus grosse erreur selon Laurie Voss ? Demander à un développeur lors d’un entretien de rédiger des lignes de code sur un tableau blanc. Pire encore : le chronométrer. Cela ne sert strictement à rien. En entreprise, combien avez-vous vu de codeurs rédiger des lignes sur un tableau blanc un chronomètre à la main ?
3 – Ne vous laissez pas impressionner par un diplôme séduisant
Le diplôme, aussi séduisant qu’il puisse être, ne doit pas être l’alpha et l’oméga du recrutement d’un développeur. Avoir un doctorat peut être un atout indéniable, mais peut également se transformer en véritable point faible. Cherchez-vous un développeur ou un théoricien du code plongé dans les concepts ?
4 – Ne regardez pas (trop) les précédents employeurs du candidat
Le nom d’une grande entreprise peut impressionner. Mais ne vous focalisez pas dessus : qui vous dit que le candidat en face de vous a participé au succès de ladite entreprise ? D’autant plus si elle compte de nombreux salariés…
5 – N’embauchez jamais des membres de votre famille ou vos amis. JAMAIS
Pour Laurie Voss, embaucher l’un de ses amis ou un membre de sa famille est une grossière erreur. Qui a de forte chance de s’avérer néfaste pour tout le monde : à terme « cela compromettra soit votre amitié soit votre entreprise, et plutôt que d’être forcé de choisir entre les deux, mieux faut éviter tout bonnement le conflit« .
DOS.
1 – Demandez-vous si le candidat pourra… faire le travail demandé
La question n’est pas tant si il peut le faire aujourd’hui et maintenant. Mais plutôt s’il possède les compétences pour, à terme, le réaliser. La base de recrutés potentiels n’en sera que plus grande. Et sur le long terme, ce choix, quoi que contre intuitif de prime abord, peut s’avérer payant.
2 – Demandez-vous s’il possède un fort potentiel d’évolution
En effet, dans l’entreprise agile, vitesse et adaptation sont des compétences clés : la compétence recherchée par plus de 9 employeurs britanniques sur 10 sera demain la résilience, ou la capacité à s’adapter au changement. Bien plus que l’exécution d’une tâche à un instant t, dont bon nombre de managers savent qu’elle ne peut qu’évoluer dans le futur, l’idée est de cerner la vitesse d’apprentissage du candidat et sa capacité à mettre en pratique de nouvelles connaissances. En un mot, son potentiel.
3 – Détectez s’il sait parler « code » à ceux qui n’y connaissent rien
Le développeur travaille souvent en équipe, et peut être en contact constant avec des directions peu au fait des spécificités techniques voire même du langage propre au métier. Et pour l’auteur, le constant est formel : « si vous n’êtes pas capable de communiquer avec vos collègues, vous ne faites que la moitié de votre job« .
4 – Demandez-vous s’il connaît ses limites
Savoir dire que l’on ne sait pas est une marque de franchise. C’est aussi faire preuve de connaissance de soi. Et c’est une qualité dont les entreprises peuvent avoir besoin. Plus que de quelqu’un qui dit tout savoir.
5 – Rappelez-vous que l’entretien est une discussion – pas un interrogatoire
Enfin, dernier conseil de Laurie Voss : se rappeler que l’entretien est une discussion, pas un interrogatoire. Savoir quel est le champ d’expertise du candidat est une bonne chose. Le mettre sous pression ou le faire paniquer durant tout l’entretien ne vous indiquera pas comment il réagit dans une configuration de travail normal. Et après tout, c’est ce que vous devriez rechercher. Sinon, il y a aussi le recrutement via hackathon.
« Les RH sont un partenaire incontournable dans la transformation de la DSI », écrivait sur nos pages Stéphane Clément, PDG de Proservia. La preuve avec ces conseils que l’inverse est aussi vrai ? Bien que destinés au recrutement des développeurs, ils peuvent assez facilement se généraliser à d’autres profils IT… et semblent à nouveau justifier la nécessité d’un nouveau front DSI/DRH.
