Si j’ai bonne mémoire, j’ai dû recevoir mon premier candidat en entretien technique il y a une petite dizaine d’années. Depuis, l’exercice s’est répété régulièrement, s’accélérant même depuis deux ans, et sans prétention, je pense que avoir affiné mon approche.
Il me semble en effet que la démarche de nos entretiens techniques a gagné en structuration, en efficacité, à la fois pour le recruteur mais aussi pour le candidat.
Chaque postulant restant un cas particulier, il n’en reste pas moins une trame commune, que je partage avec vous ici:
Le test technique
En premier lieu, le tech manager fait parvenir en amont au candidat l’énoncé de notre test technique. Il s’agit d’un exercice qui nécessite de coder un petit projet à partir d’un énoncé très loin de nos problématiques métier du quotidien. Le candidat à environ 3h pour le réaliser avec l’environnement de dev avec lequel il ce sent le plus à l’aise.
Ce test repose sur un barème de notation qui comporte 38 critères de notation selon des règles plutôt simple: le point est acquis, ou partiellement acquis et en dernier recours, le point est non maitrisé.
Malgré cela, la notation peut être plutôt subjective et c’est pour cela que nous préférons avoir plusieurs développeurs qui évaluent séparément le test du candidat. L’utilisation du même barème de notation s’impose bien sûr, et permet la comparaison des compétences des candidats et même les situer vis-à-vis de celles des développeurs déjà intégrés dans l’entreprise.
Après ce test, nous planifions systématiquement un entretien technique entre le candidat et le/les développeurs ayant évalué le candidat.
L’entretien technique:
Que ce soit en IRL ou sur zoom, on commence toujours par indiquer comment va se dérouler l’entretien: “Tour de table rapide pour ce présenter, puis questions concernant le test et enfin les questions du candidat”.
En effet on a souvent des candidats qui peuvent se montrer stressés ou redouter ce type d’entretien, et pour calmer et détendre le plus rapidement le candidat on lui évite des surprises en lui indiquant explicitement le but de cette réunion et son plan.
On enchaine très vite sur un tour de table ou nous “employeurs” nous présentons brièvement avec un modèle similaire: “Nom, prénom, notre poste actuel et dans quelle équipe, depuis combien de temps. Notre situation familiale et nos hobbies”. Le tout avec le sourire, de l’humour et en toute décontraction pour rassurer le candidat. Le but étant que le candidat se présente sur le même ton, sans retracer tout son parcours professionnel non plus. Non pas que cela ne nous intéresse pas du tout, mais nous avons accès au CV et le but et de parler du test technique sans rentrer dans un canvas d’entretien professionnel formel qui passe par une retrospective des expériences passées du candidat.
Après la présentation, toujours dans le but de rassurer le candidat, je souligne que nous sommes alors uniquement entre développeurs et que nous n’occupons aucune fonction managériale. Que nous somme ici pour échanger sur la solution mise en oeuvre pour le test technique sans qu’aucun prétende détenir la vérité ou la solution parfaite. Il est rappelé aussi que la discussion reste ouverte, et qu’aucune réponse n’est considérée mauvaise.
Le but est d’inviter ici le candidat à livrer sans appréhension sa pensée sur ses choix techniques.
Et du coup on enchaine sur une série de question à destination du candidat:
Comment s’est passé ce test ? Qu’est-ce que tu en as pensé ?
Les réponses indiquent l’état d’esprit du candidat vis à vis du test. Certains confient n’avoir pas du tout apprécié de commencer l’exercice à partir d’une feuille blanche car il n’y sont pas habitués, d’autres au contraire ont trouvé l’exercice sympa. Mais tous évoquent leur ressenti vis à vis de leur prestation et souvent ils admettent être déçus de leur prestation, de pas avoir fini à temps, d’avoir voulu faire plus, craignent d’être passés à côté de l’énoncé, d’avoir manqué de temps, etc…
Grosso modo, quel temps as-tu consacré au test ?
Même si l’exercice est donné pour 3h, il faut s’assurer que le candidat n’a pas été contraint finalement de boucler l’exercice en moins de temps qu’annoncé et qu’il a pu se dégager assez de temps pour le faire.
Est-ce que tu étais en condition optimal d’après toi pour faire ce test?
Vendredi soir, après une semaine de boulot dans les pattes, avec la fatigue cumulée et à partir de 21h30 et avec des interruptions régulières parce que le petit dernier fait ses dents… on s’imagine bien que ce n’est pas optimale et que le candidat à pu passer à coté de certains points à cause de ces conditions. Ici on laisse la place au candidat de témoigner personnellement sur le comment il a réaliser son test technique.
Es-tu globalement satisfait de ce que tu as livré ? Qu’aurais-tu aimé faire autrement si tu avais eu plus de temps ? Quel point souhaiterais-tu retravailler si l’occasion t’en était donnée ?
Par expérience j’ai pu constater qu’il est rare que les candidats s’avouent satisfaits de leurs livrables. La plupart du temps ils soulignent un point qu’ils auraient aimé aborder autrement qu’ils l’ont fait, un autre qu’ils auraient préféré mener plus loin… Ces confidences ont un aspect pratique, elles vont me permettre d’identifier si il a également perçu les points qui lui ont fait défaut dans le barème de notation.
J’essaye alors d’orienter le candidat vers les concepts technique, DDD, Solid, CQRS, architecture hexagonal, l’idéal étant qu’il les aborde naturellement de lui même… et au bon moment. Pas la peine d’être un expert, parfois avoir déjà entendu parler du concept, en avoir compris les grandes lignes ET en avoir perçu le bénéfice est déjà un sérieux plus pour la candidature. Les hards skills s’apprennent… par contre on sait rapidement si le candidat est curieux, fait sa veille et remet en question ses pratiques. C’est aussi ici qu’on débusque les juniors avides de seulement pisser du code et les profils senior qui codent comme ils l’ont toujours fait. Au bout de 20 minutes on a généralement fait le tour de la partie technique et on peux inverser les questions, toujours dans une relation de dev à dev.
Les questions du candidat
C’est au candidat de poser ses questions et c’est là qu’il faut rester concentré et faire attention à ses réponses. Car ce sont vos réponses qui vont en grande partie motiver le candidat à quitter son poste actuel, peut être déménager, chambouler son emploi du temps et sa routine. Des décisions qu’il ne prendra que s’il se sent souhaité, attendu, en confiance et s’il entrevoit qu’un challenge ou défi l’attend. Ce qui signifie qu’il faut ne surtout pas sur-vendre le poste sinon c’est le meilleur moyen de le décevoir mais aussi la principale cause de départ des employés dans la tech.
Les deux questions qui reviennent le plus souvent sont:
Quel est votre stack technique ?
Je présente alors la stack technique avec la plus grande honnêteté en évoquant les versions des frameworks qu’on utilise même si ils ne sont plus vraiment à jour.
Je reste critique envers notre stack, si on utilise un truc à la mode mais qu’on souhaite virer parce qu’on s’y prend mal ou qu’on a plus les compétences, je n’hésite pas à le dire.
Idem si on a des outils vraiment “hype” mais que le candidat, si il venait a être recruté, ne manipulera pas. Ne pas vendre du rêve à tout prix en récitant une liste de buzzword.
J’évoque ensuite le reste de la stack technique: devops, data-engineering, data-science et cette fois cela me permet de voir quel est la culture tech de candidat et sa curiosité.
A quoi ressemble votre journée/semaine type?
Ce type de question qui n’est pas purement technique permet de déceler chez le candidat une curiosité naturelle sur les process de l’entreprise. Généralement cela traduit une expérience précédente ou les process n’étaient pas optimaux ou justement une organisation bien huilée. Cela me fait penser que le développeur ne considérera pas les rituels et réunion d’alignement comme du “bruit” mais comme partie intégrante de son travail. Du coup dans un souci de transparence, je partage directement mon écran pour montrer l’agenda de ma semaine en cours, expliquant vite fait ce qui est habituel ou pas en terme de réunion. Notre manière d’être agile est là sous ses yeux, on ne peux guère tricher avec nos rituels. Je l’avertis également que chaque équipe est autonome et libre de définir sa façon de faire de l’agilité.
Notre process de recrutement n’est pas parfait et cet entretien technique n’en est qu’une étape. J’ai eu l’occasion de recroiser un candidat lors d’un meetup quelques mois plus tard et même si nous n’avions pas donné suite à sa candidature, il m’a affirmé avoir particulièrement apprécié la clarté de notre process et le feedback clair et technique qui lui ont permis d’identifier des axes d’évolutions pour sa carrière. Enfin, formaliser cet interview était une action nécessaire pour plusieurs raisons dont la principale était d’établir une égalité entre les différents candidats en les évaluant de façon rigoureusement identique.
Convaincu ? Rejoignez-nous 😁
https://careers.instapro.group/
English version here | Follow me on twitter @scullwm
