Menschen, die LeetCode-Style-Interviews satt haben

• Nachdem er Robinhood Ende November 2023 aus gesundheitlichen Gründen verlassen hatte, durchlief er mehrere Bewerbungsprozesse und gewann den Eindruck, dass LeetCode-artige Bewertungen nicht mit der tatsächlichen Arbeit in der Softwareentwicklung übereinstimmen
• Er sieht, dass viele Unternehmen ähnliche Interviews wiederholen, indem sie die Methoden von großen Tech-Konzernen wie Google, Facebook/Meta und Amazon übernehmen
• Ingenieurinnen und Ingenieure sagen, man müsse kein nachschlagbares Wissen auswendig lernen, kritisieren aber, dass in Interviews genau solches Wissen wie in einem Quiz abgefragt wird, obwohl es sich nicht immer sofort abrufen lässt
• Er hat in solchen Interviews sowohl Erfolg als auch Misserfolg erlebt, und die Grundlage seiner Unzufriedenheit liegt näher an seiner früheren Praxiserfahrung als an Erfahrungen des Scheiterns
• Wenn ein Unternehmen nach einem Ingenieur mit Erfahrung in AWS, Kubernetes und Ruby on Rails sucht und dabei auf unnötige Quizfragen verzichtet, könne es sich gern melden

---

Wo LeetCode-artige Interviews von der realen Arbeit abweichen

• Nachdem er Robinhood Ende November 2023 aus gesundheitlichen Gründen verlassen hatte, führte er Interviews mit mehreren Unternehmen
• Die Bewerbungsprozesse wurden aus verschiedenen Gründen nicht fortgesetzt, aber er empfindet vor allem Ermüdung gegenüber den sich wiederholenden LeetCode-Style-Interviews
• Solche Interviews spiegeln seiner Ansicht nach die tatsächlichen Verantwortlichkeiten in der Softwareentwicklung nicht ausreichend wider
• Viele Unternehmen übernehmen offenbar dieselben Bewertungsmethoden, weil große Konzerne wie Google, Facebook/Meta und Amazon sie ebenfalls einsetzen

Der Konflikt zwischen quizartiger Bewertung und Praxiserfahrung

• Es gibt Ingenieurinnen und Ingenieure, die normalerweise sagen, dass man Wissen, das sich leicht mit Google finden lässt, nicht auswendig lernen müsse
• In Interviews werden jedoch manchmal Inhalte abgefragt, die man zwar nachschlagen könnte, aber nicht unbedingt spontan parat hat, was er als widersprüchlich empfindet
• Eine klare Lösung für dieses Problem gibt es zwar nicht, aber für ihn ist das Problem selbst eindeutig
• Er hat in dieser Art von Interviews sowohl Erfolge als auch Misserfolge erlebt, und diese Sichtweise wird stärker von seiner früheren Berufserfahrung als von seiner Misserfolgsquote geprägt
• Wenn ein Unternehmen eine Softwareingenieurin oder einen Softwareingenieur mit Erfahrung in AWS, Kubernetes und Ruby on Rails sucht und keine quizartigen Interviews führt, könne es sich gern melden
• Als weiterführende Lektüre nennt er Re-imagining Technical Interviews: Valuing Experience Over Exam Skills

[GN⁺]

Meinungen auf Hacker News

