Warum Take-home-Aufgaben und Algorithmus-Interviews nicht mehr funktionieren

Bis 2024 haben wir so eingestellt, wie es die meisten Unternehmen noch immer tun. Ein Take-home oder ein Demo-Projekt, einige Coding-Fragen, ein Gespräch über das Gebaute. Das hat funktioniert, weil das Bauen selbst schwer war. Wenn jemand eine saubere, funktionierende Anwendung geliefert hat, bedeutete das etwas.

Schwer ist das nicht mehr. Die Folge ist rein mechanisch: Jede Take-home-Aufgabe, die wir in unseren letzten Einstellungsrunden erhielten, sah gleich aus, weil jede von einem Modell geschrieben war, und am Bildschirm sieht man den Unterschied nicht. Teams, die weiter darauf setzen, filtern faktisch nur nach Kandidaten, die bereit sind, einen Abend damit zu verbringen, einen Agenten zu beaufsichtigen.

LeetCode-artige Tests haben das entgegengesetzte Problem. Sie messen etwas Reales, aber was sie messen, ist Mustererinnerung unter Zeitdruck, und das war selbst vor der Veränderung durch die Werkzeuge kein guter Prädiktor für Senior-Arbeit. Man erfährt nicht, wie ein erfahrener Entwickler mit einer Schema-Änderung umgeht, wenn man ihm dabei zusieht, einen binären Baum zu invertieren. Schlimmer noch: Die Fähigkeit zur Mustererinnerung, die solche Tests belohnen, ist genau die Arbeit, die Agenten übernommen haben. Man würde am stärksten nach der Fähigkeit selektieren, die am wenigsten zählt.

Was nicht mehr funktioniert, in einem Satz: Einstellungsprozesse wurden darauf ausgelegt, Ergebnisse zu bewerten, und Ergebnisse haben aufgehört, Informationen über die Person zu transportieren. Weder das eine noch das andere Format zeigt noch die grundlegenden Fähigkeiten, und keines davon zeigt die Agent-Kenntnisse. Deshalb haben wir beides ersetzt durch zwei praktische Arbeitssitzungen in einer echten Codebasis: eine ohne Agents und eine mit, bei der wir beobachten, wie Menschen tatsächlich arbeiten.

Keine der beiden Sitzungen steht für sich allein. Sie sind die dritte und vierte Stufe eines längeren Prozesses: CV-Screening anhand eines Bewertungsrasters und ein dreißigminütiges Erstgespräch gehen ihnen voraus, ein Kulturinterview und Referenzgespräche folgen danach, denn wenn der Großteil des Codes von Agenten geschrieben wird, sind die Art, wie jemand Kontext teilt und mit dem Team zusammenarbeitet, mindestens ebenso wichtig wie die fachlichen Fähigkeiten.

Die erste Sitzung prüft die Grundlagen, ohne KI. Der Kandidat erhält eine Codebase, die er noch nicht kennt, eine Handvoll echter Tickets, darunter einen Produktionsfehler, und sechzig Minuten Zeit. Es handelt sich um eine normale Arbeitssitzung, keinen Test: Die Tickets werden aufgenommen und bearbeitet, wir beobachten. Code zu schreiben ist einfach geworden, aber zu verstehen, wie ein System zusammenhängt, nicht, und wer die Grundlagen nicht beherrscht, hat keinen Maßstab, um die Ausgabe eines Agenten zu bewerten. Was gute Arbeit bedeutet, ist konkret: den Datenfluss und mögliche Fehlerzustände lesen, bevor man Code anfasst; den Produktionsfehler priorisieren und benennen können, was er betrifft; die Ursache finden statt das Symptom; den Test hinzufügen, der den Fehler abgefangen hätte. Diese Runde deckt Kandidaten auf, die ein LLM über einige Jahre Remote-Arbeit lediglich weitergereicht haben, was häufiger vorkommt, als die Branche zugeben möchte. Hier stellen wir außerdem fest, ob jemand das Design eines Systems flüssig auf Englisch erläutern kann, was wir strenger prüfen als die meisten.

Die zweite Sitzung hat dieselbe Grundstruktur wie die erste, jedoch mit der umgekehrten Rahmenbedingung: ein neues Set an Tickets und welche KI-gestützten Coding-Tools der Kandidat normalerweise verwenden würde. Jetzt beobachten wir, was er tut, wenn ein Agent den Großteil der Arbeit übernimmt, bewertet anhand von sechs Kriterien: ob er überprüft, was der Agent produziert; wie er die Tools orchestriert; ob er die Arbeit in Teilschritte aufteilt, bevor er Code generiert; wie er Prompt und Kontext aufbaut; wie er debuggt; und ob er den Überblick über alles behält, was er angestoßen hat. Ob er zuerst plant, ob er liest, was zurückkommt, und ob er eine Änderung erklären kann, die er nicht selbst getippt hat.

Diese zweite Sitzung war es, an der ein kürzlich geprüfter Kandidat mit dreizehn Jahren Erfahrung scheiterte. Sein Lebenslauf sah gut aus, und die Grundlagen-Sitzung verlief problemlos. Dann durfte er Agents verwenden, und von diesem Moment an hörte er auf zu lesen. Jede Änderung wurde akzeptiert, jeder Prompt mit „Weiter so“ bestätigt, und er schloss Tickets, ohne auch nur eines davon zu prüfen. Die meisten Unternehmen hätten ihn eingestellt. Wir auch, vor zwei Jahren, denn die meisten Prozesse sehen niemals die eine Stunde, die wir gesehen haben. Wenn Sie heute noch nach Take-Home-Aufgaben und Coding-Tests filtern, besteht er Ihre Interviews gerade jetzt, und Sie werden es merken, wenn sein Code ins Review kommt.

Wenn Sie Ihren eigenen Prozess neu gestalten, ist die Zwei-Sitzungen-Struktur das eigentlich Übertragbare, mehr als eine bestimmte Aufgabe. Grundlagen ohne den Agenten, weil sie die Voraussetzung für jede Überprüfung sind. Echte Arbeit mit dem Agenten, weil das die eigentliche Tätigkeit ist. Die Aspekte des Einstellungsprozesses, bei denen es nie um das Artefakt ging, das Screening, das Gespräch über Unternehmenskultur, die Referenzen, behalten ihre ursprüngliche Bedeutung; wenn überhaupt, ist die Referenzprüfung heute noch wichtiger.

Und wenn Sie einen Anbieter statt eines Kandidaten bewerten, gilt dieselbe Logik, mit einer Ergänzung: Bitten Sie darum, den Prozess zu sehen. Jedes Unternehmen, das Engineers vermittelt, sollte Ihnen zeigen können, was getestet wird, wie es bewertet wird und warum Kandidaten scheitern. Wir veröffentlichen unseren Prozess vollständig. Ein Auswahlverfahren, das einer Veröffentlichung nicht standhält, hat die falschen Dinge gemessen.

Den vollständigen Prozess mit beiden Scorecards und Beispielen für gute und schlechte Ergebnisse in jeder Sitzung finden Sie in The Next 10X Engineer. Wenn Sie erfahren möchten, wie Ihr aktueller Einstellungsprozess im Vergleich zu dem anderer Führungskräfte abschneidet, ist der Engineering Leader Benchmark offen.