Etude : les entretiens d'embauche en IT évaluent plus l'anxiété que les compétences en programmation

Les entretiens d'embauche dans le secteur des technologies évaluent l'anxiété et non les compétences en développement de logiciels
D’après une étude de l’université de Caroline du Nord et Microsoft

Les entrevues techniques – une forme d’entretien au cours de laquelle les candidats écrivent du code pour résoudre un problème – sont monnaie courante dans l’industrie du génie logiciel. Des entreprises bien connues comme Facebook, Google ou encore Microsoft s’appuient sur celles-ci pour le recrutement de leurs employés. Dans le processus classique, tout se passe pour le candidat sur un tableau blanc face auquel il propose une solution à haute voix, ce, sous l’œil attentif d’un membre de l’équipe de recrutement. Problème : bon nombre de candidats qui pourraient pourtant être qualifiés pour le poste se trouvent recalés parce que pas habitués à travailler dans de telles conditions.

C’est de façon ramassée ce que révèle une étude de chercheurs de l’université de Caroline du Nord et de Microsoft.

Pièce jointe 575080

Le fait avec le format classique de l’entrevue technique est, qu’au-delà de mesurer le temps mis pour proposer une solution à un problème donné et la justesse de la solution à ce dernier, il introduit une « menace socioévaluative » au travers de la présence d’un membre de l’équipe de recrutement. C’est pour cette raison que les chercheurs de l’université de Caroline du Nord et de Microsoft ont eu l’idée de soumettre les candidats à un format modifié dans lequel ils résolvaient en privé un problème technique sur un tableau blanc. Objectif : évaluer l’impact du stress généré par la présence d’un évaluateur sur les performances cognitives d’un candidat.

Les 48 participants à l’expérience ont subi un test similaire à ceux sur lesquels les recruteurs s’appuient dans le cadre de tests réels menés par des entreprises comme Amazon, Cisco, Google, Facebook, etc. C’est un classique (déterminer la plus longue sous-chaîne sans répétition des caractères) que l’on peut retrouver dans le livre intitulé éléments d’entrevues de programmation en Java – un recueil de problèmes en lien avec la manipulation des chaînes de caractères. Dans le cadre de l’expérience, les participants ont reçu un énoncé imprimé du problème à résoudre. Ce dernier comprenait également trois exemples qui indiquaient ce que serait le résultat escompté pour une entrée donnée. Par exemple, étant donnée l’entrée abcabcbb, la réponse est abc, avec la longueur 3. Les participants se sont ensuite vus demander de fournir une solution raisonnable dans un langage de programmation de leur choix, ce, avec la précision que leur processus de réflexion et la justesse de la solution étaient importants, tandis que l'efficacité et la syntaxe étaient secondaires.

22 ont participé à l’entrevue en privé et 26 à celle en présence d’un évaluateur. Grosso modo, il ressort des résultats obtenus dans chaque format d’évaluation que :

• 61,5 % des participants au format public ont failli à accomplir la tâche à eux proposée ; le même constat a été fait pour seulement 36,3 % des participants au format privé ;
• les participants au format public ont exhibé de l’incapacité à se concentrer, de la nervosité, du stress en raison de la présence d’un évaluateur dans la salle ; le constat inverse a pu être fait pour ceux participant au format d’évaluation privé ;
• les participants au format public ont obtenu de moins bons scores en comparaison de ceux obtenus par les participants au format privé ;

Pièce jointe 575083

• le stress et la charge cognitive étaient sensiblement plus élevés dans un entretien technique traditionnel que dans le cadre de l'entretien privé ;

Pièce jointe 575082

• la performance est réduite de plus de la moitié du fait de la présence d’un observateur.

C’est pour ce lot de raisons que les auteurs de l’étude soulignent que les entreprises passent à côté de très bons programmeurs simplement parce que ceux-ci ne sont pas doués pour écrire sur un tableau blanc et expliquer leur travail à haute voix. Ils appellent à la mise sur pied de formats d’évaluation des candidats plus équitables.

Les problèmes mis en avant par cette étude viennent allonger une liste déjà longue de mauvaises pratiques en matière de recrutement des travailleurs de la filière développement de logiciels : communication incorrecte des critères d’embauche, entretiens menés par des enquêteurs inexpérimentés, etc.

