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.
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é ;
- le stress et la charge cognitive étaient sensiblement plus élevés dans un entretien technique traditionnel que dans le cadre de l'entretien privé ;
- 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 ?
Les entretiens d'embauche permettent-ils de trouver le bon développeur ? Ê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) ? Le processus d’évaluation intègre-t-il toujours le tableau blanc et un recruteur ? Comment s’est passé votre dernier entretien d’embauche ? Avez-vous à faire au tableau banc et à un observateur sur le côté lors d’un entretien ? Partagez vos anecdotes 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 :
Faut-il faire coder les candidats durant les entretiens d'embauche ? Certains « développeurs » ne peuvent pas développer Comment sortir gagnant d'un entretien d'embauche ? Les dix erreurs à éviter, selon Experteer Les entretiens d'embauche permettent-ils de trouver le bon développeur ? Emploi : vous pourriez être évalué par une IA lors de votre prochain entretien d'embauche chez Unilever, Golman Sachs, etc. 
Envoyé par Patrick Ruiz