• Ich verstehe die Frustration, aber letztlich haben auch solche Interviews aus meiner Sicht einen Zweck. Selbst wenn sie nicht besonders gut sind, sind sie ausreichend brauchbar, und aus Unternehmenssicht ergeben sie Sinn, weil sie in der Regel mehr falsch Negative als falsch Positive erzeugen.
  Die Kosten dafür, dass eine kluge Person abgelehnt wird, sind gering. Stellt man aber die falsche Person ein, muss man sie über Monate beurteilen, entlassen und wieder neu rekrutieren – das ist teuer. Für Bewerber ist der Prozess allerdings extrem schmerzhaft, und selbst hervorragende Software Engineers können nervös sein, etwas übersehen oder einfach einen schlechten Tag haben und ein paar Mal durchfallen. Ein Interview ist keine abschließende Bewertung des Lebenswerts, sondern nur ein stumpfes Werkzeug; man sollte es einfach abhaken.

  • In den Firmen, die ich geführt habe, haben wir deshalb einfache Whiteboard-Beispiele verwendet. Tippfehler waren uns egal; wir wollten sehen, wie jemand denkt.
    „Fangfragen“ sind dumm, aber man muss sehen, ob ein Kandidat die Grundlagen kennt, und zugleich zeigen, was für eine Art Unternehmen man ist. Wenn jemand zum Beispiel fragt: „Darf ich die Argumente verändern?“ oder sagt: „Ich weiß gerade nicht mehr, ob strlen das Nullbyte mitzählt, also addiere ich 1; normalerweise würde ich das nachschlagen“, ist das ein gutes Zeichen. Die Aufgaben lagen auf einem Niveau wie atoi oder „ein Kartendeck mischen“: grundlegend, aber nicht ganz so trivial wie FizzBuzz. Einer der besten Leute, die wir eingestellt haben, machte einen fundamentalen Fehler, sagte aber, als wir fragten, ob das wie beabsichtigt funktionieren würde: „Ich bin ein verdammter Idiot“, und korrigierte es sofort. Dieser Ton ist in einem Interview vielleicht nicht angemessen, aber wir werteten es als stark positives Signal. Umgekehrt gab es auch einen Kandidaten, der bis zum Ende darauf bestand, die Frage, einen String zu parsen und eine Ganzzahl zurückzugeben, sei unfair, weil es dafür schon eine Library-Funktion gebe; tatsächlich liefen Teile unseres Systems in einer Embedded-Umgebung ohne Library.
  • Selbst wenn man Quizfragen stellt, sollte man den Leuten erlauben, zu suchen. So arbeiten Software Engineers tatsächlich; man sollte daraus keine Prüfung machen.
    Ich wünschte, man würde nicht die schrecklichen Prüfungen aus Schule und Universität imitieren, die zuerst das Gedächtnis testen. Ich hatte große Probleme damit, Dinge bei Bedarf spontan abzurufen, und ich bin sicher nicht der Einzige. Bei Interviews für Android-Entwickler stellte ich Fragen und schaute mir an, wie sie darüber nachdachten; ich erwartete nicht, dass jede Antwort exakt richtig war. Nachdem ich geprüft hatte, ob ein grundlegendes Verständnis von Android vorhanden war, ließ ich sie zu Hause eine kleine App bauen.
  • Das Argument „kluge Leute fallen durch, aber Idioten werden selten eingestellt“ habe ich gesehen, aber ich frage mich, ob es tatsächlich stimmt. Besonders dann, wenn man auch an die andere Recruiting-Weisheit glaubt, dass „die meisten Bewerber nicht qualifiziert sind“.
    Bei Einstellungen, bei denen am Ende eine Stelle besetzt werden muss, steigt mit mehr falsch Negativen auch die Wahrscheinlichkeit, ein falsch Positives einzustellen. Im Extremfall: Wenn es auf der Erde nur eine einzige Person gibt, die für den Job geeignet ist, und man diese Person fälschlich aussortiert, bleibt als einzige Option, die falsche Person einzustellen.
  • Solche Interviews erzeugen auch viele falsch Positive. Nur nicht im Sinne von „einen Idioten einstellen“, sondern indem man jemanden einstellt, der gut in LeetCode ist, aber überhaupt nicht zur eigentlichen Arbeit passt.
    Das Problem ist nicht mangelnde Intelligenz, sondern dass jemand zwar Algorithmusaufgaben gut lösen kann, aber kein Software Engineer ist oder nicht die Fähigkeiten hat, die diese Position erfordert. Ich arbeite in einem Team, in dem viele über Puzzle-Interviews eingestellt wurden; alle sind klug, aber sie sind keine Software Engineers, und dieser Unterschied zeigt sich deutlich.
  • Schwere LeetCode-Aufgaben wählen keine denkenden Menschen aus, sondern Menschen, die wiederholt trainiert haben. Viele dieser Aufgaben wären, als sie vor Jahrzehnten erstmals gelöst wurden, stoff für wissenschaftliche Arbeiten gewesen, und selbst sehr kluge Menschen könnten in wenigen Dutzend Minuten kaum von Grund auf zu ähnlichen Ergebnissen kommen.
    Wenn jemand sie löst, ist es viel wahrscheinlicher, dass er beim Üben dieselbe oder eine ähnliche Aufgabe gesehen hat, als dass er wirklich die optimale Lösung neu hergeleitet hat.