Après, l’une des limites de cette étude fait surface, semble-t-il, dans cet aspect mis en avant par les auteurs de l’étude : présence d’un enquêteur génératrice de stress qui impacte de façon négative sur les l’aptitude d’un postulant à exposer une solution à un problème en présence d’une audience. Dans l’exercice de son métier, le développeur est en principe appelé à faire valoir ses solutions sur un support comme celui mentionné (tableau blanc) en présence de pairs. On n’est certes plus dans un processus d’embauche, mais il s’agit de présences qui pourraient s’avérer tout aussi gênantes si l’on n’a pas appris à apprivoiser ce qui apparaît comme une aptitude clé.


Source : ncsu

Et vous ?

:fleche: Les entretiens d'embauche permettent-ils de trouver le bon développeur ?
:fleche: Êtes-vous en accord avec la conclusion principale de cette expérience (la présence d’un observateur provoque un stress chez le candidat qui est susceptible d’affecter négativement ses performances) ?
:fleche: Le processus d’évaluation intègre-t-il toujours le tableau blanc et un recruteur ? Comment s’est passé votre dernier entretien d’embauche ?
:fleche: Avez-vous à faire au tableau banc et à un observateur sur le côté lors d’un entretien ? Partagez vos anecdotes
:fleche: La capacité pour un développeur à faire valoir ses idées sur un tableau blanc en présence d’un évaluateur n’est-elle pas clé à la réussite dans cette filière ?

Voir aussi :

:fleche: Faut-il faire coder les candidats durant les entretiens d'embauche ? Certains « développeurs » ne peuvent pas développer
:fleche: Comment sortir gagnant d'un entretien d'embauche ? Les dix erreurs à éviter, selon Experteer
:fleche: Les entretiens d'embauche permettent-ils de trouver le bon développeur ?
:fleche: Emploi : vous pourriez être évalué par une IA lors de votre prochain entretien d'embauche chez Unilever, Golman Sachs, etc.

Bonjour,

C'est bien de voir cette étude, et on pourrait même espérer que cela fasse bouger un peu les choses. Mais beaucoup de gens ayant fait du recrutement savent déjà ce qui est dit ici -- mais le formaliser est toujours important.

Citation:

---

Envoyé par Patrick Ruiz

Après, l’une des limites de cette étude fait surface, semble-t-il, dans cet aspect mis en avant par les auteurs de l’étude : présence d’un enquêteur génératrice de stress qui impacte de façon négative sur les l’aptitude d’un postulant à exposer une solution à un problème en présence d’une audience. Dans l’exercice de son métier, le développeur est en principe appelé à faire valoir ses solutions sur un support comme celui mentionné (tableau blanc) en présence de pairs. On n’est certes plus dans un processus d’embauche, mais il s’agit de présences qui pourraient s’avérer tout aussi gênantes si l’on n’a pas appris à apprivoiser ce qui apparaît comme une aptitude clé.

---

Je ne suis pas d'accord avec cette partie :
Dans le cas de l'entretien, on te pose une question que tu dois résoudre devant un enquêteur.
Dans le cas de ton travail quotidien, tu résouds le problème puis tu présentes la solution devant des gens.

Le fait d'avoir fait le travail en amont, en non pas devant les gens, est une différence fondamentale.

Citation:

---

Envoyé par Patrick Ruiz

:fleche: Les entretiens d'embauche permettent-ils de trouver le bon développeur ?

---

C'est très difficile d'évaluer un bon développeur, mais je ne pense pas que faire passer un test technique dans un langage soit une bonne approche dans tous les cas. C'est parfait si on veut évaluer une personne dont le métier sera limité à faire du code, mais la plupart du temps on attend plus d'un recrutement, et donc il vaut mieux chercher à voir si la personne comprend les concepts qu'elle manipule plutôt que de savoir si elle est capable d'expliquer un quicksort.

Citation:

---

Envoyé par Patrick Ruiz

:fleche: Le processus d’évaluation intègre-t-il toujours le tableau blanc et un recruteur ? Comment s’est passé votre dernier entretien d’embauche ?

---

Trop souvent, l'entretien se limite à ce genre d'exercices, sur tableau ou sur papier. Mais quel intérêt aujourd'hui de priver un développeur d'un moteur de recherche ? Est-ce que tu veux embaucher quelqu'un qui connait le concept de tri, voir qui sait que dans certains cas il faut rendre aléatoire le contenu d'un tableau avant de le trier, ou bien est-ce que tu veux quelqu'un qui implémente un quicksort sans faute, mais qui ne comprend pas que dans certains cas ce tri n'est pas le meilleur ?

