Aborder le recrutement des ingénieurs comme un problème d'apprentissage automatique
par Jean Laban
16 octobre 2012 | 13 min de lecture
Il est difficile de recruter des ingénieurs en informatique. Nous le savons tous. Si l'on passe outre le problème de la recherche et de l'obtention de bons candidats (ce qui est déjà difficile en soi), la question de savoir si la personne à qui je parle est suffisamment compétente pour travailler ici est très difficile à résoudre. Encore une fois, nous le savons tous. Beaucoup d'encre a coulé, ou, je suppose, beaucoup de molécules de cristal liquide ont été déformées sur le sujet.
J'ai beaucoup réfléchi aux raisons pour lesquelles il est si difficile de recruter, et pour ce faire, j'ai commencé à y réfléchir en termes de problème d'apprentissage automatique. (Quelques informations sur moi-même : dans une vie antérieure, j'ai travaillé au service des fraudes d'Amazon.com et j'ai écrit des articles substantiels sur les systèmes complexes d'apprentissage automatique qu'ils utilisent pour sélectionner les commandes frauduleuses/mauvaises parmi les millions de commandes passées chaque jour. [1] . J'ai également interviewé quelques centaines de personnes au fil des ans, et je le fais toujours activement pour PagerDuty. )
Alors pourquoi considérer le recrutement comme un problème d'apprentissage automatique ? Eh bien, ce n'est pas que je veuille (nécessairement ?) commencer à utiliser des ordinateurs pour m'aider à résoudre ce problème difficile. C'est juste que le ML est une manière très formelle d'enseigner aux ordinateurs (qui sont des systèmes très formels) comment devenir bon dans quelque chose ; comment devenir un expert dans un domaine très étroit et ciblé. Comprendre pourquoi le recrutement serait un problème d'apprentissage automatique difficile m'aidera à comprendre pourquoi c'est un problème humain si difficile.
Alors commençons et plongeons-nous dans certaines bases de l’apprentissage automatique au fur et à mesure.
Définition du problème
Lors des entretiens d'embauche de candidats en ingénierie logicielle, nous essayons essentiellement de classer les candidats en deux catégories : les ingénieurs embauchables et les ingénieurs non embauchables. Les ingénieurs « embauchables » sont ceux qui, selon nous, ont les compétences, l'expérience et la personnalité nécessaires pour réussir dans un poste au sein de notre entreprise, et les ingénieurs « non embauchables » ne les ont pas.
Donc, c'est un problème de classification , et un avec seulement deux classes de sortie. Nous devons construire un modèle ou un classificateur – dans nos esprits, je suppose – qui prendra en compte une sorte d’entrée sur le candidat interviewé, croquera quelques chiffres et/ou réfléchira vraiment dur, et nous indiquerons si nous devons ou non embaucher cette personne. Je parlerai de ce classificateur un peu plus tard, mais parlons d'abord des entrées dont nous avons besoin.
Recueil des contributions
Une partie extrêmement importante (en fait la la plupart (Une partie importante) lors de la construction d'un classificateur avec l'apprentissage automatique est d'avoir de bonnes données avec lesquelles travailler et de pouvoir façonner ces données afin qu'elles puissent être utilisées comme entrées pour former efficacement et sans ambiguïté votre classificateur [2] . Nous rassemblons ces entrées (ou ensembles de ce que l'on appelle de manière déroutante « caractéristiques ' dans le monde du ML) à la fois pour former notre classificateur, puis à nouveau plus tard lors de l'évaluation d'un candidat en ingénierie logicielle que nous interviewons.
Quelques fonctionnalités
Alors, quelles sont ces « caractéristiques » que nous recueillons ? Pour le recrutement, il s’agit principalement des réponses aux questions d’entretien que nous posons au candidat. Selon la question, il peut s’agir de l’algorithme qu’il a défini, du code qu’il a écrit, du système qu’il a conçu ou de l’extrait de détails informatiques qu’il a sortis du plus profond de son esprit pour répondre à votre question. Ainsi, à la fin de quelques entretiens téléphoniques et peut-être de cinq entretiens en personne, nous parlons d’environ 20 à 50 questions (selon la granularité des questions posées au cours des entretiens individuels et ce que vous considérez comme une « question » d’entretien). Donc peut-être quelques dizaines de caractéristiques par candidat. Pas grand-chose à ajouter, en fait.
Ces questions d’entretien ont tendance à être réutilisées à de nombreuses reprises. C’est mauvais, à certains égards : elles peuvent devenir « obsolètes » au bout d’un certain temps, et au fil des ans, les chances augmentent qu’un candidat ait déjà été interrogé et ait répondu à cette question ou à une question similaire posée par quelqu’un d’autre. (Ou le sujet de la question lui-même peut même devenir moins pertinent au fil du temps !) Mais la réutilisation des questions est également importante : comment savoir à quel point une question est discriminante si vous ne l’avez pas utilisée contre un certain nombre de personnes différentes ? Comment savoir autrement si une mauvaise réponse à la question est un indicateur d’un « mauvais » ingénieur ? En tant qu’êtres humains, nous pouvons utiliser un certain degré d’intuition là où les machines ne le pourraient probablement pas, mais je ne saurais vous dire combien de fois j’ai entendu la phrase suivante lors d’un compte rendu après entretien : « Il n’a pas très bien réussi cette question, mais je ne l’ai jamais posée auparavant, donc je ne sais pas si c’est une question trop difficile/obscure. » [3]
Le modèle
Ok, nous savons maintenant quelles données collecter (nos fonctionnalités, ci-dessus) ; alors comment construisons-nous notre classificateur afin qu'il puisse prédire correctement qui nous devrions embaucher et qui nous ne devrions pas ?
Maintenant, lorsque l'on fait de l'apprentissage automatique, l'algorithme de classification utilisé est une partie assez importante et sacrément intéressante du processus. Mais l'algorithme est aussi la partie la plus connectée et dépendante du fait que le ML est, vous savez, effectué sur des ordinateurs. Pour les besoins de notre exercice de réflexion, nous n'avons que notre cerveau pour travailler pour construire ce modèle, alors ignorons simplement les subtilités des algorithmes de classification existants. Disons simplement que nous utilisons une sorte de Réseau neuronal pour construire notre modèle ici. Une fois construits, ils sont de toute façon aussi opaques qu'un esprit humain. 🙂
L'ensemble de formation
Alors, comment construisons-nous réellement ce classificateur mental ? Eh bien, nous l'entraînons à l'aide d'un Ensemble d'entraînement . Il s’agit essentiellement de la liste des personnes qui ont répondu à vos questions d’entretien dans le passé. Chaque personne interrogée compte comme une « observation » dans l’ensemble.
Pour les intervieweurs débutants, cet ensemble de formation peut être aussi petit qu'une seule personne : l'intervieweur lui-même. Ils diront mentalement : « Je peux répondre à ces questions, donc un bon candidat ingénieur devrait être capable de donner les mêmes réponses à ces questions. » Cela n'est pratiquement utile que pour embaucher des personnes qui vous ressemblent. (En termes de ML, vous êtes surapprentissage (votre modèle.) De plus, êtes-vous sûr que vous auriez pu répondre à cette question aussi bien que vous le pensez, si vous n'aviez pas formulé la question vous-même et n'y aviez pas réfléchi en détail au préalable ?
Malheureusement, même pour les enquêteurs expérimentés, l'ensemble d'apprentissage est encore très restreint. De l'ordre de quelques centaines d'échantillons, au mieux. Et, comme nous le verrons plus loin, il peut y avoir beaucoup de bruit dans ces échantillons.
Étiquetage de l'ensemble d'entraînement
Pour chaque échantillon de notre ensemble de formation (c'est-à-dire l'historique des entretiens d'un intervieweur donné), nous devons les étiqueter comme « aurait été une bonne embauche » ou « aurait été une bonne embauche ». pas « J’ai été un bon recrutement ». C’est très difficile. Plus précisément, il y a BEAUCOUP d’erreurs dans nos données mentales ici.
Comment créons-nous nos étiquettes ? Eh bien, nous commençons par la prédiction initiale que notre classificateur a émise à ce moment-là, c'est-à-dire si nous avons décidé ou non d'embaucher la personne. Et puis, nous devons ajuster rétroactivement ces étiquettes en établissant une boucle de rétroaction qui aide notre modèle à apprendre de ses erreurs passées. C'est-à-dire que nous devons corriger toutes les erreurs qu'il a commises dans le passé. Nous devons déterminer quelles décisions ont été prises. faux positifs , et qui étaient faux négatifs . Comment fait-on cela?
Faux négatifs
Les faux négatifs sont les personnes à qui nous avons dit « non » à l’embauche, mais qui auraient néanmoins fait un bon employé. Après avoir refusé une offre d’emploi, il est pratiquement impossible de savoir si cette personne aurait été un bon employé dans votre entreprise. Vous avez très peu de contacts futurs avec ces personnes et n’interagissez pas avec elles comme vous le feriez avec un collègue. Il est donc très difficile de réintroduire de fausses informations négatives dans votre modèle mental afin d’ajuster vos étiquettes.
La meilleure façon d'y parvenir, et de nombreuses bonnes entreprises le font, est de toujours permettre aux personnes que vous refusez de réintégrer le processus d'entretien dans un avenir pas trop lointain. Disons, dans 6 mois. Nous faisons cela chez PagerDuty, et sur nos quelque 11 ingénieurs, 2 ont en fait été refusés la première fois qu'ils ont été interviewés !
Il ne s’agit là que d’un mince filet de fausses réactions négatives, et il faut un certain temps avant de pouvoir les recueillir.
Faux positifs
Les faux positifs sont le type d'erreur inverse : des personnes que nous avons accepté d'embaucher, mais que nous n'aurions pas dû. À moins d'avoir beaucoup de chance, vous avez déjà rencontré ce genre de personnes dans votre travail.
Il existe deux catégories de faux positifs : ceux qui ont fini par accepter l'offre d'emploi et ceux qui ne l'ont pas fait. Pour ceux qui ont accepté l'offre d'emploi, il est très facile de réintégrer cette information dans votre modèle d'embauche mental, à mesure que vous travaillez avec ces personnes (et que vous les licenciez éventuellement). n'a pas acceptez l'offre, mais vous êtes confronté à un problème similaire à celui des faux négatifs : vous ne savez pas vraiment s'il s'agissait d'une mauvaise décision d'embauche ou non.
Frais
Lorsque vous définissez vos étiquettes « embaucher » ou « ne pas embaucher » sur votre ensemble de formation, il est recommandé de prendre en compte les frais de prendre une mauvaise décision.
Les coûts d'un faux positif sont assez élevés : embaucher quelqu'un qui ne convient pas à votre entreprise peut avoir un impact important sur la qualité de votre produit, sur la productivité des autres membres de l'équipe, sur le calendrier des projets, sur le moral, etc. Cela peut être assez désastreux dans certains cas.
Les coûts d'un faux négatif sont principalement des coûts d'opportunité : nous avons raté l'embauche de cet excellent ingénieur. Il est vraiment difficile de dire quelles seraient les conséquences de ne pas avoir pu recruter ce candidat : cela nous retarderait-il simplement de quelques semaines pendant que nous recherchons un autre bon candidat, ou avons-nous simplement raté notre opportunité ? Paul Buchheit ?
Quelle que soit l’ampleur des coûts des faux négatifs, ils sont certainement moins visibles que ceux des faux positifs. Il est beaucoup plus facile de quantifier les coûts des faux positifs et les écarts de valeur sont bien moindres. Les recruteurs ont donc presque tous tendance à faire preuve de prudence et à privilégier les faux négatifs aux faux positifs. Nous espérons également que le fait de permettre aux candidats de revenir ultérieurement au processus d’entretien contribuera également à atténuer ce problème.
L'ensemble de test
Enfin, il y a notre Ensemble de test . Dans l'apprentissage automatique, un ensemble de test est un ensemble de données distinct (composé à la fois de caractéristiques et d'étiquettes correspondantes) qui est complètement indépendant de l'ensemble d'entraînement. Il est utilisé après la création du classificateur (à l'aide de cet ensemble d'entraînement) pour déterminer si le modèle construit est « suffisamment bon » pour être réellement utilisé. L'utilisation d'un tel ensemble nous évite de sur-adapter notre modèle pour qu'il corresponde trop étroitement à nos données d'entraînement.
En pratique, un scientifique en apprentissage automatique digne de ce nom construirait en fait plusieurs classificateurs et utiliserait celui qui fonctionne le mieux par rapport à l'ensemble de tests. Il utiliserait même un troisième ensemble (un validation (set) pour s'assurer qu'après les itérations répétées de création + test + raffinement des modèles, elle n'a pas réellement surajusté son modèle par rapport à l'ensemble de test également !
Lors de la création de notre modèle mental de ce qui fait un ingénieur embauchable, un ensemble de tests est un autre luxe que nous n'avons pas, et nous nous retrouvons avec surapprentissage En général, à mesure que nous faisons plus d’observations (réalisons plus d’entretiens), nous avons tendance à regrouper ces observations dans l’ensemble d’entraînement.
La science inconfortable
Donc, pour revenir à ma question initiale : pourquoi est-il si difficile de recruter ? Eh bien, pour résumer : nous collectons un petit ensemble de caractéristiques, sur un nombre tout aussi petit d'observations dans notre ensemble d'entraînement, étiquetons nos observations de manière assez imprécise en raison de la difficulté à signaler les faux positifs et les faux négatifs, utilisons tout cela pour construire un modèle de classification opaque, sur-adaptons-nous comme des fous en raison de l'absence d'un ensemble de tests, et au final, nous avons plutôt tendance à ne pas embaucher le candidat en raison des coûts élevés des faux positifs.
Ça a l’air plutôt sombre, n’est-ce pas ?
Alors, comment pouvons-nous faire un travail de recrutement à peu près correct ? Eh bien, nous avons au moins une chose qui joue en notre faveur : nous utilisons une forme de apprentissage d'ensemble pour prendre notre décision finale. Avec l'apprentissage d'ensemble, vous prenez un certain nombre de classificateurs distincts et les utilisez ensemble pour faire de meilleures prévisions que vous ne l'auriez fait avec n'importe quel classificateur individuel. Nous le faisons lors de nos réunions de débriefing une fois la boucle d'entretien terminée : les intervieweurs s'assoient ensemble, passent en revue toutes les questions et réponses, et chacun prend une décision individuelle sur l'embauche ou non de ce candidat. Ensuite, nous prenons la décision finale d'embaucher ou non sur la base d'une sorte d'agrégation de tous les votes.
[1] Les « commandes frauduleuses » sont celles passées par des criminels qui ont volé la carte de crédit d'une autre personne, ont réussi à hameçonner le compte d'une autre personne ou tentent, d'une manière ou d'une autre, de voler indirectement de l'argent à Amazon. En outre, dans certains pays, Amazon autorise les paiements par des méthodes de paiement non garanties. Cela signifie qu'Amazon n'a aucune garantie d'être payée après avoir expédié des marchandises commandées par une personne généralement non criminelle, mais fauchée. Dans certains cas, Amazon doit donc également créer des modèles d'apprentissage automatique pour déterminer également la solvabilité générale de ses clients.
[2] Pour de nombreux problèmes de ML, il peut également être nécessaire de faire appel à un expert du domaine pour vous aider à trouver des données pertinentes et prédictives. Malheureusement, lorsque nous décidons d'embaucher ou non quelqu'un, nous n'avons généralement que nous-mêmes En tant qu’experts. De plus, au moins un de ces « experts en ingénierie logicielle » dans une boucle de recrutement est souvent très novice en matière d’entretiens d’embauche, et parfois même assez novice en ingénierie logicielle ! Mais ils doivent aiguiser cette compétence de recrutement quelque part…
[3] En passant, c'est une autre raison pour laquelle les « portfolios de programmation » ont tendance à être intéressants mais ne peuvent pas vraiment remplacer un entretien. Ils peuvent vous en apprendre beaucoup sur le style de programmation d'une personne, etc., mais en raison de la nature non structurée, par exemple, du dépôt Github personnel d'une personne, vous ne pouvez pas dire (A) comment elle résout les problèmes qui lui sont présentés par d'autres, ou (B) à quel point elle est productive/rapide, ou (C) s'il y a d'horribles erreurs de logique dans le code sans passer un temps sérieux à l'approfondir, à comprendre le problème qu'il essaie de résoudre, etc. Et même si vous pouviez le dire en jetant un œil à leurs escapades de programmation passées, vous auriez souvent du mal à intégrer ces entrées dans votre classificateur mental d'une « bonne embauche », car ces caractéristiques sont celles que vous avez créées uniquement pour ce candidat et aucune autre.