• Einmal hatte ich ein Interview, das mir ziemlich gut gefiel; es war bei einer Bank. Man gab mir hastig geschriebenen, unordentlichen Code – aber keinen absichtlich verschleierten – und bat mich, ihn so gut wie möglich zu refaktorisieren.
  Der Interviewer saß daneben und sprach während des gesamten Prozesses mit mir; im Grunde war es fast Pair Programming, bei dem der Kandidat die Führung hatte. Nach all den LeetCode-Interviews war das erfrischend. Natürlich war diese Methode möglich, weil die Bank genau wusste, welche Technologien sie einsetzte, und kaum messen musste, wie gut jemand neue Technologien lernen kann. Für sie war wichtiger, ob jemand wartbaren Code schreiben, Dinge sinnvoll benennen und mit Kollegen kommunizieren kann.

  • Ein LeetCode-Interview misst doch auch nicht wirklich die Fähigkeit, neue Technologien zu lernen, oder?
  • Ich verwende diese Art von Interview ebenfalls häufig. Der Anfang ist sehr grundlegend, und da ich hauptsächlich mit Datenbanken arbeite, geht es danach in einen Abschnitt mit Code Review über.
    Interessant ist, dass manche, die bei den Grundlagenfragen fast scheitern, im Code Review so gut sind, dass ihre tiefe Expertise sichtbar wird. Interviews sind ein ziemlich schlechtes Werkzeug, um die Arbeitsfähigkeit eines Menschen zu zeigen, aber wenn jemand Probleme sowohl breit als auch eng betrachten kann und auch ausreichend gut codet, betrachte ich das meist als Erfolg.

• Interviews im LeetCode-Stil erfüllen vermutlich zwei Funktionen. Erstens sind sie ein Mittel, um Gehälter und Wechselmobilität von Software Engineers zu drücken. Wer wechseln will, muss ein, zwei Monate lernen – wer wechselt da schon leichtfertig?
  Wenn man Pech hat und ein Interviewer, der sich selbst hart vorbereitet hat, eine Bombe auf LeetCode-hard-Niveau fallen lässt, kann man sich ein Jahr lang kaum noch einmal bei diesem Unternehmen bewerben. Zweitens werden sie zu einem Mittel, um Voreingenommenheit im Prozess zu verdecken, während man behauptet, allen ein ähnliches und klares Ziel gegeben zu haben. Bei gleicher Hochschule, gleichem Geschlecht oder gleicher Herkunft kann man trotz gleicher Aufgabe Hinweise geben, Syntaxfehler durchgehen lassen und selbst ohne optimalen Ansatz wegen „Kommunikation“ eine starke Einstellungsbewertung abgeben. Wenn einem jemand nicht passt, stellt man eine schwere Aufgabe und schweigt das ganze Interview über. Für das Unternehmen ist das akzeptables Rauschen, für die einzelne Person bedeutet es den Verlust einer Chance auf eine Vergütung in Höhe von Hunderttausenden Dollar. Ich habe FAANG-Interviews gemacht und auch selbst interviewt; dabei habe ich gesehen, wie Leute mit niedrigen Standards eingestellt wurden, während gleichzeitig hervorragende Engineers wegen absurder Fragen zu Quadtrees oder Zahlentheorie ihre Chance verpassten.

  • In jedem Prozess kann man unfair handeln, wenn man es darauf anlegt, aber ich denke, dass ein standardisierter Test den Prozess eher deutlich fairer macht.
    Wenn man faire Interviewer voraussetzt, gibt diese Methode auch Kandidaten, deren Lebenslauf keine berühmten Namen enthält, die Chance, ihre Fähigkeiten zu zeigen. Einige der Chancen, die ich ohne Informatikabschluss bekommen habe, hätte ich ohne Whiteboard-Interviews niemals erhalten. Ich kann mir kaum eine Methode vorstellen, die verhindert, dass ein Interviewer den Prozess absichtlich umbiegt, um einen Freund einzustellen.
  • Das hier beschriebene Problem ist nicht LeetCode selbst, sondern Interview-Varianz und Hiring-Bias. Das gibt es in jedem Interviewformat.
    Viele Unternehmen haben einen Aufgabenpool, der fair und einigermaßen realitätsnah konzipiert ist. Bei den Unternehmen, bei denen ich interviewt habe, war das meist so; auch wenn es nicht exakt echte LeetCode-Aufgaben waren, waren es letztlich isolierte Coding-Aufgaben, also würde ich sie als LeetCode-artig bezeichnen. Interviews bei Unternehmen, die diesen Ansatz gut betreiben, waren ziemlich in Ordnung. Gute Unternehmen und Interviewer schauen nicht nur auf den finalen Code, sondern auf viel mehr, und sie vergeben Hiring-Ratings auf einer Skala, um binäre Entscheidungen zu reduzieren.
  • Das Problem ist nicht das Format eines einfachen 30- bis 50-minütigen Coding- und Datenstrukturen-/Algorithmen-Interviews an sich, sondern der steigende Schwierigkeitsgrad.
    Realistisch gesehen hat schon FizzBuzz 75 % ausgesiebt. Viele Menschen können unter Druck keinen Code schreiben, und manche halten sich mit Copy-and-paste irgendwie über Wasser. Solche Leute sind nicht zu gar nichts fähig, aber sie sind langsam, liefern merkwürdige Abstraktionen und verbrauchen viel Zeit, bis brauchbare Ergebnisse herauskommen. Und weil auch für sie Hunderttausende Dollar auf dem Spiel stehen, widersprechen sie genauso.
  • Diese Methode ist auch sehr gut darin, Menschen mit zeitlichen Einschränkungen auszusieben, etwa wegen Kindern, pflegebedürftigen Eltern oder gesundheitlichen Problemen.
    Aus Unternehmenssicht ist das rational. Man will schließlich Mitarbeiter, die nicht abgelenkt sind und Überstunden machen können.
  • Wenn man die höchste Vergütung will, muss man dieses Spiel spielen. Das ist in jedem Beruf so; glauben Anwälte, die in eine Top-Kanzlei wollen, etwa, sie hätten es leichter?
    An heutigen Tech-Hiring-Praktiken gibt es viel berechtigte Kritik, aber die Beschwerde „Ich kann nicht enorm reich werden, ohne meine Seele zu verkaufen“ ist nicht besonders überzeugend.

• Beim Auswählen von Software Engineers zählt nicht Wissen, sondern Problemlösungskompetenz und die Fähigkeit, ein mentales Modell des Problems aufzubauen.
  Wenn der Kandidat das Problem vorher noch nicht gesehen hat und der Interviewer versteht, worauf er achten muss, ist ein Whiteboard-Interview eine gute Methode, um diese Fähigkeit zu bewerten. Aber wie bei Goodharts Gesetz gilt: Wenn eine Messgröße zum Ziel wird, ist sie kein guter Indikator mehr. Auch Menschen mit schwacher Problemlösungs- oder Modellierungsfähigkeit wollen gut bezahlte Softwarejobs, also grinden sie LeetCode; und wenn diese Leute mit der Zeit selbst Interviewer werden, führen sie Interviews wie Gedächtnistests, so wie es bei ihnen gemacht wurde. Trotzdem habe ich angesichts der Zwänge der Unternehmen, der Notwendigkeit, die Zeitverschwendung für Kandidaten zu reduzieren, und des HR-Wunsches nach konsistenten Bewertungsbögen noch keinen besseren Interviewansatz gesehen, und er wird wohl vorerst weiter genutzt werden.

  • Bessere Methoden sind leicht zugänglich. Man kann Kandidaten etwas Bekanntes wie einen Taschenrechner oder Kalender bauen lassen oder ihnen ein Code-Bündel geben, das sie ändern oder in dem sie Bugs finden sollen.
    Das ist näher am Erstellen von Software. LeetCode ist zu weit von der tatsächlichen Arbeit entfernt, und die Leistung korreliert viel zu schwach mit der tatsächlichen Eignung.
  • Man kann auch zu dem Schluss kommen, dass ein hoher LeetCode-Score ein guter Indikator dafür ist, wer durch LLMs ersetzt werden wird.
  • Es heißt: „A-Leute stellen B-Leute ein, und B-Leute stellen C-Leute ein.“ Um das zu verhindern, hat man dem Interviewprozess eben noch mehr LeetCode hinzugefügt.
  • Warum sollte ein Unternehmen sich ernsthaft um dieses Problem kümmern und versuchen, den Einstellungsprozess weniger feindselig zu machen? Es gibt immer noch viele Kandidaten, die bereitwillig jeden Test bestehen wollen, der ihnen vorgesetzt wird.
    Es ist ein löchriger Eimer, aber die Unternehmen sind mit dem Status quo zufrieden, und Entwickler grinden weiter LeetCode. Es sieht nicht so aus, als würde sich das bald ändern, aber zum Glück bin ich in einer Lage, in der ich solche Interviews ablehnen kann, wenn ich mir einen neuen Job suche.

