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 ?
Méthode testée et approuvée, en tant que candidat et “collègue” dans une moindre mesure.
Je suis plutôt d’accord avec ce qui tu dis dans le post, la première fois que l’on m’a fait faire une telle journée, c’était plutôt amusant, malgré le fait que c’était au tout début de la startup. On apprend beaucoup de choses, on se fait de nouvelles connaissances (tant techniques que humaines), et surtout on assimile bien mieux le cœur du métier…
Quoi de plus important aussi que de vivre l’expérience startup – peut-être pour la première fois pour certains – de l’intérieur, avant d’effectivement rejoindre la startup ?
Comme on recrute assez rarement, on n’a pas un processus de recrutement très “rodé”, mais on n’a pas ce genre de journée en tout cas. On fait en général coder les recrues techniques dans nos locaux, mais sur 1h30 – 2h.
Personnellement j’aime assez le concept d’avoir une journée entière pour ça, pairer avec plusieurs devs puis travailler seul. Ça demande du temps et de l’organisation, mais si vous y arrivez chapeau :)
Le process s’adapte bien au junior (stage, alternance, premier emploi), beaucoup moins bien à ceux qui ont de l’expérience. J’irai même à dire que c’est une process qui pourrait décourager un bon dev avec de l’expérience (+ de 2ans). Personnellement, posé une journée de congé pour passer un test, ça me gonfle. Tu passe déjà 2, 3 voir 4 entretiens avec chacune des boîtes qui t’intéressent, ce qui te prend un temps non conséquent quand tu es en poste.
A mon sens il est important pour un nouveau développeur exigeant de connaître les questions pratiques qui sont la qualité du code, des développements, de l’ambiance, missions… Mais il est tout à fait possible par la discussion de cerner ses choses.
A tu discuté avec Capitain Train ? Il me semble qu’ils ont un process de recrutement assez pointu. Je sais que de bons développeurs sont passés à côté car ils ont trouvés le process trop lourd.
Dans ton billet, tu n’a pas précisé quel genre de poste tu pouvais être amener à proposer et par quel type de développeur. Sous-entendu des stages, ou des postes en CDI plus expérimentés ?
Hello Maxime. Merci pour ton commentaire :)
Ce process n’est absolument pas rentable pour un stagiaire ! Les stagiaires, ça ce négocie en gros par téléphone. Sinon c’est de la perte de temps. (je force le trait hein..)
J’applique ce processus pour tous mes CDI tech. Je l’ai fait aussi bien avec des “jeunes” CDI de 1-2 ans qu’avec des plus expériementés de 7-8 ans. Tous ont retenu une excellente journée d’intégration, même les quelques uns non retenus en fin de compte.
Cette journée n’est absolument pas une journée de travail, mais de découverte. C’est plus comme une ouverture d’esprit, le candidat pour voir comment ça marche et s’ouvrir à ce qu’on fait, et nous réciproquement, écouter son retour critique et le titiller un peu sur place.
Je me suis peut-être mal exprimé en fin de post. On n’a jamais repris le travail d’une de ces recrues. Juste les bonnes idées / remarques qui ont alimentés les prochains développements de la team :)
Et ça, cet échange sur une journée, avec un stagiaire, ça peut difficilement (sauf rare exception) être le cas.
“Personnellement, posé une journée de congé pour passer un test, ça me gonfle. Tu passe déjà 2, 3 voir 4 entretiens avec chacune des boîtes qui t’intéressent, ce qui te prend un temps non conséquent quand tu es en poste”
Le but étant de trouver un nouvel emploi qui t’intéresse plus et te corresponds mieux, l’investissement n’en vaut-il pas la peine ?
+1. En plus je soupçonne que cette journée permet aussi de réduire le nombre d’entretiens.
Je pense que je suis mal exprimer, sans aller au fond de ma pensée.
Bien sur dans l’absolue ça en vaut la peine.
Maintenant met toi à la place de l’ancien employeur. Si chacune des entreprises auxquelles tu postules tu dois poser une journée de congés, ton ancien employeur ne sera pas très ravie (à ce niveau là Syntec n’aide pas du tout)
Donc il va de soit qu’il faut déjà passer un premier entretien formel comme le précise Guillaume.
Le monde étant petit, en générale tu souhaite garder bon contact et partir en bon terme.
Ensuite ça reste mon avis perso, les tests de code, je déteste ça.
J’ai aussi dans les cartons, un billet sur “pourquoi votre développeur quitte votre start up”. Si ta journée de découverte peut éviter un départ après moins d’un an, dans ce cas ton process de recrutement est validé. Je t’enverrai un lien du draft sur twitter.
Sans lancer un débat sans fondement, je pense que dans certains languages, les process de recrutement peuvent être différent suivant la situation du marché (peu de candidat par rapport à une forte demande)
Je trouve cela intéressant et pertinent sauf sur deux points :
Le fait que cette journée ne soit pas rémunérée. Je ne vois pas pourquoi ?
L’attente de l’employeur à avoir des “proposition d’idées du candidat, en situation réelle …”
Je comprend que l’entretien d’un candidat peut être parfois trompeur sur la force de proposition de celui-ci en situation réel, mais des candidats timide (essayant de prouver lors de l’entretien qu’ils sont force de proposition) auront certainement plus de mal à le faire en situation réel avec un développeur confirmer dans une équipe, mais peut être seulement après se sentir accepté au sein de la boite / équipe (variable de 1 journée à 1 mois, perso pour moi c’est 1 semaine).
Bien sûr, tout dépend du genre de poste, je parle dans le cadre d’une développeur qui rejoint une équipe.
Hello Pierre,
Concernant la non-rémunération de la journée, je te renvois à mon commentaire précédent à Maxime : je conçois cette journée comme un échange, une expérience, une ouverture d’esprit mutuelle. Il ne s’agit pas d’une journée de travail. Le dev investit du temps pour connaitre la boite, et la boite, du temps pour connaitre le dev. C’est du troc. Il n’y a pas de relation pécuniaire là dedans.
Je n’oblige personne. Et ce n’est pas un processus obligatoire, une personne qui n’a pas le temps / les moyens (une a fait qu’une demi journée par exemple, ne pouvais pas plus). C’est juste un énorme plus pour moi et surtout pour le candidat. En tout cas, à chaque fois, cela lui a été très bénéfique.
Je suis un peu partagé. Je pense qu’il est difficile de ne pas présenter cela à un employé comme une “énième épreuve” non facultative.
Je comprend l’intérêt de cette “expérience” pour le profit de l’employé et de l’employeur, cela me parait effectivement pertinent sur la journée car cela évite deux choses :
1. Pour l’employé de ne pas se lancer dans une procédure de changement de travail alors qu’il ne “sent” pas l’environnement de travail
2. Pour l’employé de ne pas perdre son temps avec un employé dans le point 1.
Mais si c’est pour “jauger en fin de journée sa rapidité, sa rigueur, sa technicité” il s’agit bien pour moi d’une “énième épreuve”.
Aussi, je pense que la période d’essaie est un peu la pour ça. Il ne faut pas l’oublier non plus qu’elle est à double sens.
C’est tellement une tannée le recrutement que j’ai vraiment envie de minimiser le risque de ne pas transformer une période d’essai en CDI. Relancer un process, avoir perdu les bons candidats qui avaient postulé et que l’on avait pas retenu car pas assez creusé le profil d’un tel ou d’un tel..
Jusque à présent, j’ai peut-être eu pas mal de chance, mais ce processus m’a permis 100% de transfo de période d’essai, et quelques bonnes journées qui ont profité à tout le monde.
Je conçois tout de même que cela ne plaise pas à tous les profils / sensibilités :)
tu n oblige personne mais tu perd peut etre les meilleurs qui n ont pas une journee a offrir gratuitement, donc je rejoindrai un commentaire precedent, pour recruter un junior qui ne demande qua se faire exploiter ca semble un bon process de recrutement, pour un senior qui a un peu d amour propre et qui sait qu il trouvera un job de toute facon . . . . ca ne doit pas trop marcher.
C’est marrant, je pense l’inverse.
Si je dois changer de boite, je veux vraiment être sûr que je ne me trompe pas. Donc bosser une journée avec mes futurs collègues me semble une bonne idée pour me faire une opinion plus précise de l’entreprise. Je prendrais vraiment ça comme une opportunité *pour moi* d’évaluer l’entreprise.
En clair, il me semble que ce genre de process arrange celui qui est en position de force sur le marché du travail et qui *doit* bien choisir.
Billet sur le même sujet chez AF83: http://dev.af83.com/2013/09/04/recrutement_remplacer_l_entretien_technique.html (inspiré par celui-ci ou pas :p).
Excellent idée c’est sur. J’ai moi même eu des problèmes de recrutement qui auraient pu être évités avec cette méthode, mais….
Jamais rémunéré dites vous?
En plus d’être carrément illégal ( je ne vous souhaite pas une visite surprise de l’inspection du travail ou un accident du candidat dans vos locaux… ou tout simplement un candidat qui, mécontent d’apprendre qu’il n’a pas été retenu, vous fasse une petite surprise….), je trouve cela éthiquement douteux: vous donnez un signal que chez vous le travail n’a pas de valeur (ou peu).
Tout travail mérite salaire, d’abord.
Imaginez ensuite le jour où tous les employeurs feront cela (car c’est une bonne méthode), cela revient à payer pour être embaucher.
Et quid de ceux qui prennent une journée de congé (peut être non payée) pour venir postuler chez vous, et vous offrir une journée d’expérience, que vont-ils en retirer si ils ne sont pas retenus?
Enfin vous avouez vous même: “le travail effectué par le candidat est rarement repris tel quel (certaines fois jamais repris même).” C’est là que le bas blesse…. leur travail devrait être détruit systématiquement comme dans un coding dojo.
Bonjour Guillaume,
Merci pour votre commentaire et point de vue !
Je pense que nous sommes de chaque côté de la barrière, moi l’employeur, et vous l’employé. Jamais dans votre commentaire vous faites mention de l’expérience apportée par moi et mes équipes au candidat, du temps qui lui est consacré, de la formation qui lui est dispensée toute une matinée afin de ne pas être catapulté dans le néant deux petites heures l’après midi. Nous donnons un signal au candidat que ce qu’il apprendra chez nous, l’émulsion de l’équipe et des technos de pointe que nous maitrisons, ont plus de valeur qu’un travail de bétail en SSII ou grosse boite sclérosée. A partir du moment où le candidat perçoit ceci, il n’a aucun problème à venir effectuer sa journée. S’il ne le comprends pas, c’est qu’il ne conviendra pas avec l’esprit de notre startup, nous le respectons, et c’est très bien que cette journée l’ait démontré (avant même qu’il la fasse, si le projet de la journée le repousse).
Nous rémunérons très correctement tous nos employés. Ils détiennent tous des parts de la boite. Car nous sommes dans le même bateau. Nous partageons la même vision et avons les mêmes objectifs (qui passent parfois par oui faire des efforts, des concessions pour faire réussir la boite). Adhérer au principe de cette journée et le percevoir comme je le perçoit est la garantie pour moi d’avoir humainement un candidat sur les mêmes valeurs que nous.
Enfin, cette journée chez nous doit être très largement inférieure en terme de temps consacré par le candidat aux multiples entretiens (je pense au 5-7 qui sont standards chez Google notamment) “classiques” et déplacements effectués chez d’autres. Je me souviens de mes 4 entretiens à la défense avec des managers tous plus hauts placés les uns que les autres, sur 4 jours différents, qui ont bien dû me prendre 4 x 2,5 heures. Alors oui, c’est plus diffus, plus “classique” et cela choque moins. Mais moi cela m’a choqué de l’aisance que ces gens avaient à me redemander sans cesse de venir me répéter. Je ne pense pas que mon modèle soit plus désavantageux pour mes candidats.
> Jamais rémunéré dites vous? En plus d’être carrément illégal [...]
Je ne suis pas avocat mais je pense que c’est “plus” illégal *si c’est rémunéré*, cf. article d’AF83 que j’ai posté plus haut. Ou alors il faudrait faire un CDD d’un jour, déclarer à l’URSSAF, etc.
> Enfin vous avouez vous même: “le travail effectué par le candidat est rarement repris tel quel (certaines fois jamais repris même).” C’est là que le bas blesse…. leur travail devrait être détruit systématiquement comme dans un coding dojo.
Ça par contre clairement. Ça évitera les accusations d’exploitation etc d’ailleurs : tout le monde (candidat et entreprise) “perdra du temps”. Mais en l’absence de contrat le code appartient au candidat et l’entreprise n’a certainement pas le droit de le réutiliser.
Bon ok, devant le tollé que provoque cette dernière phrase, j’ai dû l’éditer pour refléter au mieux le cas réel: sur 10-12 journées de tests, un seul travail a été repris (juste modifié avant d’être mergé dans master) et un autre repris par le candidat, 3 semaines plus tard une fois chez nous. Le reste a végété sur leurs branches respectives et parfois été une source d’inspiration pour le “vrai” développement.
Ok pour tous les autre arguments, bla bla, la lourdeur de l’Urssaf… soit.
Je trouve votre initiative interessante, et certainement plus enrichissante que comme vous le dite justement, les heures d’entretien passées pour ruen ( moi aussi j’y ai eu droit dans mes “jeunes” années).
Mes remarques étaient juste pour prouver aux autres que cette démarche pouvait être dénuée de toute ambiguité et de tout flou juridico-administrativo-financier.
“Un seul travail a été repris”… mais est ce que ce candidat a été retenu? Ce serait intéressant de savoir…
Même dans le cas où une seule ligne de code serait utilisée, je trouve cela extrêmement choquant. C’est de l’exploitation. Inutile de jouer sur les mots !!!
C’est la lutte, finaleuhh ! ;)
Pingback: Choisir le bon candidat : comment être sûr de son choix ?