Citation:

---

Envoyé par Patrick Ruiz

:fleche: La capacité pour un développeur à faire valoir ses idées sur un tableau blanc en présence d’un évaluateur n’est-elle pas clé à la réussite dans cette filière ?

---

C'est un exercice qui évalue une chose, mais est-ce la seule que tu veux vérifier? Moi non.

Quand je suis entré en SSII, et quand j'en ai changé, on a uniquement évalué ma capacité à passer des entretiens (ce qui inclut évidemment une part de résistance au stress). Certaines le disaient même ouvertement.

Celà étant, la vie de programmeur a du stress aussi. Si on cherche quelqu'un capable de coder sous stress, alors ce moyen de test est assez intéressant, et bien plus réaliste que l'article ne le laisse supposer. D'un autre coté, si vos programmeurs codent tout le temps sous stress, vous avez peut-être un souci plus grave que le recrutement : vous ne mettes pas vos programmeurs dans de bonnes conditions pour être performants. J'ai envie de dire que le souci est plus à ce niveau. La plupart des recrutements, quel que soit le métier, de nos jours, ont pour critère prioritaire la résistance à la pression. En bref, les entreprises se vantent d'écraser les travailleurs sous la pression (ce qui ne les a jamais rendus plus productifs).

EDIT : j'avais raté le message de Gangsoleil, qui complète bien. Mais la plupart des gens qui recrutent ne comprennent même pas le métier réel d'un programmeur, et ne comprennent pas que notre métier va bien plus loin que des compétences techniques. Gangsoleil cherche des gens qui vont plus loin que ça, et il a bien raison. Mais il ne constitue pas, hélas, la règle. Plutôt l’exception. Sur un autre sujet, on a des annonces qui demandent 4 ans d'expérience dans une techno qui existe depuis 1 an - preuve que les recruteurs n'ont aucune idée de ce qu'ils cherchent.

Bonjour à tous et toutes,

Perso, face à ce genre d'entretien, je fais toujours une remarque du genre : "on est d'accord que mon métier, ce n'est pas de faire du code à la main sur un tableau blanc et en public ? Parce que là, c'est là dessus que vous allez me juger, visiblement...".

Généralement, ils prennent mal ce genre de remarque.

Cela dit, à mes yeux, le meilleur test reste encore un projet à faire à la maison (ou sur place, mais tranquille dans un coin) sur un sujet qui concerne directement le poste que tu vises.

Combien de fois j'ai postulé à des jobs orienté front pour avoir des tests reposant sur C# et SQL (???) et inversement.

En espérant que cette étude changera quelquechose mais j'y crois moyen.

Bonjour,

Citation:

---

Les entretiens d'embauche permettent-ils de trouver le bon développeur ?

---

Tout dépend de comment ils sont menés. Se limiter à faire entrer les gens dans case ... non . Par contre avoir des notions ou des connaissances métier / terrain peut aider. On peut être le meilleur des dev en PHP/C/VBA sans connaître les règles bancaires ... Résultat sortir des programmes difficillement utilisable , avec des résultats pas vraiment en phase avec les attentes.

Citation:

---

Êtes-vous en accord avec la conclusion principale de cette expérience (la présence d’un observateur provoque un stress chez le candidat qui est susceptible d’affecter négativement ses performances) ?

---

Tout a fait. Tout est fait pour voir si le candidat travaille vite ou non. On peut être excellent dev mais être incapable de travailler dans l'urgence ... Résultat en cas de pépin le client ou le presta va faire un caca nerveux ... on préférera prendre un dev qui code vite . Quitte a faire de la merde .

Citation:

---

Le processus d’évaluation intègre-t-il toujours le tableau blanc et un recruteur ?

---

Non

Citation:

---

Avez-vous à faire au tableau banc et à un observateur sur le côté lors d’un entretien ?

---

Non jamais eu affaire à cela.

Citation:

---

La capacité pour un développeur à faire valoir ses idées sur un tableau blanc en présence d’un évaluateur n’est-elle pas clé à la réussite dans cette filière ?

---

