Agilement Recruté en 100 minutes

Les modèles d’entretien techniques surtout les modèles traditionnels ont beaucoup de points communs avec le modèle du cycle en V ou les projets waterfall.
Cette ressemblance concerne notamment les deux points suivants : - le récit des expériences professionnelles du candidat
- les tests techniques sous forme de QCM
Le problème avec ces deux points est le manque d’un feedback rapide pour le recruteur qui ne l’aide pas à optimiser son entretien qui est déjà d’une durée limitée.
Afin de maîtriser notre process de recrutement et garantir une méthode d’évaluation homogène et partagée, nous nous sommes inspirés des méthodes agiles pour définir notre propre modèle de recrutement et d’animation des entretiens techniques.
Notre objectif est de satisfaire les besoins des différents acteurs impliqués dans ce process, à savoir : le candidat, le(s) recruteur(s) et le(s) décideur(s).
L’entretien dans notre modèle est constitué de plusieurs itérations assez courtes ayant comme objectif de donner un feedback rapide au recruteur à la fin de chaque itération. A l’issu de l’entretien, notre modèle permet au recruteur d’identifier un profil bien précis du candidat synthétisant ses points forts, ses points faibles ainsi qu’un plan pour conquérir ces derniers.
Cette synthèse est partagée avec le candidat lors d’une rétrospective puis communiqué au(x) décideur(s) . Cette session est un retour d’expérience sur une centaine d’entretiens techniques animées sur quatre ans. Nous détaillons les différentes parties de l’entretien, la méthode d’évaluation suivie, les contrôles permettant de détecter les points à améliorer dans notre modèle, la qualité des candidats reçus (taux de réussite, etc.), ainsi que le suivi des candidats qui nous ont rejoint (intégration, évolution, etc.) Cette session s'adresse à tous les développeurs même ceux qui n'animent pas des entretiens techniques mais aussi toutes les personnes qui sont intéressées par les questions de recrutement.

Transcript

1. @houssamfakih Agilement Recruté en 100 minutes Room BS31 -10h30
2. Le Recrutement Choix Stratégique
3. Les candidats
4. Meilleure sonde sur le marché
5. Avec les recru(es) on construit le futur
6. Plusieurs étapes dans le process du recrutement
7. Ce qui nous intéresse
8. Les entretiens techniques
9. Acteurs Impliqués
10. Les RH
11. Les évaluateurs
12. Les décideurs
13. Let’s focus on Evaluateurs
14. Comment Evaluer ?
15. Pourquoi je recrute ? Mon objectif
16. Etre sûr et conscient de mes objectifs de ce recrutement
17. s’assurer que le/la candidat/e peut m’aider pour les concrétiser
18. Ses objectifs à court, moyen et long terme
19. Puis-je l’accompagner pour les atteindre ?
20. Quel/le développeur/se chechons-nous
21. Un/e développeur/se du clean code
22. Un/e développeur/se du beau code
23. lisible
24. maintenable
25. évolutif
26. propose des solutions simples
27. pour des problèmes complexes
28. Il/Elle a des qualités humaines
29. sans trop de défauts
30. pas les défauts de type ”perfectionniste”
31. aucun(e) recru(e) n’est pas parfait(e)
32. Les points faibles ne devraient plus être un tabou
33. Il faut en parler et les conquérir
34. Un entretien technique n’est pas fait pour piéger le/la candidat/e
35. l’objectif est de faire un bilan de compétences
36. C’est plutôt une séance de coaching
37. de plusieurs itérations
38. Où le/la candidat/e devrait un peu transpirer
39. Mais pour la bonne cause
40. Pendant l’entretien, chercher le feedback
41. le plus rapidement possible
42. Inutile de passer les 10 premières minutes à faire connaissance
43. Nous avons déjà lu le CV
44. l’équipe Recrutement nous a déjà fait son feedback
45. Mais il faut montrer au/à la candidat/e que vous le/la connaissez déjà
46. Les premières minutes écouter le/la candidat/e
47. comprendre ses aspirations
48. Et pourquoi il/elle est là?
49. Ensuite lui annoncer le programme
50. Préciser les règles : pas de piège, pas de contrôle mais plutôt un bilan
51. Et pour faire le bilan de son profil dev
52. il n’y a pas mieux de coder avec lui/elle
53. Mais attention
54. Montrer son code reste un tabou
55. rassurer le/la candidat/e
56. Passer par une période d’échauffement
57. Quitte à Prendre le clavier au début
58. #checkin
59. Le choix de l’exercice doit être simple
60. Mais riche en problématique
61. L’exercice doit se faire aussi en itérations
62. Première itération obligatoire de 5 minutes
63. temps libre pour le/la candidat/e
64. pour réfléchir à sa solution
65. La présenter
66. puis de petites itérations pour voir le code
67. Adapter la difficulté suivant le profil
68. Mais attention
69. Il faut aller progressivement
70. Les étapes doivent être incrémentales
71. Il ne faut jamais atteindre le point de rupture
72. Le but n’est pas de casser le/la candidat/e
73. S’assurer que les bases sont maîtrisées
74. Augmenter la difficulté
75. Valider le niveau
76. Recommencer
77. S’arrêter avant l’échec
78. Quels sont les points à surveiller ?
79. Sa solution Simple ?
80. Son code Clean ?
81. Sa technique efficace ?
82. Ses outils Est-ce qu’il/elle les maîtrise ?
83. Les défauts de son code Est-ce qu’il/elle les voit ?
84. Les défauts de son code Est-ce qu’il/elle les corrige ?
85. Il faut timeboxer le kata pas plus d’une heure
86. A partir de ce Kata on apprend plein de choses sur le/la candidat/e
87. Ce qui nous fait gagner du temps
88. A savoir qu’en cas de stress, on voit tous les défauts / points faibles
89. Faire un bilan de l’exercice technique
90. Communiquer au candidat un retour sur son travail
91. dresser avec lui/elle un bilan
92. lui donner des conseils sur les choses à améliorer
93. sur les bonnes choses qu’il/elle doit garder
94. N’oubliez pas de toujours terminer sur une victoire
95. Mais la technique n’est pas tout
96. Discuter de l’Agilité
97. Comment il/elle comprend l’agilité ?
98. Discuter de la Veille
99. Est-ce qu’il/elle est à jour ?
100. Est-ce qu’il/elle connaît l’état de l’art ?
101. A la fin de l’entretien
102. Faites le bilan avec le/la candidat/e
103. Donner votre feedback
104. Demander le sien
105. Après l’entretien
106. Pensez à votre fiche d’évaluation
107. Qui va la lire ?
108. Quelle valeur va-t-elle apporter ?
109. Pour qui ?
110. La cellule de recrutement
111. Ils ont sélectionné le/la candidat/e
112. Ce qui les intéresse Est-ce qu’on a fait la bonne sélection ?
113. Quelle information à retenir ? #Négative
114. Les décideurs #Propale
115. Actions RH à prévoir #Positive
116. Formations ou Mises à niveau
117. Un retour objectif basé sur des faits
118. prendre le temps de travailler sur le barème d’évaluation
119. Partager ce barème avec les autres évaluateurs
120. Garantir une vision homogène
121. Mêmes standards pour les évaluations
122. Passer les entretiens en binôme
123. En pair on profite de toutes les qualités de cette technique utilisée en dev
124. Suivi après recrutement
125. #joinUS #Looking_For_CleanCode_Developers @houssamfakih