Recruter un dév / tech en startup

Recruter un dév / tech en startup
La vision d'un entretien d'embauche par Stable Diffusion. A prendre au second degré.

J'ai eu la chance durant ma carrière d'être à des postes où j'aidais des recruteurs à filtrer des candidatures et à faire passer des entretiens d'embauche, voire à recruter pour ma propre société.

Je ne suis pas RH, loin de là, mais j'ai toujours trouvé le processus passionnant, nécessitant de comprendre à la fois les motivations du recruteur, et ce qui se cache au fond d'un CV ou d'une lettre de motivation (pour expliquer aux plus jeunes ce qu'est une lettre de motivation : non, laissez tomber, c'est un truc de boomer 😎). Je n'ai pas la prétention de me substituer à un recruteur, mais j'ai une vision très tech et très projet de la façon de recruter, ce qui est utile, surtout quand le recruteur ne sait pas trop ce qu'il cherche.

Ayant été de passage à Station F dans la Founders 2.0 (un programme d'accélération pour les startups), j'ai eu la chance de pouvoir aider une jeune startup dans un processus de recrutement d'un BackEnd.

Quand on démarre une startup prometteuse, on a vite besoin de combler certains besoins vitaux - tech très souvent - et les fondateurs n'ont pas toujours l'expérience pour recruter. Il me semblait intéressant de partager l'expérience.

Recruter, oui, mais pourquoi ?

Un ami m'a un jour dit : "en startup, il ne faut recruter que quand on n'a pas le choix." Ca parait du bon sens, mais parfois certaines startups recrutent pour augmenter le head count - et la valorisation présumée de l'entreprise, quitte à ensuite devoir trouver ce que feront les nouveaux venus... Ce n'est pas une très bonne stratégie.

Quel rôle pour les premiers ?

Les premiers membres de l'équipe sont les plus précieux en startup - il ne faut pas se rater sur l'embauche, car ils vont avoir une profonde influence sur le démarrage de votre activité.

Si vous ne connaissez rien en tech et devez recruter un développeur, entourez vous de gens qui vous aideront !!

Il va falloir déterminer le rôle cherché :

  • Tech Lead : cherchez-vous la personne qui va gérer tous les problèmes techniques qui vont surgir - et aider d'autres dév. moins expérimentés ?
  • Architecte : avez-vous besoin de quelqu'un qui va concevoir l'architecture de votre système ? Et dans ce cas, qui va réaliser le système ?
  • CTO : va t'il gérer une équipe tech, ainsi que les besoins d'infra, les discussions avec les partenaires, les sujets transverses et la direction globale du dév. ?
  • Ou un peu tout à la fois ?

Il est aussi important de définir si vous avez besoin de quelqu'un de senior, si il devra manager ou développer, ou s'il vous faut un couteau suisse, prêt à endosser n'importe quel rôle.

En général, un couteau suisse, ça dépanne beaucoup, et ça permet de pivoter plus facilement.

Comment les trouver ?

De nos jours, on trouve de nombreux canaux pour recruter. Citons pêlemêle Welcome to the Jungle, LinkedIn, SkillValue...

Il est aussi possible d'aller démarcher des gens compétents déjà en poste (pas très fair-play mais c'est la vie 🙄) ou d'aller proposer à un indépendant compétent sur Malt de rejoindre une aventure en startup...

Le process de recrutement d'un dév

Ce que je vais écrire est très loin d'une vérité universelle : chacun a son opinion sur le sujet. En ce qui me concerne, il y a plusieurs points à traiter :

  • les compétences techniques
  • l'adéquation avec la vision de l'entreprise
  • la capacité de travail en équipe
  • l'autonomie
  • équilibre entre qualité / vitesse de développement

L'aspect technique est bien sur très important, mais ce qui départagera pour moi deux candidats, sera l'adhésion à la vision de l'entreprise et la capacité à développer vite pour pivoter / ou plus lentement pour privilégier la qualité, en accord avec les besoins de l'entreprise.

De l'intérêt de filtrer les candidats

On a vu juste avant les sources potentielles de recrutement. Vous allez sans doute voir beaucoup de candidats, alors filtrez la liste dès le début ! Les moteurs de recherche sont rarement très pertinents, n'hésitez pas à éliminer les gens qui vous semblent :

  • ne pas posséder les bonnes bases techniques
  • trop juniors ? Trop seniors ?
  • sur un fuseau horaire très différent ?
  • ... tout ce qui vous semblera rédhibitoire
Une fois de plus, il peut être pertinent de bien s'entourer pour réaliser ce filtrage !

