Cela fait quelques fois désormais qu’en discutant recrutement tech deci delà avec d’autres startupers / CTOs je me rends compte que mon process se démarque un peu et dénote parfois avec originalité par “sa journée test”.

Je ne pense pas avoir là trouvé la solution idéale, puisque malgré cela je n’ai pas fait que des recrutements heureux, parce que cela prends du temps et que ce n’est pas adapté à toutes les typologies de boîtes (cela marche pour nous en tout cas en ce moment), mais je pense que cela vaut le coup d’être tenté au moins pour quelques profils clés.

Dans mon process type de recrutement, il y a tout d’abord une phase amont où on apprends mon candidat et moi à se connaître sur le papier, puis ensuite lors d’un premier entretien. Là, je présente de la façon la plus limpide et franche ce que nous faisons, là où nous sommes bons, là où nous sommes mauvais, comment nous fonctionnons, et surtout, ce que j’attends du candidat pour le poste en question : pour pas qu’il n’y ait de zones d’ombres pour le candidat, sur l’environnement de travail et la mission envisagée. Et aussi pour le mettre en confiance en commençant à parler. Là, j’attends ensuite qu’il joue cartes sur table et me montre via des projets (open source, perso, pro, académiques) ce qu’il sait faire, ce qu’il aime faire, ce qu’il aime moins faire, et ce qu’il aimerait faire. Je pense qu’à cet entretien, j’essaye de jauger durant 40% du temps de l’entretien les compétences techniques de mon candidat, et le reste du temps sa personnalité, sa motivation, et le fit potentiel pour l’équipe. Et aussi occasionnellement ses “prétentions salariales” ;)

En général, sur 10 candidats initiaux, deux réellement se démarquent et m’intéressent suite à ce process. C’est à ce moment là que je propose une journée de test en condition réelle dans nos locaux.

L’intérêt de cette journée est double:

• Pour le candidat : ça lui permet de voir réellement la qualité du code, des développements, de ses futurs collègues et l’ambiance de la startup durant toute une journée. Ce point est très important pour moi, car c’est à mon sens un raison majeure des mauvais recrutements: de fausses / mauvaises promesses (involontaires la plupart du temps) à l’embauche qui vont rapidement démotiver le développeur une fois in situ.
• Pour moi recruteur, mais aussi pour mes développeurs, c’est le moyen de tester le candidat en live / en pair coding sur des réels problèmes de codes de la solution. Cela ne me sert pas à grand chose à priori un cador dans un domaine si au bout d’une demie journée je ne le vois pas force de propositions ingénieuses (pas forcément correctes hein) sur une réflexion réelle et business appliquée à mon cas réel. Certains candidats performent étonnamment bien sur des entretiens amont et des problèmes “types” d’entretien, et sont relativement “plats” en vrai. Cette journée permet aussi de jauger de la rapidité d’assimilation / réflexion / implémentation / proposition d’idées du candidat, en situation réelle toujours. C’est un point important que j’ai toujours trouvé difficilement quantifiable sans cette journée de test. Enfin, cela me permet de récolter plusieurs points de vue suite à cette journée, ceux de mes développeurs (trouvent-ils qu’il a le niveau ? se voient-ils travailler avec lui ?) et même ceux de mes commerciaux, ou tout autre domaine-related employé de la boite. Une nouvelle recrue dans une équipe, c’est certes un nouveau profil qui doit correspondre à une certaine attente, un certain profil, mais aussi une pièce de puzzle qui doit s’assembler avec les existantes déjà présentes, et cela a parfois autant de poids que la nouvelle pièce en elle-même.

Attention, cette journée est une journée bien huilée et préparée. Sans un minimum de préparation, cela ne servirait pas à grand chose, et serait plus une perte de temps. On ne catapulte pas un nouveau venu n’importe comment dans l’arène ;)

Le programme :

• Bien souvent, je fais un petit tour du propriétaire avec le candidat, aussi bien au niveau de l’équipe que de l’archi et de certains bouts de code. Cela dure une petite heure.
• Le candidat va ensuite rejoindre la team qu’il serait amené à compléter, et va cotoyer chaque dev de celle-ci entre 30 minutes et une heure. Ce temps sert pour chaque dev à expliquer son quotidien, et passer un peu de temps en pair coding afin de challenger le candidat et le jauger, chacun un peu à sa sauce (certains sont plus vicieux que d’autres, et bien plus souvent que moi).
• Tout cela nous porte généralement au déjeuner tardif (14h): là c’est l’occasion pour une grande partie de la team de partager le repas avec le candidat et de se détendre autour d’un ping pong.
• Suite à cela, il reste 1-2 heures de travail où le candidat est placé seul sur un sujet qu’il aura abordé et auquel il aura été “formé” par un autre dev le matin, afin de le continuer seul et de jauger en fin de journée sa rapidité, sa rigueur, sa technicité.

Cela fait une journée bien remplie, pour le candidat comme pour moi, où je dois trouver le plus de disponibilité au sein de mon équipe et avec un ou deux challenges techniques accessibles pour ce candidat (une matinée pour apprendre et s’immerger en pair coding, une aprèm pour y travailler seul).

Cela doit facilement prendre 4 heures de temps homme à la boite au niveau de la salle dev, 3 heures de “formation”/”culture gé” dispensé au candidat, et 2-3 heures de travail “effectif” réalisé par ce dernier. Il est à noter que cette journée n’est jamais rémunérée (mais dédommagée niveau transport et dejeuner) et que le travail effectué par le candidat est rarement repris (car même si le travail est bon, il ne sera jamais suffisant en l’état pour intégrer la branche principale, sans être lourdement refactorisé, et par conséquent, souvent repris from scratch par un des devs de la team).

Et vous, avez-vous ce genre de journée dans vos process de recrutement ? Avez-vous d’autres “curiosités” notables ?