C'est bien la tout le problème. On peut avoir de très bonnes idées ... mais les process déjà existant et le degrés de "compréhension" de la logique/perception du dev est comment dire ... jugée trop exotique . Du coup on ne considère pas l'idée ...

Citation:

---

Envoyé par Arno_94

(.../...)Cela dit, à mes yeux, le meilleur test reste encore un projet à faire à la maison (ou sur place, mais tranquille dans un coin) sur un sujet qui concerne directement le poste que tu vises.(.../...)

---

Jeff Atwood avait une méthode encore plus violente : tu prends le candidat 2 semaines en consulting. Tu lui fais faire du vrai boulot, et tu vois si ça colle avec les autres gens. Pour faire mieux que ca comme mise en situation, il n'y a plus que le recours aux SSII sur des missions longues - avec pour réel objectif de jauger les gens, et de prendre les meilleurs.

Tout le reste, c'est forcément moins bien. Mais on essaye de croire que c'est bien quand même - parce-que ça coûte moins cher.

Un entretien d'embauche est presque tjrs stressant pour le candidat, avec ou sans tableau blanc.

Il est indispensable pour un développeur de bien savoir communiquer (avec le reste de l'équipe et son CP, à minima)
On doit tjrs rendre des comptes sur ce que l'on fait, à tous les postes.
Le développeur doit savoir expliquer sa conception et pourquoi il ne tient pas les délais, justifier un chiffrage, etc.
Le CP rend des compte au DP et au client
...
J'ai même pu constater des situations où la DG devait rendre des comptes, même si c'est plus rare (c'est le cas notamment lorsqu'il y a des actionnaires).

Je fais passer des entretiens et j'utilise le tableau blanc
Par contre, pour les postes de dev, je ne demande pas d'y écrire du code (du pseudo code, à la limite)
Je demande plus d'y écrire un workflow, ou un diag de relation et forcément en rapport avec le domaine métier dans lequel le poste est ouvert.
J'attends d'un entretien pour un dev que ce dernier sache mettre en évidence sa capacité à comprendre une problématique et ses enjeux et être en mesure de l'exprimer de manière claire et avec une proposition de correction / gestion de la situation.

L'idée n'est pas de mettre le candidat en situation de stress mais ce dernier doit savoir le gérer pour mettre ses compétences en avant (et ses capacités de raisonnement surtout)
Si un candidat perd ses moyens lors de l'entretien, tampis pour lui. (à lui de mener un travail sur lui-même)


Note :
Inversement, en tant que candidat, j'ai déjà postulé dans une boîte où les recruteurs sont arrivés en armés rangés à 4 en face de moi à me bombarder de questions de manière dure et anxiogène.
J'ai tenu bon mais je l'ai très mal vécu.
L'entreprise m'a appelé 4 jours plus tard (histoire de me mettre encore plus en stress en ne me faisant pas le feedback immédiatement) pour me dire que j'avais réussi mon entretien.
J'ai décliné l'offre car même si le poste m'intéressait beaucoup, il était hors de question que je travaille dans une boîte qui utilise des stratégies pour mettre sous pression ses collab pour mieux les manipuler derrière.
On a la chance d'être dans l'info où ce n'est pas le taff qui manque pour se permettre d'être sélectif sur l'entreprise où l'on signe.

Citation:

---

Envoyé par el_slapper

Jeff Atwood avait une méthode encore plus violente : tu prends le candidat 2 semaines en consulting. Tu lui fais faire du vrai boulot, et tu vois si ça colle avec les autres gens. Pour faire mieux que ca comme mise en situation, il n'y a plus que le recours aux SSII sur des missions longues - avec pour réel objectif de jauger les gens, et de prendre les meilleurs.

Tout le reste, c'est forcément moins bien. Mais on essaye de croire que c'est bien quand même - parce-que ça coûte moins cher.

---

ça s'appelle la période d'essai :aie:
Et comme tu le dis bien, ça a un coût non négligeable donc faut bien faire une sélection par entretien avant car on ne peut pas mettre 10dev en période d'essai alors qu'il n'y a qu'un seul poste d'ouvert

L'entretien devrait être un moyen de vérifier la compatibilité entre l'offre et la demande pour un poste et un candidat donnés. Cependant, certains recruteurs (subjectivement incompétents) le considèrent comme une opportunité d'évaluer intrinsèquement un candidat en tant que personne, en dehors du cadre du poste proposé. Ils ne se gênent pas d'inventer des situations ubuesques, de poser des questions déplacées, de demander à faire des pieds et des mains. Ils se placent au dessus des candidats, comme des assesseurs, professeurs, évaluateurs, maîtres, etc...
Je préfère rencontrer un candidat dans ses meilleurs jours et en pleine possession de ses moyens. Lui mettre la pression ou en situation de stress est totalement contre-productif, sauf cas vraiment spéciaux (force spéciale? enseignant au lycée? ...).

Citation:

---

Envoyé par Patrick Ruiz

C’est pour ce lot de raisons que les auteurs de l’étude soulignent que les entreprises passent à côté de très bons programmeurs simplement parce que ceux-ci ne sont pas doués pour écrire sur un tableau blanc et expliquer leur travail à haute voix. Ils appellent à la mise sur pied de formats d’évaluation des candidats plus équitables.

---

Je reconnais plein de défauts à mon école d'ingé, mais à ma quatrième année sur cinq (prépa intégrée) on avait beaucoup de présentation à l'oral, sur quasiment tout. Mon costard a été bien rentabilisé. Pour moi ce genre d'exercice est nécessaire, apprendre à présenter, ne pas perdre ses moyens. J'ai remarqué que les collègues qui brillent le plus combinent d'extrêmement bonnes compétences avec une grande capacité à présenter leur travail, la vulgariser, l'expliquer, et l'adapter selon la personne en face (soit de manière très détaillée face à un utilisateur à qui on veut une validation de règle de gestion, soit succinte et orientée objectifs / résultats quand il s'agit d'un manager qui veut savoir si on est à l'heure ou pas).

