Agilement recruté en 100 minutes

715 vues

Publié le

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.

Publié dans : Ingénierie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
715
Sur SlideShare
0
Issues des intégrations
0
Intégrations
10
Actions
Partages
0
Téléchargements
3
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Agilement recruté en 100 minutes

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

×