Comment recruter un développeur quand on n'est pas technique

Le moment où vous réalisez que vous êtes dépassé

Vous publiez l'offre, les CV arrivent, et chacun d'entre eux mentionne des frameworks dont vous n'avez jamais entendu parler. Quelqu'un affirme avoir cinq ans d'expérience en « développement full-stack avec architecture microservices scalable », et vous n'avez aucune idée si c'est impressionnant ou si la personne a lu ça sur un site de tutoriels une heure avant l'entretien. Vous hochez la tête pendant l'appel. Vous n'avez aucun moyen de challenger ce qu'elle dit.

C'est normal. La plupart des personnes qui dirigent une entreprise de 10 à 200 salariés ne sont pas développeuses, et pourtant elles doivent quand même en recruter. La bonne nouvelle, c'est que vous n'avez pas besoin d'apprendre à coder pour bien recruter. Vous devez simplement arrêter d'essayer de juger le code, et commencer à juger les preuves qui l'entourent.

Ne faites pas semblant d'être technique — ça se retourne contre vous

Les candidats sentent quand vous bluffez. Demander « alors, parlez-moi de votre expérience avec Kubernetes » puis répondre « très bien, très bien » quelle que soit la réponse apprend à un candidat malin que cet entretien n'a aucune vraie barre à franchir. Ceux qui parlent avec aisance mais ne livrent rien passeront sans effort. Les plus discrets, compétents, qui pensent que vous vérifiez réellement leurs propos, se sous-vendront.

Soyez honnête à ce sujet. « Je ne suis pas technique, donc je vais vous demander d'expliquer les choses en langage simple, et je vais m'appuyer sur quelqu'un de technique pour une partie de ce processus. » Ce n'est pas une faiblesse — c'est exactement ce que fait un bon recruteur lorsqu'il embauche dans un domaine qu'il ne pratique pas lui-même.

Emprunter le regard technique de quelqu'un d'autre — pour une heure, pas pour tout le processus

Vous n'avez pas besoin d'un co-fondateur technique à temps plein pour bien recruter. Vous avez besoin d'une heure du temps d'un développeur, deux fois : une fois pour vous aider à rédiger l'offre d'emploi et les questions de présélection, et une fois pour participer à un entretien final ou examiner un test technique.

Qui peut jouer ce rôle :

• Un développeur freelance que vous payez pour deux heures de conseil
• Un ami ou un conseiller qui a déjà développé des logiciels
• Un prestataire que vous employez déjà pour autre chose

Ce que vous lui demandez de faire doit rester précis : « Regardez la réponse de ce candidat à cette question précise et dites-moi si elle tient la route. » Pas « validez-moi cette personne » — c'est trop vague, et c'est trop demander en échange d'un service.

Demandez aux candidats d'expliquer leur propre travail, pas des cas hypothétiques

Un développeur qui a réellement construit quelque chose peut l'expliquer en langage simple, au niveau de détail que vous exigez. Quelqu'un qui a gonflé son CV ne peut généralement pas aller au-delà de la surface.

De bonnes questions, dans l'ordre de ce qu'elles révèlent :

1. « Décrivez-moi quelque chose que vous avez construit et dont vous êtes fier. Que faisait ce projet, et quel était votre rôle exact ? »
2. « Quel a été le problème technique le plus difficile de ce projet, et comment l'avez-vous résolu ? »
3. « Si je demandais aux autres ingénieurs de cette équipe comment c'était de travailler avec vous, que diraient-ils — et pourquoi ? »
4. « Racontez-moi une fois où votre code a cassé quelque chose en production. Que s'est-il passé et qu'avez-vous fait ? »

La quatrième question est la plus révélatrice. Pratiquement tout développeur sérieux a déjà cassé quelque chose. Quelqu'un qui répond « ça ne m'est jamais arrivé » après plusieurs années d'expérience affirmée soit ment, soit n'a jamais livré quelque chose qui comptait vraiment.

