10 erreurs commises lors d’un recrutement tech

Le recrutement technique est une phase dans la vie d’une entreprise qui va mêler intimement le besoin de comprendre en profondeur l’humain et la technique. De ma petite expérience, je m'aperçois que c’est un exercice de la plus haute difficulté :

Je vois des dévs exprimer une grosse frustration à la sortie d’un entretien, ou des angoisses à l’idée d’y aller pour être humilié ou perdre leur temps
Je vois des recruteurs faire des entretiens complètement lunaires, à côté de la plaque, ou mal préparés.
Je vois des candidats qui ne font pas l’affaire être pris malgré tout
etc.

Sans prétendre avoir la solution pour mener l’entretien parfait, je vais essayer de m’attarder sur ce que je pense être des motifs d’erreurs que j’ai pu percevoir au fil des années. J’insiste sur le fait qu’on est ici dans un écrit particulièrement subjectif, que mon avis s’est façonné au fil du temps par mon expérience personnelle, par les retours d’amis, de blogueurs. Impossible ici d’émettre des vérités immuables, avec preuves et statistiques à l’appui.

A défaut d’apporter cette solution miracle, l’article devrait permettre à un recruteur tech de se reconnaitre dans certains points, et peut-être se remettre en question sur certains aspects, ou au contraire se conforter dans manière de faire. Je m’adresse ici au recruteur en utilisant le “vous”.

Bonne lecture !

⚠️ 1 - Vous n’êtes pas techniques et recrutez seul

La règle est simple : si vous voulez recruter quelqu’un de meilleur que vous dans un domaine, vous ne pouvez pas être celui qui juge ses compétences.

Est-ce qu’un juge qui ne connaitrait pas les textes de loi pourrait décider seule de condamner un accusé ? Non.
Est-ce qu’une personne qui ne code pas peut recruter seule et sans risque un développeur ? Non plus.

Je distingue ce point sous deux formes :

L’erreur inconsciente :

L’être humain a par nature, une tendance à vouloir juger son prochain à tout prix, sans se rendre compte que son jugement n’est pas toujours fondé. Il confond parfois l’analyse (🧠Thinking) avec son intuition (Feeling 🫀).

J’ai entendu de nombreuses fois des personnes non techniques affirmer avec aplomb :

Ce dév c’est un tueur !

Peut être bien, mais comment en être certain ? Comment le prouver seul ? Que ce soit de manière générale en société, ou spécifiquement pendant un recrutement technique, basons tant que possible notre un avis sur des faits très concrets.

Par exemple, si vous voulez savoir si un scientifique est bon, demandez l’avis de ses pairs, plutôt qu’uniquement utiliser votre intuition basée sur un tas d’éléments fallacieux, comme sa réputation dans la presse.

Si vous voulez savoir si un dév est bon, demandez l’avis de bons autres dévs si vous n’en êtes pas un vous-même. En tant que personne non technique, acceptez que votre intuition n’est et restera qu’une intuition, même si l’expérience la rendra de plus en plus juste au fil du temps.

L’erreur volontaire :

Il y a aussi le recruteur qui est conscient de son manque, mais qui faute de mieux, concède qu’il n’a pas trop le choix car il ne dispose pas des compétences en interne (évidemment, sinon après tout il ne recruterait peut être pas s'il disposait déjà de la compétence !).

Dans ce cas, le recruteur accepte sciemment de prendre le risque de se tromper, en se fiant à son intuition. Ce risque peut être payant ou non, c’est un choix à faire.

💡Quelques pistes

Faites-vous aider par votre réseau, des amis, un freelance, ou toute personne en qui vous avez confiance.
Ne faites pas confiance aveuglément aux entreprises de mises en relation, puisque leur but est que le candidat soit pris pour toucher leur com, et parce qu’eux même ne connaissent pas en détail votre besoin.
Mesurez le niveau de risque que vous êtes prêts à prendre dans votre recrutement. Un mauvais premier recrutement technique en startup peut être très douloureux.
Continuez malgré tout à utiliser de manière complémentaire votre intuition, qui bien qu’insuffisante, reste nécessaire.

 Attention, il reste malgré tout indispensable qu’une personne non technique participe au recrutement, de manière complémentaire pour donner son avis sur le côté humain, la personnalité du candidat, etc.

⚠️ 2 - Vous ne savez pas quels rôles précis aura votre recrue

On cherche un ninja hacker du code pour notre super start-up en croissance

On a tous vu ce genre d’annonce complètement évasive, qui montre que vous ne vous êtes pas posé toutes les questions qu’il fallait pour bien définir votre recherche.

Certains pensent qu’une fois le choix fait entre full stack / back-end / front-end / mobile / devops, alors le boulot est fait.

Mais même au-delà de cette spécialisation, il existe de nombreux rôles très distincts, que certains profils ne maitrisent pas, ou ne souhaitent simplement pas avoir au sein de l’entreprise. Voici quelques exemples de rôles parmi beaucoup d’autres :

Un technical architect, capable de construire des solutions complexes à partir de rien, en faisant des choix d’architecture déterminants pour la suite.
Un features doer, capable de comprendre vite les besoins métiers et d’enchainer les développements qui y répondent.
Un team builder, capable de construire et fédérer autour de lui une équipe.
Un technical expert, capable d’arriver à un niveau d’excellence sur le code écrit, et servir de référent pour les autres dévs.
Un task manager, capable de découper et répartir les tâches techniques intelligemment

Tout développeur aussi talentueux soit-il, aura des rôles dans lequel est plus à l’aise, ou auxquels il aspire.

Pour votre défense, le vocabulaire associé aux différents rôles est loin de faire consensus, et les termes anglais et français se mélangent souvent. 

Aussi, le terme développeur est un parfait exemple d’un vocabulaire pas assez inclusif. Software Engineer serait plus adapté selon moi car il couvre un spectre plus large, pouvant correspondre aux différents rôles vus ci-dessus.

💡Quelques pistes

Définissez clairement les rôles dont vous avez besoin, d’abord dans votre tête, puis ensuite sur l’annonce, et pendant l'entretien
Pour chacun des aspects qui vous intéressent réellement, demandez au candidat de s’auto évaluer et de raconter ses expériences et anecdotes.
Voici quelques exemples de questions à poser pour aider à définir des aspirations à un rôle :

Tu préfères partir d’une feuille blanche ou d’une solution existante ?

(builder VS runner)

Tu préfères faire 2 features avec du code bien ou 1 feature avec un code excellent ?

(feature-doer VS tech expert)

Tu prends plus de plaisir à aider un collègue ou à terminer une feature ?

(orienté équipe ou doing)

Tu te sens plus l’âme d’un compétiteur ou d’un collaborateur ?

(orienté performance ou collaboration)

Il est important que les réponses proposées soient toutes des bonnes réponses de manière générale, mais moins dans votre cas spécifique.

Par exemple pour la 2e question, les deux réponses me semblent parfaitement acceptables, mais si le time-to-market est crucial pour votre startup, vous préférerez développer vite à court terme.

⚠️ 3 - Votre entretien est trop axé sur du code, de l’algo, ou des maths

Comme on l’a vu dans un point précédent, vous ne recrutez ni un pisseur de lignes, ni la future médaille Fields, mais une personne amenée à avoir différents rôles techniques au sein de votre entreprise, bien que tous axés autour du développement.

  Pourquoi alors passer les 9/10e de l’entretien à ne parler que de code en détail ?  Pourquoi les tests ne devraient juger que la capacité d’une personne à écrire du code ? 

Ce genre d’entretien peut témoigner du fait qu’un recruteur n’a pas pris la mesure des caractéristiques qui font un bon software engineer, en résumant le travail du développeur à écrire des lignes de code.

Ne vous faites pas piéger, il y a de nombreuses personnes très fortes en développement pur, mais qui ne feront pas l’affaire dans votre cas car par exemple incapables :

de prendre du recul pour prendre des décisions structurantes qui marcheront à long terme
de se manager eux-mêmes s’il n’y a pas de tech lead
de prendre des décisions pertinentes, en rapport avec le contexte business du projet.
de délivrer des features parce que trop passionnés / perfectionnistes / whatever

Les tests techniques où le but est de faire un maximum d’exercices de code dans un temps imparti, n’ont pour moi que très peu d’intérêt, car c’est du travail sous stress dans lequel la créativité n’a pas sa place, et où la résolution de problème est orientée uniquement sur le code, ce qui ne correspond pas à la vraie vie, dans laquelle le code est un moyen de répondre à un problème réel.

Or, le développement d’un produit est rarement un sprint, mais plus souvent un marathon. Si à court terme un développeur rapide va donner l’impression d’avancer plus vite, à long terme, un développeur plus lent qui prend les bonnes décisions d’architectures et d’outillage, qui teste mieux, rattrapera forcément son retard.

Dans le même genre, les entretiens pour du développement web qui sont bourrés d’exercices mathématiques et algorithmiques sont pour moi des contresens absolus. Il s’agit d’exercices qu’on faisait tous à l’école pour former son esprit et sa logique. 10 ans après être sorti d’école, je n’ai quasiment plus eu à me servir directement de ces compétences dans ma vie professionnelle.

Pourquoi alors les demander en entretien ? Là encore on teste davantage la mémoire d’un candidat, que sa capacité réelle à réfléchir. Un candidat qui sort d’école va d'ailleurs sûrement être avantagé comparé à un meilleur développeur plus senior, ce qui est paradoxal.

💡Quelques pistes

Essayez de voir du code publié par le candidat en amont (sur Github en open source, sur un blog), demandez-lui d’envoyer du code sinon. Regardez les questions qu’il pose sur Stack Overflow, etc. Cela vous permettra d’être en partie rassuré sur la qualité de son code, de manière à alleger ce sujet pendant l'entretien.
Ayez confiance dans le fait que quelqu’un doué d’un raisonnement logique saura écrire du code, et ce, sans savoir recoder des algorithmes complexes de tête sur un tableau devant 5 personnes.
A part pour un poste où les maths sont nécessaires (ex : orienté data-scientist, IA, R&D), sortez-vous cette idée de la tête qu’un dev web doit absolument être une brute en maths, c’est faux.

⚠️ 4 - Vous vous focalisez trop (ou pas assez) sur les technos actuelles du candidat

Ce candidat a l’air bon mais il a bossé dans un langage/framework différent du nôtre, est-ce que ça vaut le coup de le prendre quand même ?

Comme souvent, ça dépend du contexte. Quelques erreurs courantes :

Croire qu'un candidat va faire l'affaire juste parce que les technos de son CV sont celles dont l'entreprise a besoin
Sur-estimer ou sous-estimer le gap de compétences qu’il existe quand le CV du candidat ne matche pas les besoins sur les technos.
- dans le 1er cas, on va passer à côté d’un bon candidat qui aurait vite rattrapé son retard
- dans l’autre cas, on va espérer qu’une recrue devienne bonne rapidement alors qu’elle restera sous l’eau et ratera probablement son intégration à cause de ça

Là encore, on le redit, seule une personne technique pourra évaluer ce gap précisément.

💡Quelques pistes : des questions à poser pour aider à décider :

Est-ce que le retard sur la techno en question peut-être très vite rattrapé ? Plutôt oui pour un petit outil et une recrue qui adore apprendre, plutôt non pour un langage + framework entier
Pourquoi la recrue postule-elle à un poste qui ne correspond pas à ses compétences actuelles ? L’a t-elle déjà fait avant ?
Est-ce que l’équipe en place est déjà forte sur les technos en question ? Si oui, quelles seront les implications (la nouvelle recrue va-t-elle se sentir nulle en se comparant ? Ou au contraire des collègues vont avoir du temps pour l’aider ?)
Est-ce que le niveau technique du code actuel nécessite des compétences basiques ou solides pour être pris en main ?

⚠️ 5 -Vous oubliez d’être réellement attirant pour le candidat

Ce n'est pas un scoop, l’offre et la demande dans le milieu de la tech sont déséquilibrés. Les développeurs, même en poste, reçoivent de nombreuses offres par tout un tas de chasseurs en permanence.

A ce titre, vous devez encore plus que dans un autre job, tout faire pour être séduisant, et vous devez proposer une certaine symétrie dans l’entretien, en acceptant d’être challengé autant que vous le faites, d’être questionné autant que vous le faites, etc.

Vous voyez ce genre d’entretien où le recruteur pense que le seul but de l’entretien est de tester le candidat ?  N’oubliez pas que ça va toujours dans les deux sens : vous devez montrer votre valeur au candidat vous aussi.

Et cela ne consiste pas à décrire l’entreprise de la même manière platonique à tout le monde. Vous devez écouter activement les traits du candidat et rebondir dessus pour affirmer pourquoi votre entreprise est parfaite pour lui.

A part si vous êtes une entreprise extraordinaire avec un poste et un salaire de rêve, vous allez devoir convaincre vous aussi !

💡Quelques pistes

En amont, étudiez les forces de votre entreprise, et les forces de votre poste. En quoi la personne qui obtiendra ce poste aura une chance folle ? Si vous n’en voyez pas, revoyez peut-être le poste lui-même, voire la culture de votre entreprise.
Regardez ce que propose les autres startups de votre catégorie, afin de savoir comment vous vous positionnez vis à vis des concurrents.
Ne pensez pas qu’aux aspects matériels pour attirer un candidat. Le “choix des technos à mettre en place” peut être un argument plus séduisant pour un passionné, que des tickets restaurants.
N’ayez pas d’idée arrêtée sur des questions comme le télétravail, si vous n’avez pas sérieusement étudié la question en amont. Si vous avez des doutes, levez-les avant l’entretien, pour être en mesure d’apporter une réponse claire au candidat. Plus généralement, n’imposez pas une culture d’entreprise que vous n’avez pas.
Ne vous offusquez pas quand un candidat demande clairement ce qu’il veut. Vous n’avez pas affaire à une “petite princesse 👸”, mais juste à une personne souvent rationnelle qui sait globalement ce qu’elle est en mesure d’obtenir, surtout après quelques années d'expérience.
Ne soyez pas inutilement formels : n’exigez pas un CV en pdf A4, si le candidat a déjà fait l’effort de faire mieux comme un site personnel, soyez naturels, gardez votre sens de l’humour, restez détendu et sympathique, mettez au clair la question du tutoiement dès le début, mettez en confiance votre interlocuteur, évitez de créer une sensation de hiérarchie entre vous, ou de déstabiliser volontairement votre interlocuteur.
Restez honnêtes et affichez vos faiblesses. Le candidat aura plus confiance en vous que si vous dites que tout est parfait dans la boite. Puis une recrue qui part au bout de quelques mois parce qu’elle est déçue sera un échec de toutes façons.

⚠️ 6 - Vous n’êtes pas clairs sur le processus de recrutement et/ou la fiche de poste

Cela rejoint le point précédent, mais il est pénible de ne pas savoir quelles vont être les étapes, pas savoir combien de temps ça dure. Dites vous que rien qu'une mauvaise annonce, peut vous faire perdre la majorité des candidatures.

💡Quelques pistes

N’ayez pas la prétention de croire que le candidat dispose d’un temps illimité pour vous. Demandez-lui s'il dispose du temps nécessaire pour le process de recrutement en entier. Si trop disent non, c'est sûrement que votre recrutement est trop long.
Définissez chaque étape clairement pour permettre au candidat de se projeter. Un candidat ne prendra généralement pas la peine de postuler s'il n'a pas assez d'infos sur le poste ou le process de recrutement.
Par exemple, si vous savez que le salaire que vous proposerez sera bas, dites-le clairement dès le début, vous gagnerez du temps à pas tester des candidats qui veulent le double et diront non in fine de tout manière, ou partiront pour une autre opportunité.

⚠️ 7 - Vous imposez votre style de test au candidat

Il existe mille et une manières de faire un test technique :

faire un test de code en live sur un tableau ?
proposer un projet à faire à la maison ?
proposer à un dev de passer une demi-journée payée dans votre équipe ?

 Tous les types de tests ont pour vous, leurs avantages et inconvénients. Mais ce qui est certain, c’est que le candidat aura forcément une préférence.

A titre personnel, je sais que je suis incapable de réfléchir correctement debout à un tableau avec quelqu’un qui me regarde. Et je n’y vois rien de surprenant, j’étais toujours stressé de passer au tableau à l’école. Mais ça ne pose aucun problème à d’autres candidats, pour qui ces conditions n’ajoutent aucun stress. Je préfère largement prendre le temps qu’il faut chez moi à coder tranquillement un truc au top, alors que d’autres candidats ne souhaiteront pas passer trop de temps à travailler pour un poste qu’ils ne sont pas certains d’obtenir, ce qui est tout à fait compréhensible.

Sachant ces différences, pourquoi alors ne pas plutôt laisser le candidat choisir ? Le risque à ne pas le faire, est que ce candidat refuse le test, ou l'accepte et le rate, non pas parce que le candidat ne convient pas, mais parce que le test ne lui convient pas.

💡Quelques pistes :

L’idéal serait que vous soyez prêt à proposer tous les styles de tests possibles, et demandiez l’avis du candidat avant
N’hésitez pas à mettre à l’aise le candidat en lui disant qu’il n’y aucun souci à préférer un style de test plutôt qu’un autre…
… Mais profitez de l’occasion pour comprendre pourquoi le candidat préfère un certain type de test. Par exemple dans mon cas précis, le recruteur verrait que la résistance au stress n’est pas ma meilleure qualité, une info qui peut lui servir.

⚠️ 8 -Vous pensez qu’une bonne communication n’est que nice to have

Peu importe le métier que nous sommes amenés à faire, je suis persuadé que la communication est toute aussi primordiale que les compétences techniques. Le développement n’échappe pas à la règle, sous prétexte que le développeur est plus souvent derrière son ordi que devant un client.

En effet, combien de temps est perdu parce qu’un développeur n’arrive pas à s’exprimer clairement auprès d’un collègue, à vulgariser un concept technique auprès de personnes non techniques, ne sait pas quelles informations doivent être distribuées au bon moment, ne sait pas ordonner ou documenter son travail, préfère faire qu’expliquer, … etc ? 

Et pourtant, vous allez faire passer moulte tests sur le code et laisser de côtés des soft skills tous aussi importants.

💡Quelques pistes

Evaluez la qualité de la communication à chaque étape du recrutement, chaque échange, oral ou écrit, doit être analysé avec attention.
En plus de demander du code, n’hésitez pas à lire tout livrable d’un candidat qui contiendrait davantage de texte.
Quand vous posez des questions en entretien, en plus du contenu, concentrez-vous sur la capacité du candidat à être clair, synthétique, à vulgariser, à répondre précisément sans trop s’éparpiller, à prendre le temps de faire des phrases construites, etc. Voyez sa réaction lorsque vous n’êtes pas d’accord avec lui, est-ce qu’il se braque et bafouille, ou au contraire réexplique plus clairement ses arguments pour vous convaincre.
Ne vous aventurez pas à choisir des recrues qui ne parlent pas français, si votre équipe ne parle pas bien anglais, ou n’est pas prête à faire des efforts pour travailler dans cette langue au quotidien.
Même si j'insiste ici sur la communication, je pense que ces conseils peuvent être étendus à tout "soft skill" que vous jugez être important.

⚠️ 9 -Vous pénalisez un candidat honnête

Malgré toutes les qualités et la malice d’un recruteur, il me semble très difficile de détecter les défauts (techniques ou humains) d’un candidat. Or, il y a deux types de candidats :

Ceux qui veulent réussir l’entretien à tout prix, et donner la meilleure impression possible au recruteur, comme s’ils faisaient leur propre publicité. Réussir leur entretien leur donne de la confiance et flatte leur égo. Ces derniers ne facilitent pas la tâche du recruteur, car il doit alors creuser en profondeur pour déterrer les failles.
Ceux qui, plus matures, ont compris qu’en disant toute la vérité, leur future union si elle devait avoir lieu, n’en serait que meilleure. Ces candidats sont du pain béni car en étant proactifs et honnêtes, ils rendent la tâchent facile au recruteur.

Si on prend l’analogie des apps de rencontres, vous auriez deux types de profils Tinder :

la fille qui est maquillée sur toutes ses photos, prises dans le meilleur angle possible, pour cacher ses défauts et plaire au maximum
la fille qui s’est prise en photo dans un tas de conditions différentes, pour donner un maximum d’info sur elle afin de montrer qui elle est vraiment

💡Quelques pistes

Essayer de mettre en confiance le candidat, en lui faisant comprendre dès le début que vous valorisez l’honnêteté.
Dès qu’un candidat parle d’une faiblesse, envoyez-lui un signal positif (verbal ou non verbal) pour l’inciter à continuer dans ce sens.

⚠️ 10 -Vous confondez mauvais candidat et mauvais entretien

Pour reprendre l'analogique des apps de rencontre, l’entretien c’est comme un date, si l’un est trop timide et ne parle pas, il faut que l’autre le mette en confiance, et pose les bonnes questions pour l’amener à le faire parler, sinon l’entretien risque d’être ennuyeux à mourir. 

Si le candidat est peu bavard, et que le recruteur ne pose pas de questions pertinentes, ne rebondit pas, alors l’entretien va être inintéressant. Le match risque de ne pas se faire, non pas à cause du candidat lui-même, mais à cause de l'incapacité des protagonistes à rendre cet entretien riche.

Il y a plein de développeurs peu expansifs en entretien, qui sont bons par ailleurs dans leur domaine de compétence. Mais en s'arrêtant à ça, vous risquez alors de passer à côté d’une perle, juste parce que l’entretien aura été pauvre.

💡Quelques pistes

En tant que recruteur, préparez sincèrement un entretien, n’arrivez pas les mains dans les poches en découvrant le CV au début de l’entretien. Vous devez passer au moins autant de temps qu'un candidat. Si vous n'avez pas de temps, faites moins d'entretiens en filtrant davantage en amont.
Pendant l'entretien, votre devoir est de comprendre les aspirations profondes du candidat par tous les moyens. Relancez les discussions, reformulez vos questions, n'abandonnez pas un point pas clair.
S’il y a encore beaucoup de doutes à l’issue de l’entretien, posez-vous honnêtement la question de savoir d'où vient le soucis.

Conclusion

Mener un entretien à la perfection semble être une tâche bien plus difficile qu'il n'y parait. Sans même avoir la moindre expertise dans se secteur, on se rend compte à quel point il est facile de faire des erreurs et de passer à côté d'un entretien réussi.

Les lectures et retours d'expériences, à la fois de recruteurs et de candidats sont des mines d'or d'apprentissage, et ont d'ailleurs été un gros complément de mon expérience pour pouvoir écrire cet article.

Quoi qu'il en soit, ne prenez pas un candidat en ayant des doutes sur lui, en laissant la période d'essai remplacer le rôle de l'entretien. Vous perdriez un temps précieux.

Parce qu'en effet, avec ce rapport de force dans le recrutement en faveur des développeurs, et après plusieurs tentatives infructueuses, il peut être tentant de revoir ses exigences à la baisse.

Un dicton que j’aime bien dans le recrutement, c’est que pour le choix d’un candidat à l'issue d'un entretien :

it’s a FUCK YES, or it’s a no

En effet, si vous pensez avoir réalisé votre recrutement exactement comme il le fallait, mais qu’à l’issue de celui-ci vous avez toujours des gros doutes sur le candidat, c’est ce que ce n’est pas le bon ! Tout simplement.

Bon courage à tous les recruteurs pour trouver leur perle rare 😇