Faut-il faire coder les candidats durant les entretiens d'embauche ?
Non. Je pense qu'après avoir eu le blablabla de la RH sur l'entreprise pendant 15 minutes, avoir raconté sa vie pour montrer qu'il saura s'intégrer dans une team et résisté à des questions de "mise en pression cass-pied" pour voir comment réagit le candidat à des provocations, le faire jouer avec du code C sur un tableau blanc et plein de pointeurs supervisé par 1-2 développeurs qui le font tous les jours c'est un peu jouer au lotto pour avoir 5% de chance de recruter le bon candidat.
Quelle est selon-vous la meilleure méthode pour ne pas rater le recrutement d'un développeur ?
1/ Ne pas faire aveuglément confiance au candidat. Si il a pas mal d'expérience, il est malgré tout devenu habituel de "bullshiter" dans les CV. En Suisse, profiter des 3 mois d'essais pour lui infliger les plus grosses épreuves qu'il pourrait avoir à affronter, surtout si la place que le candidat vise est du genre "Scrum Master" / "Senior Architect"... il y a surement de belles grosses "story" trainant en backlog qui pourraient passer en en implémentation, ça aurait de quoi montrer que le sujet sait y faire face
2/ Si la roadmap est déjà planifiée sur du long terme, la meilleure façon de s'assurer des capacités du canditat sont à mon avis:
a/ De lui demander des exemples de projets comparable à ce qu'il devra faire
b/ Lui donner un projet à réaliser dans un temps imparti, par exemple 1 à 2 semaines sur son temps libre suivant sa condition et qu'il devra présenter / défendre durant l'entretient. Je trouve ça plus utile que de lui faire pondre 30 lignes de code après 40 minutes d'entretient avec la RH
Et vu que (d'après les offres d'emploi actuel), tout le monde veut quelqu'un avec 5 ans d'expérience dans le domaine, connaissance de .Net avec 5 ans d'exp, maitrise de l'anglais du français et de l'allemand, certif SQL,...: candidat introuvable pour le salaire de misère que certains proposent, ça prouvera qu'il saura s'adapter pour se débrouiller dans son job.
Partager