Utilisez un petit test technique réel

Vous n'avez pas besoin qu'un candidat construise une fonctionnalité entière gratuitement. Une tâche courte et bien cadrée — quelque chose qui prend 60 à 90 minutes et qui ressemble étroitement au travail réel du poste — vous en apprend plus qu'une heure de conversation.

Restez équitable :

• Payez pour ce travail, ou faites en sorte qu'il soit vraiment assez court pour que l'absence de rémunération soit raisonnable (la plupart des candidats sauront faire la différence)
• Donnez la même tâche à tout le monde à cette étape
• Demandez-leur d'expliquer ensuite leur propre solution — c'est là que vous repérez quelqu'un qui a eu de l'aide sans le mentionner

Si vous n'avez pas le jugement technique nécessaire pour évaluer le résultat vous-même, c'est exactement le moment d'utiliser votre heure de temps technique emprunté.

Si vous préférez ne pas construire un test à partir de zéro, un test de présélection technique calibré peut faire un premier tri avant cette étape — AssessFit propose des tests adaptatifs couvrant un large éventail de compétences techniques, afin de ne pas envoyer chaque candidat directement à votre unique évaluateur technique.

Vérifiez ce qu'ils ont livré, pas ce qu'ils prétendent savoir

Un CV rempli de noms de technologies vous indique ce qu'une personne a touché, pas ce dans quoi elle excelle. Demandez plutôt des preuves concrètes :

• Un profil GitHub, un portfolio, ou un lien vers quelque chose de réel qu'ils ont construit
• Le nom de l'entreprise et du produit, pour que vous puissiez y jeter un œil vous-même
• Quel pourcentage d'un projet leur revenait réellement, par rapport à celui de l'équipe

Ne soyez pas impressionné par une longue liste d'outils. Intéressez-vous plutôt à une ou deux choses sur lesquelles ils peuvent aller en profondeur. La profondeur est le vrai signal ; une large panoplie de mots-clés à la mode en est souvent l'inverse.

Vérification des références : parlez de la livraison, pas des compétences

Vous ne pouvez pas demander à une référence « est-ce que son code était bon ? » et attendre une réponse utile, sauf si cette référence est elle-même technique — et même dans ce cas, c'est une question molle et complaisante à laquelle on répond rarement de façon franche.

Demandez plutôt :

• « A-t-il/elle terminé ce qu'il/elle avait dit terminer, dans le délai estimé ? »
• « Quand quelque chose se passait mal, vous en informait-il/elle tôt, ou l'appreniez-vous plus tard ? »
• « Lui confieriez-vous quelque chose de flou en lui faisant confiance pour se débrouiller, ou faut-il tout détailler ? »

Ces questions ne demandent pas non plus que la référence connaisse le code. Elles demandent seulement qu'elle ait travaillé avec cette personne, ce qui est une barre bien plus basse pour obtenir des réponses honnêtes.

La limite honnête de cette méthode

Rien de tout cela ne remplace le fait d'avoir, à terme, une personne technique de confiance. S'il s'agit de votre premier ingénieur et qu'il n'y a vraiment personne dans votre réseau capable de vérifier ses compétences, c'est un risque qu'il vaut mieux nommer clairement — pour vous-même, et éventuellement pour un investisseur ou un conseiller de la première heure qui connaîtrait peut-être quelqu'un. Une période d'essai de 90 jours avec des jalons de livraison clairs et non techniques (le projet est-il sorti, fonctionne-t-il, les utilisateurs se plaignent-ils) constitue votre filet de sécurité si le recrutement se révèle plus faible que ce que l'entretien suggérait.

Vous n'essayez pas de devenir développeur. Vous essayez de construire un processus capable de faire la différence entre quelqu'un qui a réellement construit des choses et quelqu'un qui a simplement mémorisé les mots pour en parler.