Je vois que mes explications ton choqué (tu dis que je t'ai fait sauter au plafond) et je m'en excuse alors mais je pense que tu as mal perçu mon propos, sans doute un soucis de passer par l'écris, je pense pas que tu aurais eu ce genre de réaction avec moi à l'oral. Je sais pas comment te convaincre mais je m'estime plutôt bienveillant pendant mes entretiens, j'explique le processus de question/réponse (qui n'ai pas un script fixe écrit à l'avance d'ailleurs mais plutôt un échange avec le candidat par rapport à son expérience passé et ses envies futures), qu'il n'y pas de mauvaise réponse, que rien n'est éliminatoire etc... Et j'ai plutôt des bon retours sur les candidats que j'auditionne par rapport à ma bienveillance donc bref je suis pas la bête inhumaine de recruteur que tu as lu entre mes lignes.
J'ai vu des personnes ultra stressé qui trouver plus leur mot, et à ce moment tu prends le temps pour justement éviter un avis trop hâtifs, tu tente de le rassurer, tu pose des questions lié à l'expérience du candidat avant de retourner à des questions plus pointus etc...
Dans ton commentaire, y a plusieurs points sur lesquels j'aimerai rebondir:
Ta réponse de dire:
"Je connais pas les notions théoriques/le nommage précis derrière les design pattern mais je m'en fiche parce que c'est pas ce que je fais au quotidien, je lis beaucoup de code existant et je sais m'intégrer avec et ceci dans des projets open-source important" est pour moi une réponse VALIDE.
On aurait échangé la dessus et j'aurais certainement mis un avis positif à la sortie. Ici je résume ma vision d'un entretien technique, en réel je pose plus que 3 questions mais quelques soit la questions aucune réponse même "mauvaise" n'est éliminatoire, c'est sur l'ensemble que j'apporte un jugement.
Alors le fait de porter un jugement sur quelqu'un t'hérisse peut être le poil mais c'est le but même d'un entretien, émettre un avis sur quelqu'un pour savoir si il pourra répondre au besoin ou non et je vais te choquer mais c'est en plus complétement subjectif comme processus, tu évalue à la fois la technique mais aussi la capacité de la personne à discuter de sa technique, parce que aujourd'hui je recrute des personnes pour du travail en équipe. ça m'est arrivé de mettre un avis négatif à un profil ultra compétant mais totalement imbue de sa personne et je voulais pas prendre le risque d'avoir un TechLead compétant mais toxique pour l'équipe (c'est que les Rh appelle soft & hard skill).
Concernant libuv tu m'as mal compris, c'était juste un exemple, je demande pas la maitrise de libuv ou libev ou autres, je demande la maitrise/compréhension des concepts de la programmation orienté asynchrone (avec des callback quoi si le terme "programmation asynchrone est trop théorique pour toi).
Pourquoi je le demande, parce que c'est rarement un mode de programmation qui est appris en école (les écoles s'arrête généralement au multithread avec mutex). Donc si la personne connait la programmation asynchrone pour du C bas niveau, ça montre une personne curieuse, qui regarde ce qui se fait ailleurs, bref fait une veille techno ce qui est pour moi un critère très important. Encore une fois ici, c'est un plus, un bon indicateur mais c'est pas éliminatoire.
Et pour revenir au débat initiale, le "faire un test 4 à 6H pour évaluer ton niveau technique" à faire chez soi est pas forcément plus humain, ça peut être vu comme vexant pour des profils expérimenter de devoir passer par ce "devoir à la maison". Bref y a pas de solution parfaite mais je trouve la moins invasive (tout en restant efficace) pour un candidat, reste encore l'entretient technique avec questions-réponses, partage d'expérience et des ses envies futures.
[^] # Re: Chouette
Posté par Tangi Colin . En réponse au lien Avez vous déjà vu... ? (du recrutement, spécialement informatique). Évalué à 2.
Je vois que mes explications ton choqué (tu dis que je t'ai fait sauter au plafond) et je m'en excuse alors mais je pense que tu as mal perçu mon propos, sans doute un soucis de passer par l'écris, je pense pas que tu aurais eu ce genre de réaction avec moi à l'oral. Je sais pas comment te convaincre mais je m'estime plutôt bienveillant pendant mes entretiens, j'explique le processus de question/réponse (qui n'ai pas un script fixe écrit à l'avance d'ailleurs mais plutôt un échange avec le candidat par rapport à son expérience passé et ses envies futures), qu'il n'y pas de mauvaise réponse, que rien n'est éliminatoire etc... Et j'ai plutôt des bon retours sur les candidats que j'auditionne par rapport à ma bienveillance donc bref je suis pas la bête inhumaine de recruteur que tu as lu entre mes lignes.
J'ai vu des personnes ultra stressé qui trouver plus leur mot, et à ce moment tu prends le temps pour justement éviter un avis trop hâtifs, tu tente de le rassurer, tu pose des questions lié à l'expérience du candidat avant de retourner à des questions plus pointus etc...
Dans ton commentaire, y a plusieurs points sur lesquels j'aimerai rebondir:
Ta réponse de dire:
"Je connais pas les notions théoriques/le nommage précis derrière les design pattern mais je m'en fiche parce que c'est pas ce que je fais au quotidien, je lis beaucoup de code existant et je sais m'intégrer avec et ceci dans des projets open-source important" est pour moi une réponse VALIDE.
On aurait échangé la dessus et j'aurais certainement mis un avis positif à la sortie. Ici je résume ma vision d'un entretien technique, en réel je pose plus que 3 questions mais quelques soit la questions aucune réponse même "mauvaise" n'est éliminatoire, c'est sur l'ensemble que j'apporte un jugement.
Alors le fait de porter un jugement sur quelqu'un t'hérisse peut être le poil mais c'est le but même d'un entretien, émettre un avis sur quelqu'un pour savoir si il pourra répondre au besoin ou non et je vais te choquer mais c'est en plus complétement subjectif comme processus, tu évalue à la fois la technique mais aussi la capacité de la personne à discuter de sa technique, parce que aujourd'hui je recrute des personnes pour du travail en équipe. ça m'est arrivé de mettre un avis négatif à un profil ultra compétant mais totalement imbue de sa personne et je voulais pas prendre le risque d'avoir un TechLead compétant mais toxique pour l'équipe (c'est que les Rh appelle soft & hard skill).
Concernant libuv tu m'as mal compris, c'était juste un exemple, je demande pas la maitrise de libuv ou libev ou autres, je demande la maitrise/compréhension des concepts de la programmation orienté asynchrone (avec des callback quoi si le terme "programmation asynchrone est trop théorique pour toi).
Pourquoi je le demande, parce que c'est rarement un mode de programmation qui est appris en école (les écoles s'arrête généralement au multithread avec mutex). Donc si la personne connait la programmation asynchrone pour du C bas niveau, ça montre une personne curieuse, qui regarde ce qui se fait ailleurs, bref fait une veille techno ce qui est pour moi un critère très important. Encore une fois ici, c'est un plus, un bon indicateur mais c'est pas éliminatoire.
Et pour revenir au débat initiale, le "faire un test 4 à 6H pour évaluer ton niveau technique" à faire chez soi est pas forcément plus humain, ça peut être vu comme vexant pour des profils expérimenter de devoir passer par ce "devoir à la maison". Bref y a pas de solution parfaite mais je trouve la moins invasive (tout en restant efficace) pour un candidat, reste encore l'entretient technique avec questions-réponses, partage d'expérience et des ses envies futures.