Comme le dit glutinus : savoir faire et faire savoir. Il faut les deux.

Le tableau blanc, on peut s'y entraîner quand on est en poste. Un collègue ou un manager vous demande des éclaircissements ? Levez-vous de votre bureau, allez au tableau blanc, et dessinez lui un mouton, pardon, une boîte, des boîtes, et des flèches. Et tout le monde comprend.Dans mon job actuel, j'ai fait un schéma au tableau qui explique comment fonctionne le module d'authentification de la plateforme de service dont j'ai la charge. Le schéma au tableau, je l'ai refait au propre en Visio. Il sert pour le chef de projet pour savoir de quoi on parle. Il sert au directeur de programme qui le présente au marketing, parce que ce module décide quel tarif est appliqué aux clients. Son impact est énorme, il est né sur un tableau blanc. Amis développeurs, apprenez le tableau blanc !

Ben faut dire qu'un tableau blanc en entretien, c'est quand même plus intéressant qu'un QCM ou un entretien bilatéral mais avec un seul sens...

Entre les QCM bourrés de fautes ou triviaux (déjà vu : "Question 12 : A quoi sert un objet Filtre" réponse "A filtrer". Véridique) et l'interview avec l'expert de la boite qui veut savoir quel case très précise on coche dans quelles conditions... Par contre si un jour je fais passer un entretien à un mec qui prétend être un peu expérimenté, je lui demande de faire des schémas au tableau.

Citation:

---

on a des annonces qui demandent 4 ans d'expérience dans une techno qui existe depuis 1 an

---

Elles doivent provenir de boîtes dans lesquelles il n'y a encore aucun développeur.
Si ? Alors c'est qu'ils n'ont pas leur mot à dire.

A fuir.

Bah, en entretien, une fois, de but en blanc, on me sort: quelle est la 14 ième option de la procédure mes c***** de SAS ?
Ben ,je sais pas tout par cœur, je regarde l'aide en ligne si j'ai un doute d'habitude..
Ah, ben vous n'êtes pas un expert, alors je ne vous propose qu'un 40 Ke...

C'est connu, tu dévalorises le candidat pour baisser ses exigences salariales :roll:

Désolé mais pour moi, cette étude ne révèle rien du tout,
si on enlève les femmes dans les statistiques, on a quasi le même taux de réussite pour les hommes, que ce soit en public ou en privé

car on a 100% de réussite pour les femmes en privé et 0% de réussite pour les femmes en public, ce qui fausse complément les stats

c'est à se demander comment l'étude a été faite et ce qui s'est passé en privé ...

Attention, alerte dérapage misogyne !!!! :mouarf:

Une population de 22 postulants dans un test et de 26 dans le contre-test, on peut vraiment en déduire quelque chose ? :koi: