In den letzten Jahrzehnten hat sich die Art und Weise, Programmierer zu interviewen, mehrmals geändert, und jeder von ihnen sieht im Nachhinein lächerlich aus. Entweder fanden wir endlich das wahre Geheimnis effektiver Interviews, oder wir ließen uns vom nächsten Modetrend mitreißen, der in zehn bis zwanzig Jahren genauso lächerlich erscheinen wird.

Wenn ich Leute in modischen großen Technologieunternehmen frage, warum es so notwendig ist, bei einem Interview nach Algorithmen zu fragen, lautet die häufigste Antwort: „Wir haben eine solche Skala, und wir können nicht zulassen, dass jemand versehentlich das O(n^2) schreibt O(n^2) und klopfte das ganze System " ¹ . Was besonders lustig ist, in letzter Zeit habe ich diese Algorithmen viel in der Praxis angewendet und echte Probleme gelöst, aber ich kann keine Interviews durchgehen, in denen Leute danach fragen! Glaubst du, ich scheitere die Hälfte der Interviews oder so? Nein, mehr als die Hälfte. Ich habe an ungefähr 40 "echten" Interviews teilgenommen und vielleicht ein oder zwei bestanden. Oder nicht ein einziger ² .

Als ich einen Entwurf für diesen Artikel schrieb, fanden es meine Freunde langweilig, weil ich zu viele Interviews nicht bestanden habe. Sie sagen, dass alle Fehler tabellarisch aufgeführt werden sollten, da niemand zehn Seiten Text mit einer langen Liste von Fehlern lesen wird. Guter Tipp. Ich arbeite schon an einem Tisch.

Schauen wir uns einige Beispiele an.

In einer großen Firma, in der ich gearbeitet habe, hat das Team eine Basisbibliothek mit einer eigenen Implementierung eines dynamischen Arrays geschrieben. Wenn während des Betriebs nicht genügend Größe vorhanden war, fügte die Implementierung dem Array eine feste Anzahl von Zeilen hinzu und kopierte dann das alte Array in ein neues Array mit etwas größerer Größe. Dies ist ein klassisches Beispiel für eine unsachgemäße Implementierung eines dynamischen Arrays , da dies zu einem linearen Zeitanstieg anstelle einer amortisierten konstanten Zeit führt. Dies ist ein so klassisches Beispiel, dass es häufig als kanonisch für die Erklärung der Abschreibungsanalyse verwendet wird.

In großen IT-Unternehmen lassen sich typische Telefoninterviews in drei Kategorien einteilen:

Eine "einfache" Programmier- / Algorithmusfrage, vielleicht zuerst mit einer "sehr einfachen" Aufwärmfrage.
Eine Reihe von "sehr einfachen" Programmier- / algorithmischen Fragen.
Eine Reihe bekannter Fakten (selten für gute Positionen, aber oft für niedrige oder nicht kreative Positionen).

Dieses Problem der Array-Implementierung wird als so einfach angesehen, dass es in die Kategorie "sehr einfach" fällt und entweder eine Aufwärmübung für eine "echte" Frage darstellt oder mit einer Reihe derselben einfachen Fragen einhergeht. In unserem Unternehmen war ein solches dynamisches Array jedoch für etwa 1% der Gesamtlast des Garbage Collectors im JVM-Code (die zweitgrößte Quelle für Speicherzuweisungen im gesamten Code) sowie für einen erheblichen Anteil der CPU-Last verantwortlich.

Glücklicherweise wurde diese Implementierung nicht als universelles dynamisches Array verwendet, sondern nur mit Hilfe einer semi-spezialisierten Shell erstellt. Daher war sie für „nur“ 1% des Drucks auf den GC verantwortlich. Wenn sie beim Interview gefragt würden, würden die meisten Mitglieder dieses Teams es richtig beantworten. Mein Patch brachte dem Arbeitgeber in einem Jahr mehr Geld als ich in meinem Leben verdient habe.

Es war die zweitgrößte Quelle für Speicherzuweisungen, die wichtigste war die Umwandlung eines Paares long Werte in Byte-Arrays aus derselben Basisbibliothek. Anscheinend hat jemand eine Hash-Funktion geschrieben oder kopiert, die ein Array als Eingabe verwendet hat, und dann den Code geändert, um zwei Arrays zu verwenden und mit ihnen in einer Sequenz aus einer alten Hash-Funktion wie byte[], byte[] . Um diese Funktion bei zwei Longs aufzurufen, verwendeten sie die praktische Funktion zur Konvertierung von long in byte[] in der weit verbreiteten Utility-Bibliothek. Diese Funktion markiert nicht nur byte[] und fügt dort long ein, sondern ändert auch die long Byte-Reihenfolge (anscheinend wurde die Funktion entwickelt, um long Werte in die Netzwerk-Byte-Reihenfolge umzuwandeln).

Leider wurde die Umstellung auf eine geeignetere Hash-Funktion als zu gravierend empfunden, sodass mein Patch darin bestand, die Schnittstelle für die Hash-Funktion zu ändern, statt zwei Byte-Arrays ein Paar Longs zu verwenden und einen separaten Schritt zum Ändern der Byte-Reihenfolge zu entfernen (da sich die Hash-Funktion bereits geändert hat) Für ihn war kein separater Schritt erforderlich. Die Beseitigung dieser unnötigen Operationen brachte dem Arbeitgeber in einem Jahr mehr Geld ein, als ich in meinem Leben verdient habe.

Optimierung ist technisch keine Frage von Algorithmen, wird aber in der Praxis ständig nachgefragt. Als Antwort auf eine Frage zu Algorithmen fragen sie mich normalerweise: "Können Sie es beschleunigen?" Die Antwort auf eine solche Frage beinhaltet oft eine einfache Optimierung, die den Code um ein Vielfaches beschleunigt.

Ein konkretes Beispiel, das ich beim Interview zweimal gefragt habe: Sie speichern Bezeichner als ints, aber aus dem Kontext folgt, dass die Bezeichner eng gepackt sind, sodass sie als Bitfeld gespeichert werden können. Die real existierende Lösung ist jedoch so weit von der erwarteten Antwort auf das Bitfeld entfernt, dass es kaum möglich ist, eine mehrfache Beschleunigung zu erreichen. Höchstwahrscheinlich endet das Interview dort.

Ein weiteres Beispiel für eine einfache Frage zu Algorithmen ist die tatsächliche Konfiguration von BitFunnel , dem in Bing ³ verwendeten Suchindex .

Das Beschreiben des vollständigen Kontexts dieses bestimmten Unternehmens wird zu viel Zeit in Anspruch nehmen. Kurz gesagt, Sie müssen eine Reihe von Bloom-Filtern konfigurieren. Eine Möglichkeit besteht darin, eine Optimierungsfunktion nach dem Black-Box-Modell zu schreiben, die anhand des Gradientenabfalls versucht, die optimale Lösung zu finden. Sie taten dies, aber die Funktion zeigte einige merkwürdige Eigenschaften und die Ausgangskonfiguration funktionierte nie perfekt. Dies wurde korrigiert, indem die Bloom-Filter verdünnt wurden, dh indem dem Problem noch mehr Ressourcen (und damit Geld) zugewiesen wurden.

Wenn Sie Optimierungsmöglichkeiten analysieren, stellen Sie möglicherweise fest, dass die grundlegende Operation in BitFunnel der Multiplikation von Wahrscheinlichkeiten entspricht. Daher können Sie für eine bestimmte Konfiguration einfach einige Wahrscheinlichkeiten multiplizieren - und bestimmen, wie die Konfiguration funktioniert. Da der Konfigurationsraum nicht so groß ist, können Sie alle möglichen Optionen durchlaufen und dann die beste auswählen. In der Realität ist dies nicht ganz richtig, da die Multiplikation der Wahrscheinlichkeiten eine gewisse Unabhängigkeit impliziert, die in der Realität nicht stattfindet. Die Methode funktioniert jedoch immer noch einwandfrei, aus dem gleichen Grund, dass die naive Bayes'sche Spam-Filterung ziemlich gut funktioniert und fälschlicherweise eine unabhängige Wahrscheinlichkeit des Auftretens im Brief voraussetzt zwei beliebige Wörter. Für eine vollständige Lösung können Sie die Abhängigkeiten analysieren. Obwohl dies wahrscheinlich den Rahmen des Interviews sprengt.

Dies sind nur drei Beispiele, die mir in den Sinn gekommen sind, und ich stoße ständig auf ähnliche Dinge und kann Dutzende Beispiele finden, vielleicht mehr als hundert, wenn ich mich hinsetze und versuche, alles aufzulisten, woran ich gearbeitet habe. Und mehr als hundert Beispiele, an denen jemand anders (oder niemand) gearbeitet hat. Beide Beispiele sowie diejenigen, die ich weggelassen habe, haben die folgenden Eigenschaften:

Ein Beispiel kann als Frage für ein Interview formuliert werden.
Wenn die Frage formuliert ist, erwarten Sie, dass die meisten (oder alle) Mitarbeiter des betreffenden Teams die richtige Antwort kennen.
Das Sparen von Geld aus diesem Fix bringt dem Arbeitgeber mehr Geld in einem Jahr, als ich in meinem Leben verdient habe.
Das Problem aus dem Beispiel bestand lange genug, sonst wäre es nicht aufgefallen.

Zu Beginn des Artikels haben wir festgestellt, dass große IT-Unternehmen Fragen zu Algorithmen stellen, da Ineffizienz in großem Maßstab sie teuer kostet. Meine Erfahrung zeigt, dass es in jeder interviewenden Firma eine Million Beispiele für solche Ineffizienzen gibt. Es stellt sich heraus, dass die Fragen zu den Algorithmen im Interview nicht dazu beitragen, echte algorithmische Probleme bei der Arbeit zu lösen.

Einer der Gründe ist, dass große Unternehmen versuchen, Leute zu finden, die Algorithmus-Rätsel lösen können, aber solche Überlegungen in der Produktion verbieten.

Von den drei Lösungen für die obigen Beispiele gingen zwei an den Hersteller. Für mich ist dies ein normaler Prozentsatz, wenn ich einfach zu einem zufälligen Projekt eingeladen wurde, dem ich nicht ständig folge. Zyniker können sagen, dass der Prozentsatz sogar hoch ist. In einem zufälligen Team könnten die Ergebnisse schlechter sein, da es für sie nicht vorteilhaft ist, eine Lösung zu implementieren, auch keine effektive. Schließlich müssen sie Änderungen testen, integrieren und bereitstellen. Neue Risiken entstehen. Das heißt, ich bitte das Team, etwas zu tun und Risiken einzugehen, um etwas Nützliches für das Unternehmen zu tun, das aber für sich selbst nutzlos ist. Trotz alledem akzeptieren die Leute normalerweise den Code, obwohl sie nicht sehr geneigt sind, Zeit für die Optimierung aufzuwenden (ihre Arbeitszeit wird für Dinge aufgewendet, die mit den Zielen des Teams vereinbar sind) ⁴ .

Angenommen, ein Unternehmen lehnt es ab, Kandidaten Interview-Rätsel anzubieten, und fordert die Entwickler auf, einfachere und relativ effiziente Algorithmen zu verwenden. Es ist unwahrscheinlich, dass eines der oben genannten Beispiele für viele Jahre unbemerkt bleibt. Das Problem wäre wahrscheinlich behoben. Einige hypothetische Entwickler in einem Unternehmen mit Code-Profiling würden die "heißesten" Elemente im Profil für die ressourcenintensivste Bibliothek sehen.

In zwei Fällen handelt es sich bei der praktischen Lösung nicht um eine Art magischen Algorithmus, sondern nur um eine umfassende Analyse. Das dritte Beispiel ist weniger offensichtlich, da es kein Standardwerkzeug zur Problemanalyse gibt. Sie können versuchen, das Ergebnis als eine Art Meisterleistung zu präsentieren. Schließlich basiert dieses Beispiel auf einem wissenschaftlichen Artikel, der auf der renommiertesten Konferenz seines Fachs als bester Artikel ausgezeichnet wurde. In Wirklichkeit gibt es jedoch Mathematik der Oberstufe, das heißt, eine echte Lösung für das Problem, die Sie gerade brauchen zu untersuchen, wo diese mathematischen Methoden anwendbar sind.

Ich habe wirklich einmal in einem Unternehmen gearbeitet, das bei Interviews keine Fragen zu Algorithmen stellte, sondern sich auf praktische Fragen konzentrierte. Während meines Aufenthalts dort fand ich nur eine Optimierungsmöglichkeit, die die oben genannten Kriterien fast erfüllt (aufgrund ihrer geringen Größe geht es nicht ein wenig über den dritten Punkt hinaus, das heißt, zu diesem Zeitpunkt hatte ich in meinem Leben mehr verdient als die jährlichen Einsparungen durch das Reparieren dieser Fehler).

Warum hatte diese Firma fast keine Probleme mit Leistungssteckern? Ich denke, der Hauptgrund ist, dass ziemlich viele Leute dachten, dass es ihre Aufgabe sei, das Unternehmen zu verbessern. Daher wurden die Systeme ursprünglich nahezu optimal ausgelegt. Mit seltenen Ausnahmen gab es genug Spezialisten, die versuchten, das Unternehmen weiter zu fördern und nicht sich selbst und ihrem Team persönlich (was sich vom globalen Nutzen für das Unternehmen völlig unterscheidet). So gab es immer jemanden, der das Problem löste, bevor es mir auffiel.

In großen IT-Unternehmen ist die Befragung von Algorithmen, die Codierungsfähigkeiten testen, in der Regel einfacher als die Erstprüfung per Telefon. Normalerweise werden Systemdesignprobleme hier nicht angesprochen.

Vor einiger Zeit haben wir versucht, in einem persönlichen Interview eine Frage zu Algorithmen zu stellen. Eine ziemlich schwierige Frage, aber im Rahmen dessen, worauf Sie bei großen Unternehmen beim Telefon-Screening stoßen könnten (aber immer noch einfacher, als Sie es von persönlichen Interviews erwarten würden). Wir haben diese Praxis aufgegeben, weil absolut alle Kandidaten diesen Teil nicht bestanden haben (wir haben den erfahrenen Kandidaten keine Frage zu den Algorithmen gestellt). Unser Unternehmen ist nicht so bekannt, dass es Neulinge gibt, die diese Fragen leicht beantworten können. Daher funktionieren diese modischen Filter für Kandidaten-Screening bei uns nicht. In modernen Einstellungsartikeln wird das, was wir getan haben, oft als "Senken der Messlatte" bezeichnet, aber ich verstehe nicht, warum wir die maximale Sprunghöhe des Kandidaten berücksichtigen sollten, wenn seine Arbeit fast (oder nie) Hochsprünge beinhaltet. Und in den Fällen, in denen Sie wirklich springen müssen, befindet sich die Stange in einer Höhe von etwa fünf Zentimetern.

Gemessen an der tatsächlichen Leistung war es das produktivste Unternehmen, in dem ich gearbeitet habe. Ich denke, dass die Gründe in der Kultur liegen und zu komplex sind, um sie in einem Artikel vollständig zu zerlegen, aber es hat uns wahrscheinlich geholfen, dass wir mit Hilfe von Algorithmus-Tests keine guten Kandidaten herausgefiltert haben. Wir haben vorgeschlagen, dass die Menschen dieses Material bei der Arbeit studieren können, wenn wir die richtige Kultur haben und die Mitarbeiter das Richtige tun, anstatt sich auf lokale Aufgaben für sich selbst oder ihre Abteilung zu konzentrieren.

Wenn andere Unternehmen möchten, dass die Mitarbeiter bei der Arbeit Probleme mit Algorithmen auf dem gleichen Niveau lösen, auf dem sie bei Interviews gefragt haben, müssen Sie die Mitarbeiter grundsätzlich dazu ermutigen, Probleme mit Algorithmen zu lösen (falls zutreffend). Dies kann zusätzlich oder sogar anstelle der Auswahl von Kandidaten für theoretische Probleme erfolgen.

Anhang: Wie sind wir dazu gekommen?

In der guten alten Zeit wurden bei Interviews „triviale“ Fragen gestellt. Moderne Versionen könnten so aussehen:

Was ist MSI? MESI? MOESI? MESIF? Was ist der Vorteil von MESIF gegenüber MOESI?
Was macht ein Destruktor? Und wenn es C ++ 11 ist? Und wenn Sie den Subobjekt-Destruktor vom Top-Level-Destruktor aufrufen, welche anderen Subobjekt-Destruktoren werden dann ausgeführt? Und während der Förderung des Stapels? Unter welchen Umständen können Sie vermeiden, std::terminate aufzurufen?

Ich hörte von diesen einfachen Interviews in der Schule und sah in einigen Unternehmen sogar die „alte Schule“. Dies geschah unter der Führung von Microsoft, als alle anderen zu einem erfolgreichen Unternehmen aufschauten und Microsoft kopierten. Der meistgelesene Programmierblogger (Joel Spolsky) sagte, jeder müsse sich auf eine X-Entwicklungspraxis einlassen, weil Microsoft dies tut. Zum Beispiel führte Joel Spolsky in einem der einflussreichsten Programmartikel der Zeit den sogenannten Joel-Test ein, der feststellt, wie viel Sie mit Unternehmen wie Microsoft auf dem Laufenden halten:

12 Punkte sind exzellent, 11 Punkte sind erträglich, aber bei einer Bewertung von 10 oder weniger treten ernsthafte Probleme auf. Die Wahrheit ist, dass die meisten Programme auf einer Ebene von 2 bis 3 Punkten arbeiten und ernsthafte Hilfe benötigen, da Unternehmen wie Microsoft auf Ebene 12 Vollzeit arbeiten.

Nach populären Legenden dieser Zeit stellte Microsoft solche Fragen bei Interviews (und mir wurde bei einem Interview in Microsoft um 2001 wirklich eine dieser Aufgaben gestellt, ohne Fragen zu Algorithmen oder Programmierung):

Wie komme ich aus einem Mixer heraus, wenn ich 1 cm groß bin?
Warum sind Kanaldeckel rund?
Der fensterlose Raum verfügt über drei Lampen, die jeweils über einen Schalter von außen gesteuert werden. Sie befinden sich außerhalb des Raumes und können nur einmal hineingehen. Wie bestimme ich, welcher Schalter welche Lampe steuert?

Da ich in einer Ära des Wandels interviewt wurde, wurden mir viele einfache Fragen und eine Reihe von Aufgaben gestellt (einschließlich all der oben genannten). Bei Interviews dieser Zeit waren Fermis Fragen , die technisch gesehen keine Rätsel sind, immer noch beliebt. Ein weiterer Trend der Zeit waren Verhaltensinterviews ohne ein einziges technisches Problem.

Wie dem auch sei, die Leute versuchten, Interviews im Microsoft-Stil zu kopieren. Als ich gefragt habe, welche Art von Rätseln oder Fermis Fragen gut sind, haben sie mir geantwortet, dass es auf diese Weise möglich ist, zu überprüfen, ob der Kandidat zur Reflexion fähig ist, im Gegensatz zu Wissensfragen, die nur besagen, dass sich eine Person an einige Informationen erinnert hat. Und wir brauchen Kandidaten, die wirklich denken können!

Rückblickend ist nun allen klar, dass dies ineffizient war. Wenn Sie jeden Microsoft-Trick kopieren, wird Ihr Unternehmen nicht so erfolgreich, da Microsoft viele andere Tricks verwendet hat. Sie wirken nur aufgrund des Netzwerkeffekts zusammen. Durch das Kopieren von Microsoft-Interviews werden Sie zu einem Unternehmen, das Interviews einfach im gleichen Stil durchführt, jedoch die von Microsoft verwendeten Netzwerkeffekte nicht nutzen kann.

Für die Kandidaten war das Interviewverfahren im Grunde dasselbe wie jetzt für die Algorithmen. Um sich auf ein Interview vorzubereiten, musste man, anstatt ein Programmierinterview zu hacken, lesen, wie man den Berg Fuji bewegt. Das heißt, Sie mussten viel Wissen über Aufgaben erlernen, die Sie niemals bei der Arbeit verwenden werden, anstatt Kenntnisse über Algorithmen, die Sie niemals auf die gleiche Weise verwenden werden.

In jenen Tagen fanden Interviewer Interviewfragen in Vorbereitungsbüchern für Interviews, wie zum Beispiel Wie man den Fuji bewegt. Diese Fragen wurden Kandidaten gestellt, die die Antworten in denselben Büchern gelernt hatten. Die moderne Jugend findet das lächerlich - es ist offensichtlich, dass die Fragen nichts mit Arbeit zu tun haben und die Wahrscheinlichkeit einer guten Antwort mehr von der Vorbereitung auf ein Vorstellungsgespräch abhängt als von der Kompetenz des Bewerbers. Aber der heutige Ansatz ist nicht so anders.

In den letzten Jahrzehnten hat sich die Art und Weise, Programmierer zu interviewen, mehrmals geändert, und jeder von ihnen sieht im Nachhinein lächerlich aus. Entweder fanden wir endlich das wahre Geheimnis effektiver Interviews, oder wir ließen uns vom nächsten Modetrend mitreißen, der in zehn bis zwanzig Jahren genauso lächerlich erscheinen wird.

, ( ), , . .

- , , . ( ):

Was denn , ?
, .
, .
.
Wir hätten Voreingenommenheit bemerkt, wenn es einen Bewertungsprozess gegeben hätte.
Jemand hat die Studie studiert und / oder durchgeführt, kann aber nichts Konkretes darüber sagen, wie sie studiert wurde und nach welcher Methode die Studie durchgeführt wurde.

Anwendung: Training

Wie bei den meisten realen Problemen ist es unmöglich, den einzigen Grund zu finden, warum Fehler im Wert von Dutzenden und Hunderten von Millionen Dollar in der Produktion nicht gemeldet werden. Einerseits stoßen wir auf eine Art Tiefenverteidigung mit unpassenden Anreizen. Auf der anderen Seite wird das Lernen leider unterschätzt .

Ich habe bereits erwähnt, dass das System in fast allen Unternehmen die Menschen nicht dazu ermutigt, Zeit für die Verbesserung der Effizienz aufzuwenden, selbst wenn eine einfache Berechnung zeigt, dass die Behebung von Fehlern leicht Dutzende oder Hunderte von Millionen Dollar einsparen kann. Und da es keine Anreize gibt, haben Entwickler keine Möglichkeit, Erfahrungen mit solchen Arbeiten zu sammeln. Ungewohntes Arbeiten erscheint immer komplizierter als es wirklich ist. Selbst wenn ein Arbeitstag in Form von Einsparungen oder Gewinnen 1 Million US-Dollar pro Jahr einbringen kann (dies ist meiner Erfahrung nach in großen Unternehmen durchaus üblich), verstehen die Menschen nicht, dass dies nur ein Arbeitstag ist und dass er ohne Ablenkung durchgeführt werden kann aus dem Rest der Fälle. Eine Möglichkeit, dieses letzte Problem zu lösen, ist das Training. Es ist jedoch noch schwieriger für einen Manager, dies zu rechtfertigen, als die Effizienz zu steigern, was nicht zu den Hauptaufgaben gehört!

, (4500 , , ) : CPU, GC , JVM, . . , , . , , - . , 10% , , , .

Wenn ich anstelle eines Leitfadens eine Woche für einen „echten“ Job zubringen würde, würde ich etwas Bestimmtes mit quantitativem Wert erhalten, das in einem Werbepaket oder einer Leistungsbeurteilung wunderschön aussieht. Stattdessen habe ich eine vage Leistung, die bestenfalls teilweise als "Extra-Verdienst" angesehen werden kann. Ich beschwere mich nicht - das ist genau das Ergebnis, das ich erwartet habe. Im Durchschnitt erhalten Unternehmen jedoch, was sie selbst für die Mitarbeiter tun. Wenn sie erwarten, dass die Schulungen von den Entwicklern selbst durchgeführt werden (ohne die Herstellung von Schulungsunterlagen zu finanzieren), diese jedoch nicht so hoch einschätzen wie die Arbeit der Entwickler, werden Schulungen seltener.

Ich glaube, es ist leicht, die schlechte Qualität der öffentlichen Unterrichtsmaterialien zu bemerken, da es relativ schwierig ist, Bildung und Ausbildung zu monetarisieren. Wenn Sie Trainingsprogramme monetarisieren möchten, gibt es einige gute Methoden. Anscheinend funktioniert die Monetarisierung wertvoller Videokurse gut (Hunderte oder Tausende von Dollar für einen kurzen Kurs). Unternehmenstrainings, bei denen Unternehmen Sie zu Gesprächen mit 30 Personen einladen und von denen Sie jeweils 3.000 US-Dollar erhalten, funktionieren ebenfalls recht gut.

Wenn Sie eine große Anzahl von Menschen erreichen (und potenziell helfen) möchten, ist das Veröffentlichen im Internet effektiv, aber Sie können keine Monetarisierung erwarten. Bei technischen Themen ist es unwahrscheinlich, dass das Publikum ohne Werbeblocker groß genug ist, um Inhalte durch Werbung zu monetarisieren (im Gegensatz zum kostenpflichtigen Zugriff).

Zum Beispiel Julia EvansGenügend Einkommen für den Verkauf von Computer-Comics, die in letzter Zeit etwa 100.000 US-Dollar pro Jahr einbringen. Ein Corporate Training Spezialist kann dies in ein bis zwei Tagen verdienen.

Anhang: Tiefenverteidigung mit Incentive-Mismatch, Teil 3

Von den drei oben genannten Beispielen erhielt ich in zwei Fällen eine Ermutigung, das Geld des Unternehmens zu sparen. Nach meiner Erfahrung ist dies in großen Unternehmen selten der Fall, aber die Verteilung der Anreize erwies sich als eher schlecht. Irgendwann, nach Beförderung und Gehaltserhöhung, errechnete ich das Verhältnis meiner Erhöhungen und Ersparnisse, die ich dem Unternehmen gebracht hatte. Die Quote betrug direkt im Geld ungefähr 0,03%, ohne die von mir entwickelten Tools zu berücksichtigen, für die es schwierig ist, einen bestimmten Wert zu berechnen. Wahrscheinlich ist dieser Wert tatsächlich mehr als ein quantifizierbarer Wert. Wir können daher den Schluss ziehen, dass ich deutlich weniger als 0,01% des Betrags erhalten habe, den das Unternehmen mitgebracht hat. Und dies ist eine überschätzte Einschätzung: In Wirklichkeit vermute ich stark, dass die geleistete Arbeit mir tatsächlich nichts gebracht hat.und der Anstieg hat nichts mit diesem Projekt zu tun, das dem Unternehmen Dutzende Millionen Dollar erspart hat. Nach den ersten 10 Millionen USD pro Jahr oder vielleicht 20 Millionen USD pro Jahr gibt es keinen Anreiz mehr, Arbeiten im Hinblick auf die Bewertung von Wirksamkeit, Beförderung, Verbesserung usw. durchzuführen. Weil es keine Vorteile gibt, aber einige Nachteile gibt (Sie können dies tun) sich auf Undercover-Intrigen einlassen, versehentlich eine Site zum Absturz bringen usw.), so dass die Rendite bei optionaler Arbeit wahrscheinlich negativ wird.Es gibt jedoch einige Nachteile (Sie können in verdeckte Intrigen verwickelt werden, versehentlich eine Site zum Absturz bringen usw.), so dass die Rendite bei optionaler Arbeit wahrscheinlich negativ wird.Es gibt jedoch einige Nachteile (Sie können in verdeckte Intrigen verwickelt werden, versehentlich eine Site zum Absturz bringen usw.), so dass die Rendite bei optionaler Arbeit wahrscheinlich negativ wird.

, , , , «» . , , «».

, , .

Es kam auch vor, dass Manager ein Teambudget zur Erhöhung der Gehälter erhalten, das hauptsächlich von der Anzahl der Mitarbeiter abhängt und dann auf die Mitarbeiter verteilt wird. Grundsätzlich hat das Team nur produktive Entwickler, so dass unter anderem niemand auffällt. Gleichzeitig ist die Fluktuation sehr gering, da Programmierer gerne mit guten Kollegen zusammenarbeiten. Um die Mitarbeiter zu ermutigen, in weniger effektive Teams zu wechseln, setzt das Unternehmen einen der stärksten Hebel ein - die Kompensation.

Da dies in einigen Unternehmen ein gängiges System ist, versuchen Manager, harmlose, aber ineffiziente Mitarbeiter zu halten, um Bonusbeschränkungen zu umgehen. Wenn man sich theoretisch fragt, ob Unternehmen ineffektive Mitarbeiter einstellen und halten müssen, lautet die Antwort nein. In der Praxis wird dies jedoch indirekt durch das Schema der universellen Prämien für ein Team angeregt.

Algorithmus-Interviews: Theorie vs. üben

Anhang: Wie sind wir dazu gekommen?

Anwendung: Training

Anhang: Tiefenverteidigung mit Incentive-Mismatch, Teil 3

Verwandte Links

More articles: