Note : cet article a été initialement publié sur LinkedIn.
Lorsque vous rédigez un article de blog, vous pouvez chercher pendant des heures LE TITRE qui tue. Ce titre racoleur s’inspire de ces bandeaux publicitaires qui fleurissent sur les réseaux sociaux, et qui cherchent à vous défiscaliser OU vous faire rencontrer votre futur moitié, parfois les deux. Mais je rassure tout le monde : on va bien parler de recrutement dans ce post. Je ferai un placement produit à la fin, mais vous verrez, c’est discret (et vous êtes averti).
Recruter des développeurs/développeuses : le sujet de 99% des In Mail que je reçois via LinkedIn. « Comment faites-vous pour trouver des développeurs ? », « Connaissez-vous un ami qui fait du Java ? », « …Quels sites de recrutement me conseillez vous ? »… et enfin mon favori : « Je suis désespéré : mon fiscaliste veut me recruter dans sa startup de putaclic… »
Ces derniers mois nous avons réellement recruté 11 personnes, entre avril 2017 et janvier 2018 pour Lunatech. Des juniors, des séniors et des team-leaders. J’ai testé à l’occasion différents canaux. Et c’est surtout de cette expérience dont je souhaite parler. Recruter en tant que de tel c’est une vraie chasse. Identification de la ressource, acquisition, cycle de recrutement, closing… Tout s’apparente à de la vente.
Côté « je donne des chiffres pour relativiser » : nous sommes une SSII / ESN / boite de conseil. Nous ne sommes pas 1000, pas 100, mais 20. Oui juste 20 pour la France et 80 pour la Hollande. Et donc 11 personnes en 9 mois sur ces 20… Pas de département de chalutage, pardon, de recrutement à notre disposition. Nous sommes 2, nous sommes déterminés et organisés.
…voici une petite partie de nos secrets enfin dévoilé…
D’abord définir les besoins et rédiger des offres de poste réaliste. Je conseillerai de toujours faire relire vos offres aux futurs managers qui seront en charge d’encadrer les candidats. Et n’ayez pas peur de parler franchement, d’être vous même. Un costume et une cravate ne sont pas des attributs qui rendent plus intelligent. Juste plus sûr de soi-même. De même, un style neutre et ampoulé peuvent parfois décourager de bons candidats, et n’arrêteront pas les CV Bomber (ceux qui proposent leur candidature mais n’ont pas lu l’offre).
A propos de relecture d’offres d’emploi : attention aux coquilles, particulièrement sur les technologies que vous recherchez. Le développeur (H/F) reconnaît à 200 mètres un piège mal placé, une coquille telle que : « jithub« , « htlm« , « java script » ou « micro sévices » (au lieu de microservices…).
Une fois l’offre publiée, vous recevrez des candidatures. Et il sera temps de s’organiser, de préparer des entretiens techniques. Sur l’aspect gestion et suivi, notre vitesse de recrutement pour le poste « Développeur Java/Scala » est de 20 jours en moyenne. Entre la prise de contact, les entretiens, et l’envoi d’une offre : nous allons le plus rapidement possible. Et je vais vous expliquer comment.
Nous utilisons Workable, une plate-forme SaaS qui permet de gérer les candidatures, d’effectuer un suivi et de s’assurer que « … mince j’ai oublié de recontacter ce candidat… » n’arrive pas.
Sur le poste « Développeur Java/Scala » nous avons traité 29 candidats au total. Nous avons recrutée 11 personnes au final sur cet ensemble. Comme vous le voyez, le taux de transformation n’est pas très élevé. Il faut donc déployer pas mal d’énergie entre l’acquisition, l’identification et ensuite les entretiens, pour recruter. Un ratio de 33% est plutôt bon, croyez moi.
Ce graphique montre pour le poste « Développeur Java/Scala (H/F) » la vélocité moyenne entre les étapes de notre processus.
Comment recrutons-nous ? Nous effectuons un premier tri sur les candidatures reçues ou proposées par des chasseurs de tête. Ensuite, nous effectuons 2 entretiens, un test technique et c’est tout. Un processus assez court améliore la réactivité, tout en étant suffisant pour recruter.
En tant que candidat, lorsqu’une entreprise me contacte, j’aimerai savoir « comment elle m’a trouvé » et surtout « pourquoi moi ? ». Pour nous, cela passe par une phase d’identification, visite des repositories Github, consultation de LinkedIn et de Twitter, pour voir si le ou la candidat(e) a une identité numérique. Est-ce qu’elle est en fait contributeur d’un outil ? Quels sont ses derniers tweets ? C’est des petits plus pour qualifier des candidats. Et cela permet souvent de démarrer la discussion lors du premier entretien. N’hésitez pas à préparer une fiche sur votre candidat avant l’entretien.
Le premier entretien pour moi doit servir autant le candidat que la société qui recrute. Durant cet entretien, je présente notre société et son activité, la composition des équipes et les types de projets sur lesquels nous travaillons. Etant développeur il est plus facile pour moi d’aborder immédiatement les sujets techniques. C’est forcément un plus, lorsque l’on s’adresse à un candidat. Peut-être que vous pouvez demander à vos développeurs, certains aiment bien faire des entretiens.
Les développeurs s’intéressent en premier lieu au projet que vous pouvez leur proposer. Quelles technologies ? Perspective d’évolution ? Environnement ?
J’ai noté que les sujets « salaire » ou « emplacement des bureaux » sont accessoires. Les développeurs s’intéressent à ce que l’entreprise va leur permettre d’apprendre, ainsi que les conditions de travail. Pour notre part, nos développeurs ont tous un ordinateur portable (en général Macbook Pro). S’ils souhaitent travailler de temps en temps de chez eux, nous l’acceptons. Je parle souvent de Slack, Github, Pull-request pour expliquer au candidat comment nous travaillons.
Durant le premier entretien toujours, je demande au candidat : « Pourquoi souhaiteriez-vous quitter votre entreprise ? ». Ceci permet de comprendre les motivations. Le salaire souvent mais c’est surtout l’ennui qui déclenche la décision de partir et de voir ailleurs. Sur les salaires, les SSII payent mal les développeurs en France. Mal les personnes expérimentées, alors que ce sont souvent les éléments clés d’un projet. Tant pis pour elles, nous les recrutons et nous avons de très bons séniors.
Comment faisons-nous pour recruter dans ce cas ? On paye les gens correctement, au prix juste selon leur expérience et leur valeur sur le marché. Les salaires vont de 30k à plus de 65k. Une personne excellente techniquement et à même de diriger 5 développeurs, se doit d’être reconnue et payée en conséquence. Vérifiez toujours la grille des salaires sur le marché pour le profil du candidat ciblé. Je demande toujours le niveau de rémunération actuel et le souhait du candidat, afin de comprendre son projet. Si quelqu’un est mal payé dans son poste actuel, il me l’aura déjà dit dans ses motivations à quitter sa société.
A l’issue du premier entretien nous avons les informations suivantes :
- résumé du parcours en 3 phrases : permet d’expliquer à son collègue qui est le candidat
- son dernier projet/équipe actuelle : bosse-t-elle seule ou en équipe ? Connaissance des méthodes Agiles, Git, etc.
- pourquoi la personne souhaiterait quitter son employeur : ennui ? salaire ? autre ?
- age, salaire actuel, salaire souhaité, formation/étude : les éléments légaux pour le salaire
- twitter, github, marque sur Google, conférences : les petits plus pour mieux comprendre le candidat
Le deuxième entretien est plus technique. Il permet au candidat d’expliquer ce qu’il veut faire. Pas forcément ce qu’il fait actuellement. Par exemple, j’ai fait passer un entretien à un excellent AMOA, issu du monde du développement. Son CV ne m’aurait jamais laissé penser qu’il était aussi un développeur Scala en devenir. C’est en échangeant avec ce candidat que j’ai compris le potentiel de la personne, que nous avons recruté. S’arrêter au CV (ou au profil LinkedIn mal complété) est une erreur. Cela étant dit : de trop nombreux candidats n’ont pas de CV ou de page LinkedIn à jour. Certes, personne ne les trouve (sauf nous) mais bon, faites un peu un effort si vous êtes candidat.
Deuxième partie du deuxième entretien : je demande au candidat de nous poser des questions. Librement. Que pensez-vous de Clojure chez Lunatech ? Est-ce que vous ne faites que du Scala ? Est-ce que l’on peut proposer un nouveau framework ? etc. Si le candidat n’a pas de questions, c’est qu’il n’est pas intéressé. Mieux vaut s’arrêter là. En général, les candidats veulent en savoir plus.
A l’issue du second entretien : nous savons si nous voulons passer à l’étape du test technique. En général il nous faut entre 2 et 8 jours pour arriver à cette étape. De l’identification d’un candidat à « … je lui ai parlé et ça vaut le coup de passer le test technique », moins d’une semaine. La vélocité est la clé.
Troisième étape : le test technique.
Nous pourrions avoir un QCM pourri. Ou demander à un non-développeur de faire passer l’entretien. Nous pourrions aussi lui poser 10 questions très tordues comme celle-ci : vous avez 8 ballons de basket de même forme et même aspect. L’un des ballons est plus lourd que les 7 autres. En ne faisant que 2 pesées, comment feriez-vous sur une balance pour trouver le ballon le plus lourd ? réponse…
Non. Nous faisons coder les candidats, et voici comment.
Nous proposons un énoncé relativement simple, un petit projet à coder en une semaine. Le candidat dispose de fichiers de données fictives, et doit réaliser une application avec quelques consignes d’architecture ou techniques. Les données peuvent par exemple être générées avec un site comme Mockaroo. Peu importe les données, nous essayons d’avoir un volume intéressant pour que le candidat ait un peu de challenge.
Ensuite, selon le type de profil recherché (plutôt dev front, plutôt backend, plutôt l’ami de Mickey…) nous orientons différemment les questions. Cela étant dit, nous essayons de laisser le candidat choisir la technologie et les frameworks de son choix.
Enfin nous nous retrouvons une semaine plus tard. Via Appear.in ou en face à face. C’est là qu’il découvre nos locaux, notre fresque, bref un environnement qui doit donner envie de travailler.
Le candidat a alors une heure pour présenter sa solution, parcourir le code, et expliquer ses choix. En général, nous demandons à voir le code la veille, afin d’avoir le temps de préparer l’entretien au mieux.
Cette interview entre développeurs permet de valider plusieurs points :
- la capacité à expliquer ce qui a été fait
- la gestion des bugs, des incidents et du stress lorsque je casse le code volontairement
- l’esprit de synthèse et la simplicité dans l’approche
- et finalement, est-ce que je me vois coder avec lui ou pas lundi prochain ?
Que nous apprend-t-on lorsque nous sommes étudiants en informatique ? A écouter, et à apprendre. Pas à coder. Vous apprenez à apprendre. La clé du métier de développeur c’est la capacité à apprendre. Quelque part, la définition d’un bon développeur est là : une personne à même de progresser, d’apprendre et de découvrir chaque année de nouvelles technologies. Et c’est ça que l’on cherche à évaluer en entretien technique.
L’une des clés j’en suis convaincu : faîtes coder vos candidats. Cependant, respectez aussi leur temps personnel et ne leur demandez pas un projet insurmontable, qui prend plusieurs jours à coder. Le développement c’est du fun et du plaisir. Pas une punition à essayer de fixer une dépendance node ou un package sbt récalcitrant. La réalité de notre métier c’est que nous avons accès à StackOverflow, à des collègues et que nous pouvons nous aider les uns, les autres.
Je peux demander à un candidat de m’expliquer ce qu’est un Functor, une Applicative ou une Monad… mais est-ce que ma question sur les ballons de basket n’était pas plus marrante au final ? Je gagne quoi si le candidat répond correctement ? En quoi mes clients seront-ils plus heureux ?
Etape finale : la proposition d’embauche. Le test technique nous demande pas mal de temps et d’efforts. C’est pour cela que nous ne gardons que la moitié des candidats avant cette étape. Et vous verrez sur le graph ci-dessous que nous ne disqualifions presque pas.
La rédaction de la promesse d’embauche est importante, et elle doit s’effectuer rapidement. Si vous n’êtes pas certain de vouloir recruter la personne, ne la prenez pas. Si vous tardez à répondre et que vous avez besoin de plus de 48h pour prendre votre décision : ne la recrutez pas. A cette étape si le travail a bien été fait, la promesse d’embauche est une formalité.
Il ne reste plus qu’à accueillir et à prépare ensuite l’arrivée de la nouvelle personne dans l’équipe. Commander son Mac (ou autre), s’assurer que le bureau est prêt, que ses identifiants techniques sont tous créés… Mais nous parlerons de cela dans un autre article avec un titre tout aussi racoleur. Promis.
Avouez, vous avez craqué et tout lu non ?
Allez, la page pub comme prévu maintenant :
Lunatech France recrute, découvrez nos offres et envoyez-nous sinon un petit mot par email à jobsfr@lunatech.com
Cliquez ici –> Oui moi aussi je veux changer ma vie et devenir développeur chez Lunatech, je souscris sans engagement. <– là
0 no like
Heu … parce que tu crois qu’on en est encore au stade où on a envie de passer des tests techniques ? 1 semaine de coding à la maison en plus !
Te rends-tu compte du délire dans lequel tu vas ? Depuis quand faut systématiquement se faire chier à ce point pour avoir un job lors d’un processus de recrutement ? Si toutes les boîtes feraient pareilles, on serait bien dans la merde.
Est-ce qu’on demande à un coordonnier de travailler une paire de chaussures pendant 1 semaine avant de prendre une décision ?
Salut Jacques la Fripouille (l’anonymat c’est mieux pour répondre…)
Il y a une différence entre un délai et le temps nécessaire pour faire une tâche.
Le délai : oui le candidat a une semaine pour le faire, car il n’a pas que cela à faire. Il a une vue professionnelle et pas sa semaine à y consacrer. Le temps nécessaire : chacun fait ce qu’il veut. Des candidats en 3h de boulot ont terminé. D’autres y consacrent 10mn… C’est un moyen de détecter si nous avons assez intéressé le candidat (ou pas).
Enfin ton analogie avec le cordonnier est assez boiteuse. J’aurai plus l’image d’un groupe de musique. Et oui, on a bien envie d’entendre ton niveau en trompette ou pardon, en pipeau, avant d’aller plus loin.
Bonne continuation
Bonjour,
Une chose est sure c’est qu’avec ce processus de recrutement tu ne recherches pas des profils comme Jacques 🙂
Par contre, avec ce système de recrutement peut-on quand même se tromper ?
Laurent
Hello,
Les tests techniques c’est sympa. Mais ça doit être compliqué de trouver des jeunes diplômé-es en Scala.
Par curiosité, sauriez-vous quelles écoles/universités enseignent ce langage?