N'oubliez pas qu'un processus de recrutement, c'est très long ; donc, si vous avez des doutes dès le début, alors : ne poursuivez pas !!

Un déroulement classique

En général les étapes du recrutement ressemblent à ce plan :

  1. Filtrage des candidats
  2. Première prise de contact (email /DM...)
  3. Premier call par un fondateur (permet de jauger l'intuitu personae)
  4. Si ok : test technique
  5. Si test ok : Call avec les autres fondateurs et/ou un/des autres employés pour valider
  6. Si ok : proposition ! Les bons candidats sont très recherchés !

Remarque : Il est important de prendre le temps au début d'appeler le candidat pour vérifier, déjà, que le CV et ce qu'on a lu est à jour, et si le contact passe bien.

Puis, passer à un test technique.

Pourquoi un test technique ?

Les opinions sont souvent partagées, voire tranchées sur le sujet. Certains détestent ça...

Le test technique n'est pas la panacée, mais, en fonction de comment il est fait, il est un bon révélateur du niveau technique et de l'adéquation au poste.

Si votre candidat ne veut pas en entendre parler, peut être n'est ce pas le bon candidat ? 😎

Quel test technique ?

En général, chaque type d'embauche nécessite un test spécifique, en fonction du poste recherché (FrontEnd, BackEnd, Data Scientist, Dév Mobile...) et de la séniorité voulue, pour être révélateur.

Pour un test technique, en terme de durée, il faut compter entre 2 heures 30 et 3 heures 30. J'aime bien le décomposer en plusieurs étapes - à vous d'adapter le déroulé et les durées :

1- Test générique à base de QCM (45 minutes)

2- Réalisation d'un projet (2 heures à 2 heures 30)

3- Sujets techniques ouverts (optionnel : 30 minutes)

Remarque : en général, je fixe avec le candidat un créneau horaire ; il réalise chez lui le test, sans supervision, mais doit impérativement respecter la durée !

Le test générique est assez simple à faire, de nombreuses apps proposent de choisir des questions à poser ; citons TestDome, par exemple, qui permet de créer un QCM en piochant des questions de difficultés et de thèmes variés. On a une durée approximative à chaque question, on peut ainsi bâtir un QCM.

Le test de réalisation de projet est pour moi le plus intéressant : on fournit au candidat un mini cahier des charges / recueil de besoins, plus ou moins précis (avec potentiellement des recommandations à respecter), on lui demande de réaliser un projet répondant aux besoins, et de fournir les outils pour tester le produit réalisé. En général, on énumère dans les besoins un certain nombre de demandes décorrélées les unes des autres – ainsi, le candidat pourra s'arrêter quand il n'aura plus assez de temps, et pourra livrer quelque chose de fonctionnel. On vérifiera la qualité du résultat et le respect des exigences.

Enfin, les sujets techniques ouverts peuvent être un bon moyen de jauger la curiosité et les connaissances du candidat, ou sa façon de répondre à un problème en particulier.

A adapter !

Comme on l'a dit, le test doit être adapté en fonction du poste.

Par exemple, pour un BackEnd, il pourrait être bon de demander de réaliser :

  • Une API, en REST ou GRPC, avec des fonctions CRUD qui interroge une base de données ? Et de vérifier la qualité de la remontée d'erreurs ou d'exceptions ?

(si vous n'avez rien compris à la phrase précédente, ce n'est pas grave, c'est technique 😉)

Pour un Data Scientist, en revanche, on mettra l'accent sur la clarté des explications et la capacité à rendre le sujet compréhensible ainsi que la mention des outils ou des techniques utilisées, même si le candidat n'a pas eu le temps de tout finir.

L'intérêt du test

Je n'étais pas convaincu, auparavant, de l'intérêt du test technique.

Mais j'ai rencontré des gens dont la capacité à se vendre était bien supérieure aux compétences... le test m'a permis d'éviter à de nombreuses reprises des problèmes ultérieurs de casting.

L'autre intérêt du test : il est relativement long, le temps est limité et très strict : on place le candidat dans une situation de stress, on peut ainsi voir comment il le gère - dans une startup, ce genre de situation est monnaie courante.

En conclusion

Voici donc quelques retours sur des expériences de recrutement que j'ai pu vivre. Je ne prétends une fois de plus pas être RH, il m'a fallu adapter un système qui permette rapidement d'avoir une vision claire des qualités et défauts d'un candidat, et de son adéquation au poste.

Et si d'aventure vous êtes dans le recrutement et que ma présentation vous a interpellé / intéressé / horrifié, n'hésitez pas à me le dire !