- PagerDuty /
- Der Blog /
- Alarmierung /
- Die Einstellung von Ingenieuren als ein Problem des maschinellen Lernens betrachten
Der Blog
Die Einstellung von Ingenieuren als ein Problem des maschinellen Lernens betrachten
von Johannes Laban
16. Oktober 2012 | 13 Minuten Lesezeit
Softwareentwickler einzustellen ist schwierig. Das wissen wir alle. Wenn man das Problem der Suche und Anwerbung guter Kandidaten hinter sich lässt (was an sich schon schwierig ist), ist die ganze Frage „Ist die Person, mit der ich spreche, ‚gut genug‘, um tatsächlich hier zu arbeiten?“ eine sehr harte Nuss. Auch das wissen wir alle. Zu diesem Thema ist schon viel Tinte vergossen worden, oder, wie ich annehme, viele Flüssigkristallmoleküle verdreht worden.
Ich habe viel darüber nachgedacht, warum die Einstellung von Personal so schwierig ist, und habe angefangen, es im Kontext eines maschinellen Lernproblems zu betrachten. (Einige Hintergrundinformationen zu mir: In einem früheren Leben habe ich in der Betrugsabteilung von Amazon.com gearbeitet und einige wesentliche Teile der komplexen maschinellen Lernsysteme geschrieben, die sie verwenden, um die betrügerischen/schlechten Bestellungen aus den Millionen von Bestellungen herauszufiltern, die täglich eingehen. [1] Ich habe im Laufe der Jahre auch etwa ein paar hundert Leute interviewt, und tue dies immer noch aktiv für PagerDuty. )
Warum also Personalbeschaffung als ein Problem des maschinellen Lernens betrachten? Nun, es ist nicht so, dass ich (unbedingt?) Computer verwenden möchte, um dieses schwierige Problem für mich zu lösen. Es ist nur so, dass ML eine sehr formale Methode ist, Computern (die sehr formale Systeme sind) beizubringen, wie man in etwas gut wird; wie man ein Experte in einem sehr engen und fokussierten Bereich wird. Wenn ich herausfinde, warum Personalbeschaffung ein schwieriges Problem des maschinellen Lernens ist, kann ich auch herausfinden, warum es ein so schwieriges menschliches Problem ist.
Lassen Sie uns also beginnen und dabei in einige Grundlagen des maschinellen Lernens eintauchen.
Definition des Problems
Wenn wir Vorstellungsgespräche mit Softwareentwicklern führen, versuchen wir grundsätzlich, die Bewerber in zwei Kategorien einzuteilen: anstellbare und nicht anstellbare Ingenieure. „Anstellbare“ Ingenieure sind diejenigen, von denen wir glauben, dass sie die erforderlichen Fähigkeiten, Erfahrungen und Persönlichkeiten haben, um in unserem Unternehmen gute Arbeit zu leisten, und „nicht anstellbare“ Ingenieure sind unserer Meinung nach nicht anstellbar.
Das ist also ein Klassifizierungsproblem , und eines mit nur zwei Ausgabeklassen. Wir müssen ein Modell oder einen Klassifikator bauen – in unseren Gedanken, nehme ich an –, der eine Art Eingabe über den zu interviewenden Kandidaten aufnimmt, einige Zahlen verarbeitet und/oder denkt Wirklich schwer und gibt aus, ob wir diese Person einstellen sollten oder nicht. Ich werde später auf diesen Klassifikator eingehen, aber zuerst wollen wir über die Eingaben sprechen, die wir benötigen.
Eingaben sammeln
Ein äußerst wichtiger Teil (eigentlich der am meisten Der wichtigste Teil) beim Erstellen eines Klassifikators mit maschinellem Lernen besteht darin, gute Daten zum Arbeiten zu haben und diese Daten so zu gestalten, dass sie als Eingaben verwendet werden können, um Ihren Klassifikator effizient und eindeutig zu trainieren. [2] . Wir sammeln diese Eingaben (oder Sätze von dem, was verwirrenderweise als „ Merkmale ” in der ML-Welt), sowohl für das Trainieren unseres Klassifikators als auch später bei der tatsächlichen Bewertung eines Softwareentwicklungskandidaten, den wir interviewen.
Eine Auswahl an Funktionen
Was sind also diese „Merkmale“, die wir sammeln? Für die Einstellung sind das meist nur die Antworten auf die Interviewfragen, die wir dem Kandidaten stellen. Je nach Frage kann das der Algorithmus sein, den sie definiert haben, oder der Code, den sie geschrieben haben, oder das System, das sie entworfen haben, oder das Stück Informatik-Kleinigkeiten, das sie aus den Tiefen ihres Verstandes hervorgekramt haben, um Ihre Frage zu beantworten. Am Ende einiger Telefoninterviews und vielleicht 5 persönlicher Interviews sprechen wir also von etwa 20-50 Fragen oder so (je nachdem, wie detailliert die Befragung während der einzelnen Interviews wird und was Sie als Interview-„Frage“ zählen). Also vielleicht ein paar Dutzend Merkmale pro Kandidat. Nicht wirklich viel, um damit weiterzumachen.
Diese Interviewfragen werden häufig wiederverwendet. Das ist in gewisser Weise schlecht: Sie können nach einer Weile „abgestanden“ werden, und im Laufe der Jahre steigt die Wahrscheinlichkeit, dass ein Kandidat diese oder eine ähnliche Frage bereits von jemand anderem gestellt bekommen hat und beantwortet hat. (Oder das Thema der Frage selbst könnte mit der Zeit sogar weniger relevant werden!) Aber auch die Wiederverwendung von Fragen ist wichtig: Woher wissen Sie, wie diskriminierend eine Frage ist, wenn Sie sie nicht bei einer Reihe verschiedener Personen verwendet haben? Woher wissen Sie sonst, ob eine falsche Antwort auf die Frage auf einen „schlechten“ Ingenieur hindeutet oder nicht? Als Menschen können wir hier ein gewisses Maß an Intuition einsetzen, wozu Maschinen wahrscheinlich nicht in der Lage wären, aber ich könnte Ihnen nicht sagen, wie oft ich Folgendes in einer Nachbesprechung nach einem Interview gehört habe: „Er hat bei dieser Frage nicht sehr gut abgeschnitten, aber ich habe sie noch nie zuvor gestellt, also bin ich mir nicht sicher, ob es eine zu schwierige/undurchsichtige Frage ist.“ [3]
Das Model
Ok, wir wissen jetzt, welche Daten wir erfassen müssen (unsere Funktionen, siehe oben). Wie bauen wir also unseren Klassifikator auf, damit er richtig vorhersagen kann, wen wir einstellen sollten und wen nicht?
Wenn wir nun tatsächlich maschinelles Lernen durchführen, ist der verwendete Klassifizierungsalgorithmus ein ziemlich wichtiger und verdammt interessanter Teil des Prozesses. Aber der Algorithmus ist auch der Teil, der am meisten damit verbunden ist und davon abhängt, dass ML, wie Sie wissen, auf Computern durchgeführt wird. Für die Zwecke unserer Gedankenübung haben wir nur unser Gehirn, mit dem wir arbeiten können, um dieses Modell zu erstellen. Lassen wir also einfach die Feinheiten der Klassifizierungsalgorithmen da draußen außer Acht. Nehmen wir einfach an, wir verwenden eine Art Neurales Netzwerk um unser Modell hier zu bauen. Nachdem sie gebaut sind, sind sie sowieso ungefähr so undurchsichtig wie der menschliche Geist. 🙂
Das Trainingsset
Wie bauen wir also diesen mentalen Klassifikator? Nun, wir trainieren ihn mit einem Trainingsset . Diese Liste besteht im Wesentlichen aus der Liste der Personen, die Ihre Interviewfragen in der Vergangenheit beantwortet haben. Jede interviewte Person zählt als eine „Beobachtung“ im Set.
Für Interviewanfänger kann dieser Trainingssatz aus nur einer Person bestehen: dem Interviewer selbst. Sie werden sich im Geiste sagen: „Ich kann diese Fragen beantworten, also sollte ein guter Ingenieurkandidat in der Lage sein, dieselben Antworten auf diese Fragen zu geben.“ Das ist eigentlich nur dann sinnvoll, wenn Sie Leute einstellen, die mit Ihnen identisch sind. (In ML-Begriffen sind Sie Überanpassung Ihr Modell.) Und sind Sie sicher, dass Sie diese Frage so gut hätten beantworten können, wie Sie meinen, wenn Sie sich die Frage nicht selbst ausgedacht und sie vorher im Detail durchdacht hätten?
Leider ist der Trainingsdatensatz selbst für erfahrene Interviewer immer noch sehr klein. Er umfasst bestenfalls ein paar hundert Stichproben. Und wie wir weiter unten sehen werden, können diese Stichproben viel Rauschen enthalten.
Beschriftung des Trainingssets
Für jede Stichprobe in unserem Trainingsset (d. h. die Interviewhistorie eines bestimmten Interviewers) müssen wir sie als „wäre eine gute Einstellung gewesen“ oder „wäre nicht eine gute Einstellung gewesen wären“. Das ist sehr schwierig. Insbesondere gibt es hier eine MENGE Fehler in unseren mentalen Daten.
Wie erstellen wir unsere Labels? Nun, wir beginnen mit der anfänglichen Vorhersage, die unser Klassifikator zu diesem Zeitpunkt gemacht hat; also ob wir uns entschieden haben, die Person einzustellen oder nicht. Und dann müssen wir diese Labels rückwirkend anpassen, indem wir eine Rückkopplungsschleife einrichten, die unserem Modell hilft, aus seinen Fehlern der Vergangenheit zu lernen. Das heißt, wir müssen alle Fehler korrigieren, die es in der Vergangenheit gemacht hat. Wir müssen herausfinden, welche Entscheidungen Fehlalarm , und die waren Falsch-Negative . Wie machen wir das?
Falsch-Negative
Falsch-negative Personen sind Personen, die wir nicht einstellen wollten, die aber trotzdem gute Mitarbeiter gewesen wären. Wenn Sie jemanden abgelehnt haben, ist es praktisch unmöglich zu wissen, wie gut er sich als Mitarbeiter in Ihrem Unternehmen geschlagen hätte. Sie haben in Zukunft nur sehr wenig Kontakt mit diesen Personen und interagieren nicht wie mit einem Kollegen mit ihnen. Daher ist es wirklich schwierig, falsch-negative Informationen in Ihr mentales Modell einzuspeisen, um Ihre Bezeichnungen anzupassen.
Die beste Methode hierfür (und viele gute Unternehmen tun dies auch) besteht darin, abgelehnten Bewerbern die Möglichkeit zu geben, in nicht allzu ferner Zukunft erneut an dem Bewerbungsgespräch teilzunehmen. Sagen wir, in 6 Monaten. Wir machen das bei PagerDuty und von unseren etwa 11 Ingenieuren wurden tatsächlich 2 beim ersten Vorstellungsgespräch abgelehnt!
Allerdings handelt es sich hierbei nur um ein Rinnsal an falsch-negativem Feedback und es dauert eine ganze Weile, bis es erfasst wird.
Fehlalarm
Falsche Positivmeldungen sind der entgegengesetzte Fehlertyp: Personen, deren Einstellung wir „ja“ gesagt haben, obwohl wir das eigentlich nicht hätten tun sollen. Sofern Sie nicht sehr viel Glück haben, sind Sie dieser Art von Personen bei Ihrer Arbeit schon begegnet.
Es gibt zwei Kategorien dieser falschen Positivwerte: diejenigen, die das Stellenangebot letztendlich angenommen haben, und diejenigen, die es nicht angenommen haben. Bei denjenigen, die das Stellenangebot angenommen haben, ist es sehr einfach, diese Informationen in Ihr mentales Einstellungsmodell zurückzuspeisen, wenn Sie mit diesen Leuten arbeiten (und sie schließlich entlassen). Bei denjenigen, die nicht Wenn Sie das Angebot annehmen, stehen Sie allerdings vor einem ähnlichen Problem wie bei falsch-negativen Ergebnissen: Sie wissen nicht wirklich, ob es sich um eine schlechte Einstellungsentscheidung handelte oder nicht.
Kosten
Wenn Sie Ihre „Einstellung“- oder „Nichteinstellung“-Labels für Ihren Trainingssatz festlegen, sollten Sie Folgendes berücksichtigen: Kosten eine falsche Entscheidung zu treffen.
Die Kosten eines Fehlalarms sind enorm: Wenn Sie jemanden einstellen, der nicht gut zu Ihrem Unternehmen passt, kann dies erhebliche Auswirkungen auf die Qualität Ihres Produkts, die Produktivität anderer Teammitglieder, den Zeitplan von Projekten, die Arbeitsmoral usw. haben. In manchen Fällen können die Folgen ziemlich verheerend sein.
Die Kosten eines falschen Negativs sind größtenteils Opportunitätskosten: Wir haben es verpasst, diesen großartigen Ingenieur einzustellen. Es ist wirklich schwer zu sagen, was die Konsequenzen einer verpassten Einstellung wären: Würde uns das nur ein paar Wochen verzögern, während wir nach einem anderen guten Kandidaten suchen, oder haben wir einfach unsere Paul Buchheit ?
Unabhängig von der Höhe der Kosten falsch-negativer Ergebnisse sind diese sicherlich weniger sichtbar als die Kosten falsch-positiver Ergebnisse. Die Kosten falsch-positiver Ergebnisse lassen sich viel einfacher quantifizieren und es gibt viel weniger Wertabweichungen. Interviewer neigen daher fast immer dazu, auf Nummer sicher zu gehen und falsch-negativen Ergebnissen den Vorzug vor falsch-positiven Ergebnissen zu geben. Wir hoffen auch, dass dieses Problem gemildert wird, wenn wir den Kandidaten die Möglichkeit geben, später noch einmal in den Interviewprozess einzusteigen.
Das Testset
Schließlich gibt es noch unsere Prüfset . Beim maschinellen Lernen ist ein Testsatz ein separater Datensatz (bestehend aus Merkmalen und entsprechenden Bezeichnungen), der völlig unabhängig vom Trainingssatz ist. Er wird verwendet, nachdem der Klassifikator erstellt wurde (unter Verwendung dieses Trainingssatzes), um herauszufinden, ob das erstellte Modell „gut genug“ ist, um es tatsächlich zu verwenden. Die Verwendung eines Testsatzes verhindert, dass wir unser Modell überanpassen, um es zu genau an unsere Trainingsdaten anzupassen.
In der Praxis würde eine Wissenschaftlerin, die etwas auf sich hält, mehrere Klassifikatoren bauen und den verwenden, der am besten gegen den Testsatz abschneidet. Sie würde sogar einen dritten Satz einsetzen (ein Validierung Set), um sicherzustellen, dass sie nach den wiederholten Iterationen des Erstellens, Testens und Verfeinerns von Modellen ihr Modell nicht auch im Vergleich zum Testset überangepasst hat!
Wenn wir unser mentales Modell dessen erstellen, was einen anstellbaren Ingenieur ausmacht, ist ein Test-Set ein weiterer Luxus, den wir nicht haben, und wir enden mit Überanpassung . Je mehr Beobachtungen wir machen (je mehr Interviews wir geben), desto eher neigen wir im Allgemeinen dazu, diese Beobachtungen einfach in den Trainingsdatensatz aufzunehmen.
Unbequeme Wissenschaft
Kommen wir also auf meine ursprüngliche Frage zurück: Warum ist die Einstellung von Bewerbern so schwierig? Um es kurz zusammenzufassen: Wir sammeln eine kleine Anzahl von Merkmalen über eine ebenso kleine Anzahl von Beobachtungen in unserem Trainingsset, kennzeichnen unsere Beobachtungen ziemlich ungenau, da es schwierig ist, falsch-positive und falsch-negative Ergebnisse zu kennzeichnen, verwenden all dies, um ein undurchsichtiges Klassifizierungsmodell zu erstellen, führen aufgrund des Fehlens eines Testsets eine Überanpassung durch wie verrückt durch und tendieren am Ende aufgrund der hohen Kosten falsch-positiver Ergebnisse stark dazu, den Bewerber nicht einzustellen.
Sieht ziemlich düster aus, nicht wahr?
Wie also können wir es schaffen, bei der Einstellung von Personal einigermaßen gute Arbeit zu leisten? Nun, wir haben zumindest einen Vorteil: Wir verwenden eine Form von Ensemble-Lernen um unsere endgültige Entscheidung zu treffen. Beim Ensemble-Lernen verwenden Sie eine Reihe separater Klassifikatoren und verwenden diese zusammen, um bessere Vorhersagen zu treffen, als dies mit einem einzelnen Klassifikator möglich wäre. Wir tun dies in unseren Nachbesprechungen nach Abschluss der Interviewschleife: Die Interviewer setzen sich zusammen, gehen alle Fragen und Antworten durch und jeder entscheidet individuell, ob er diesen Kandidaten einstellt oder nicht. Dann treffen wir die endgültige Einstellungs-/Nichteinstellungsentscheidung auf der Grundlage einer Art Aggregation aller Stimmen.
[1] „Betrügerische Bestellungen“ sind solche, die von Kriminellen aufgegeben werden, die die Kreditkarte einer anderen Person gestohlen, sich per Phishing Zugang zu einem Konto einer anderen Person verschafft oder auf irgendeine Art und Weise versuchen, Amazon indirekt Geld zu stehlen. Darüber hinaus erlaubt Amazon in einigen Ländern Zahlungen über nicht garantierte Zahlungsmethoden. Das bedeutet, dass Amazon nicht wirklich garantiert ist, bezahlt zu werden, nachdem Waren versandt wurden, die von einer im Allgemeinen nicht kriminellen, aber zahlungsunfähigen Person bestellt wurden. Daher muss Amazon in einigen Fällen auch maschinenbasierte Modelle erstellen, um die allgemeine Kreditwürdigkeit seiner Kunden zu bestimmen.
[2] Bei vielen ML-Problemen könnte dies auch der Punkt sein, an dem Sie einen Fachexperten einstellen, der Ihnen hilft, relevante und prädiktive Eingaben zu erstellen. Leider haben wir bei der Entscheidung, ob wir jemanden einstellen oder nicht, normalerweise nur uns selbst als Experten. Darüber hinaus ist mindestens einer dieser „Softwareentwicklungsexperten“ in einer Einstellungsschleife oft sehr neu im Führen von Vorstellungsgesprächen und manchmal sogar ziemlich neu im Softwareentwicklungsbereich! Aber sie müssen diese Einstellungskompetenz irgendwo schärfen …
[3] Dies ist übrigens ein weiterer Grund, warum „Programmierportfolios“ zwar interessant sind, aber ein Vorstellungsgespräch nicht wirklich ersetzen können. Sie können Ihnen viel über den Programmierstil einer Person usw. beibringen, aber aufgrund der unstrukturierten Natur beispielsweise eines persönlichen Github-Repos einer Person können Sie nicht sagen, (A) wie gut sie Probleme löst, die ihr von anderen präsentiert werden, oder (B) wie produktiv/schnell sie ist, oder (C) ob der Code schreckliche Logikfehler enthält, ohne sich ernsthaft damit zu befassen, das Problem zu verstehen, das er lösen soll, usw. Und selbst wenn Sie das oben Genannte anhand eines Blicks auf ihre vergangenen Programmierabenteuer erkennen könnten, hätten Sie oft Schwierigkeiten, diese Eingaben in Ihren mentalen Klassifikator für eine „gute Einstellung“ einzuordnen, da Sie diese Merkmale nur für diesen Kandidaten und für keine anderen erstellt haben.
