Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    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.



    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.
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Modérateur

    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 Voir le message
    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 Voir le message

    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 Voir le message
    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 Voir le message
    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.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  3. #3
    Expert éminent sénior
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  4. #4
    Membre actif
    Mouais
    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.

  5. #5
    Membre émérite
    Bonjour,

    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.

    Ê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 .

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

    Avez-vous à faire au tableau banc et à un observateur sur le côté lors d’un entretien ?
    Non jamais eu affaire à cela.

    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 ...

  6. #6
    Expert éminent sénior
    Citation Envoyé par Arno_94 Voir le message
    (.../...)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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #7
    Expert éminent
    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.

  8. #8
    Expert éminent
    Citation Envoyé par el_slapper Voir le message
    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
    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

  9. #9
    Membre averti
    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? ...).

  10. #10
    Expert éminent sénior
    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).
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  11. #11
    Expert éminent sénior
    Comme le dit glutinus : savoir faire et faire savoir. Il faut les deux.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  12. #12
    Membre éprouvé
    Tableau blanc
    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 !

  13. #13
    Expert éminent sénior
    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.
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  14. #14
    Membre éclairé
    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.
    Sur Youtube je suis "Le développeur des cavernes"
    https://www.youtube.com/channel/UCSz...bYl_pSNMv_zerQ

  15. #15
    Membre extrêmement actif
    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

  16. #16
    Membre à l'essai
    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é ...

  17. #17
    Membre extrêmement actif
    Attention, alerte dérapage misogyne !!!!

  18. #18
    Membre éprouvé
    Taille de l'échantillon ...
    Une population de 22 postulants dans un test et de 26 dans le contre-test, on peut vraiment en déduire quelque chose ?

###raw>template_hook.ano_emploi###