• Ein Freund hat einmal mitten in einem technischen Interview plötzlich aufgehört zu sprechen, ist aufgestanden und gegangen. Die Leute aus dem Unternehmen liefen ihm hinterher und sagten: „Was ist los, Sie machen das gut!“, aber er sagte, er sei zu deprimiert geworden und habe kein Interesse mehr.
  Für die meisten wäre das wohl ein schöner Beruf; das ist traurig.

  • Ich habe einmal etwas Ähnliches getan. Es war eine Spielefirma, bekannt für gute Benefits, aber auch für wahnsinnige Produktionspläne, und anfangs wollte ich wirklich dorthin.
    Doch etwa in der Mitte des Interviews kam ein Whiteboard zum Einsatz, Kollegen kamen herein und forderten mich auf, grundlegende Dinge mit einem Stift zu implementieren. Je weiter es ging, desto feindseliger und unhöflicher wurden sie, sodass es sich wie ritualisiertes Mobbing anfühlte. Es wirkte, als wollten sie testen, ob ich Beleidigungen und Feindseligkeit aushalten kann, während ich technisch triviale Ergebnisse liefere. Schließlich brach ich das Interview ab und sagte: „Ich habe gesehen, wie Sie arbeiten, und entschieden, dass ich hier nicht arbeiten möchte. Danke für die Gelegenheit, und es tut mir leid, dass wir gegenseitig unsere Zeit verschwendet haben.“ Dann ging ich. Der CEO lief mir bis zum Parkplatz hinterher und fragte, wie es dazu gekommen sei; er schien wirklich schockiert darüber, dass ein Bewerber während eines Interviews eine Entscheidung treffen kann. Menschen vergessen, dass ein Jobinterview in beide Richtungen geht. Seit diesem Tag ist mir klar, dass ich das Recht habe, jeden Aspekt eines Unternehmens zu prüfen, bei dem ich möglicherweise arbeiten werde, und dass ich keine Kompromisse eingehen muss, wenn ich im Prozess etwas Negatives sehe. Am nächsten Tag traf ich bei einem Konkurrenten Menschen, die bis heute gute Freunde und Kollegen sind, also war es die richtige Entscheidung. Dieser Beruf macht Spaß, aber wenn dieser Spaß wie auf einer Farm geerntet und ausgebeutet wird, unterscheidet er sich nicht von anderer Versklavung.
  • In einem Zoom-Interview habe ich etwas Ähnliches gemacht. Ich bekam eine schwierige LeetCode-hard-Aufgabe und steckte völlig fest; die Interviewer schienen auch nicht helfen zu wollen.
    Als ich sagte: „Ich glaube, heute ist nicht mein Tag, und ich möchte das Interview beenden“, bemühten sie sich danach ziemlich, mich für den Rest der Zeit zum Bleiben zu bewegen. Wenn ein Kandidat gehen möchte, sollte man ihn gehen lassen.

• Auch fünf Jahre später lehne ich solche Interviews ab und möchte diesen Prozess nie wieder durchlaufen. Ich wurde von Leuten schikaniert und verspottet, die Menschen wie ein einstündiges Trittspiel behandeln, und will mich damit nicht mehr abgeben.
  Weil es viele unangekündigte LeetCode-Interviews gab, habe ich auf meinem LinkedIn-[1]- und GitHub-[2]-Profil klar festgehalten, was akzeptabel ist und was nicht. „Ich habe eine persönliche Policy gegen jede Form von Live Coding oder Online-Coding-Tests während Interviews und genieße weder Competitive Programming noch nehme ich daran teil. Stattdessen bin ich gern bereit zu Offline-Coding-Aufgaben mit vernünftigen Zielen und Fristen sowie zu tiefgehenden technischen Diskussionen über Softwarearchitektur, Design und relevante Technologien.“
  [1] https://www.linkedin.com/in/mtodor
  [2] https://github.com/mihaitodor

  • Leute, die Entwickler suchen, könnten gemeinsam so etwas wie Nutzungsbedingungen erstellen. Das könnte HR dazu bringen, sie zur Kenntnis zu nehmen und die eigene Vorgehensweise zu überdenken.
  • Mir gefällt der Ansatz. Kannst du teilen, wie gut er in der Praxis funktioniert hat?
    Allerdings hört man, dass bei Take-Home-Aufgaben Betrug weit verbreitet ist; ich mache mir Sorgen, dass die Zahl der Arbeitgeber, die sie einsetzen wollen, stark zurückgehen könnte.

• Um mal den Advocatus Diaboli zu spielen: LeetCode wird bei der Einstellung durchschnittlicher Individual Contributors genutzt, um eines von zwei Dingen oder beides herauszufiltern. Ist die Person fleißig, also jemand, der viele Aufgaben übt, Lösungen auswendig lernt und reproduziert? Oder ist sie klug, also jemand, der auch ohne LeetCode die Grundlagen kennt und früheres Wissen synthetisieren kann, um neue Fragen zu beantworten?
  Wenn man sonst keine Informationen hat, ist jemand, der eine LeetCode-Aufgabe nicht besteht, meiner Ansicht nach mit höherer Wahrscheinlichkeit keines von beidem. Für eine Rolle, in der man programmieren muss, sollte man meiner Meinung nach zumindest eine leichte bis mittlere LeetCode-Aufgabe lösen können, notfalls mit etwas Richtungshilfe durch den Interviewer. In der Praxis gewichten Unternehmen LeetCode-Fähigkeiten umso geringer, je senioriger oder spezieller die Rolle ist, auf die man sich bewirbt. Es gibt auch Bugfixing, System Design, Behavioral Interviews, Take-Home-Aufgaben, Trivia-Fragen, hintergrundspezifische Fragen usw.; bei Einstellungen oberhalb des Einstiegslevels ist LeetCode nicht alles. Es ist kein magisches Werkzeug, um die besten Engineers auszuwählen, sondern nur ein weiteres Signal, das ein Hiring Committee nutzt.

  • Das ist eine Fähigkeit, die Studierende an vierjährigen Hochschulen etwa mit 19 lernen und dann in den folgenden 50 Jahren, in denen sie tatsächlich Dinge bauen, kaum noch einsetzen.
    Es erfasst nicht die Engineering-Fähigkeit, etwas innerhalb des Budgets bis zum Ende durchzuziehen. Im besten Fall ist es ein Nebenaspekt; im schlimmsten Fall ein Proxy für Altersdiskriminierung, der Menschen bevorzugt, die näher an 19 sind. Vielleicht tut sich diese Branche deshalb so schwer damit, hochwertige Software zu liefern. Eine bessere Methode wäre, einen Fehlschlag vorzugeben, etwa einen kaputten Build oder abstürzenden Code, und ihn beheben zu lassen. Wenn jemand ein System erkunden, einen Defekt diagnostizieren, die Ursache finden, einen Patch vorschlagen und sich an Coding- und Kommentarstil anpassen kann, ist das tatsächlich die Art von Spieler, die man braucht. Es könnte Branches und einen Issue-Tracker geben, vielleicht läuft bereits eine Diskussion über den Bug, oder in den Kommentaren liegt eine Patch-Datei, die man manuell anwenden muss. Der Patch könnte einen neuen Bug enthalten oder als Köder ein ähnliches, aber irrelevantes Problem berühren. Es könnte die Regression eines geschlossenen Bugs sein, für die es keine Unit Tests gibt; und selbst wenn es Tests gibt, muss der Kandidat sie vielleicht erst finden, oder die Tests selbst sind veraltet und voller Fehler. Das ist echte Arbeit. Am Ende zu sagen „Die Unit Tests waren kaputt“ oder „Ich habe nicht verstanden, wie man sie richtig ausführt, also habe ich sie übersprungen“ zeigt einen großen Unterschied in der Haltung, und der Teamplayer ist Letzterer.
  • Die meisten Bewerber haben bereits einen Job. Wenn jemand wirklich hart arbeitet, hat er neben seinem Hauptjob eher selten noch reichlich Energie, LeetCode-Aufgaben zu lösen.
    Umgekehrt kann man so Kandidaten bekommen, die in ihrer aktuellen Rolle keine herausragende Leistung bringen, aber ihre übrige Energie in LeetCode-Grinding gesteckt haben.
  • LeetCode-Aufgaben können per Definition realen Problemen nicht nahekommen, weil sie aus dem Kontext gerissen sind.
    Schon nach ein paar Wochen in einem Projekt kann eine kluge Person die Einsichten gewinnen, die tatsächlich nötig sind. Die unvermittelten Rätsel, die LeetCode stellt, ähneln eher den Kreuzworträtseln aus alten Zeitschriften.
  • Zu glauben, man könne sich im Interview allein aus Prinzipien den Dijkstra-Algorithmus herleiten, ist enorme Hybris.
    Der einzige Grund, warum man das kann, ist, dass man ihn vorher gelernt hat.
  • Es heißt, dass LeetCode mit zunehmender Seniorität weniger Gewicht bekommt — wann fängt das an? Ich habe über acht Jahre Erfahrung und bin es leid, gesagt zu bekommen, ich solle in 30 Minuten eine NxM-Bingo-Lösung bauen.
    2022 hätte ich zugestimmt, dass LeetCode kein Werkzeug ist, um die besten Engineers auszuwählen; 2024 wird man aber viel häufiger aussortiert, weil man die Aufgabe zwar richtig löst, aber nicht schnell genug ist oder sie nicht ohne Hinweis schafft. Ich bin kein LeetCode-Genie, habe ohnehin viel zu viel zu lernen, und LeetCode macht in Interviews etwa 20 % aus, aber ich habe nicht das Gefühl, dass es so viel schlimmer ist als vor zwei Jahren. Nur die Erwartungen der Unternehmen sind in den Himmel geschossen, und es herrscht eine Stimmung, Rollen mit mehr als 15 Jahren Erfahrung zum Gehalt von jemandem mit fünf Jahren Erfahrung einkaufen zu wollen.

• Ein interessanter Punkt, der bei LeetCode-artigen Interviews selten erwähnt wird, ist, dass sie eine Art intellektuelles Initiationsritual sind.
  Es wurde mehrfach gezeigt, dass die Hingabe der Menschen, die in eine Gruppe aufgenommen werden, stark steigt, je härter das Aufnahmeritual ist.

  • Das Problem ist, dass die Verlierer den Test nicht bestehen, die Gewinner aber schon.
    Wenn ein kapitalistisches Unternehmen Programmierer einstellt: Was ist besser, „kluge, ähnliche Menschen, die an richtige Antworten glauben“, oder „eine zufällig gemischte Gruppe erfahrener Leute“? Wenn deine Antwort Letzteres ist, bist du idealistisch, und solche Ansichten zählen in der Praxis nicht. Die Natur wird dich durch jemanden ersetzen, der klüger und realistischer ist.

• In den letzten paar Interviews habe ich den Kandidaten Beispielcode gezeigt und sie gebeten, ihn zu reviewen. In dem Beispiel steckt in jeder Zeile mindestens ein Bug oder ein Problem.
  Danach kommt eine Modellierungsaufgabe, meist am Whiteboard. Es gibt auch eine einfache Übung im Stil von fizzbuzz, um zu sehen, ob ein Junior wirklich eine Junior-Rolle ausfüllen kann, und sie dient als Aufhänger für Gespräche über Themen wie Laufzeitkomplexität oder Speicherlayout. Je nach Leistung des Kandidaten läuft das sehr interaktiv ab; Ziel ist es, Blender auszusortieren, die es irgendwie durch das Screening geschafft haben, und auch ein gewisses Gefühl für den Cultural Fit zu bekommen.

  • Ich gebe Kandidaten gern kaputte Unit Tests und lasse sie diese in einer für sie bequemen Umgebung mit ihren eigenen Tools innerhalb einer Stunde reparieren.
    Ich baue ein schmutziges Problem wie Zeitzonen oder Telefonnummernvalidierung und nehme einen Wikipedia-Artikel als Spezifikation. Am Ende frage ich nach der Lösung und mache ein Code Review. Die besten Seniors verwenden einfach eine Library. Gute Kandidaten bauen es selbst, können aber die Trade-offs erklären. Juniors bringen nur die Tests zum Laufen und hören dann auf.
  • Das hier nutze ich gern:
    https://github.com/emilybache/GildedRose-Refactoring-Kata
    Ich habe die Kandidaten es in ihrer bevorzugten Sprache machen lassen, und es war ein sehr effektiver Filter.

• Ich habe schon Entwicklerkandidaten interviewt, die theoretisch sehr viel zu wissen schienen, aber kläglich scheiterten, sobald sie Code schreiben sollten. Sie konnten nicht einmal fizzbuzz implementieren, und ein Senior-Java-Entwickler konnte ohne Nachschlagen HashMap nicht importieren.
  Es ist ähnlich wie in der Mathematik. Für 562 * 1041 ist es richtig, einen Taschenrechner zu benutzen, aber wenn jemand für 3 * 7 den Taschenrechner zückt, fragt man sich, ob er ein Experte ist. Viele Unternehmen übertreiben es mit LeetCode-Interviews, aber ein Live-Coding-Interview, in dem man Array-Manipulation, Ablaufsteuerung und die Nutzung grundlegender Datenstrukturen zeigt, macht sichtbar, ob es Muskelgedächtnis gibt, das nur aus Erfahrung kommt. Wenn man Graph-Traversal-Algorithmen lernen muss, um zu bestehen, ist es wahrscheinlich zu LeetCode-lastig.

  • Abzufragen, ob jemand den Paketnamen von HashMap auswendig kennt, ist der dümmste Java-Programmiertest, von dem ich je gehört habe.
  • HashMap nicht importieren zu können, ist für sich genommen ein lächerliches Kriterium. Ein Student, der gerade ein HashMap-Beispiel in Java gesehen hat, könnte sich den Import merken.
    Aber ein Programm braucht viele solcher Kleinigkeiten, und in dieser Weltanschauung muss man sie alle auswendig können. Bei 562 * 1041 erwartet man, dass man das Rechenprinzip kennt, also weiß, wie es geht. Man kann sich verrechnen, aber die Idee der schriftlichen Multiplikation darf nicht falsch sein. In diesem Kontext wäre es okay, wenn man einen Eintrag aus dem Einmaleins wie 3 * 7 vergessen hat. Programmierer organisieren Berechnungen, sie rechnen nicht selbst; das macht der Computer. Ich stimme zu, dass es bei Graph-Traversal-Algorithmen reicht zu wissen, wo man die Lösung findet, statt jede Lösung parat zu haben.
  • Eclipse erledigt die Imports für mich, ohne dass ich überhaupt hinsehen muss. IntelliJ genauso.
    In welcher Situation mussten diese Leute die Imports selbst schreiben? Hatten sie keine IDE?
  • Ist jemand, der nicht weiß, in welchem Namespace HashMap liegt, wirklich dasselbe wie jemand, der 3 * 7 nicht kann?
    Ich bin mir nicht sicher, ob das eine Satire auf die Vorurteile von Interviewern sein soll.