Wir haben unseren Bewerbungsstandard veröffentlicht. Beide Assessments, beide Scorecards, wie gut aussieht, wie schlecht aussieht: alles davon, offen zugänglich. Bevor Sie es lesen, erläutern wir hier das Denken hinter den sechs Kriterien, die wir bewerten, wenn der Kandidat einen Agenten geöffnet hat, und warum die Session so aufgebaut ist, wie sie ist.
Das AI-native Assessment ist die zweite von zwei praktischen Sitzungen in einer realen Codebasis. Wenn ein Kandidat sie erreicht, hat er bereits eine Grundlagen-Sitzung in einer Codebasis bestanden, die er noch nie gesehen hat, mit echten Tickets und ohne KI-Tools. Denn wer ein System nicht ohne den Agent durchdenken kann, erkennt auch nicht, wenn der Agent falsch liegt. Dann beginnt die zweite Sitzung: ein neues Set an Tickets und welche KI-gestützten Coding-Tools der Kandidat normalerweise verwenden würde. Ein Agent übernimmt den Großteil der Produktion, und wir beobachten, was der Mensch tatsächlich beisteuert.
Das erste Kriterium ist die Überprüfung von KI-Output. Gut sieht so aus: halluzinierte APIs, subtil fehlerhafte Logik oder Sicherheitslücken im generierten Code werden erkannt, bevor er ausgeliefert wird. Schlecht sieht so aus: dem Output zu vertrauen, weil er kompiliert. Das Scheitern hat eine Qualität, die man innerhalb weniger Minuten zu erkennen lernt: Der Kandidat hört auf, ein Engineer zu sein, und wird zum Durchlauferhitzer zwischen dem Modell und der Codebasis. Jede Änderung akzeptiert, jeder Prompt mit „Weiter so“ beantwortet, Tickets geschlossen ohne einen davon zu prüfen. Genau so fiel der Entwickler mit dreizehn Jahren Erfahrung aus der Einleitung auseinander, und das ist für jeden Prozess unsichtbar, der nur auf das schaut, was er geliefert hat, denn was er geliefert hat, kompilierte.
Der zweite Bereich ist die Orchestrierung von Tools, und genau hier liegt der Multiplikatoreffekt. Gut bedeutet: zu wissen, wann man Aufgaben an den Agenten übergibt, das Scaffolding, den Boilerplate-Code, die Tests, und wann man die neue Logik und die schwierigen Sonderfälle selbst schreibt; beides läuft dann parallel in Worktrees, damit sich Agenten nicht gegenseitig blockieren. Schlecht bedeutet: ein einziges Fenster für alles, oder das genaue Gegenteil davon: Dinge aus Stolz manuell zu schreiben, die ein Agent besser erledigt. Kaum ein Einstellungsprozess testet das, was bemerkenswert ist, denn genau das ist der Unterschied zwischen einem Engineer und der mehrfach schnelleren Version desselben Engineers.
Die verbleibenden vier vervollständigen das Bild. Spezifikationsgetriebene Entwicklung: Ein vages Ticket in Teilaufgaben zerlegen, die klein genug sind, damit das Tool sie zuverlässig ausführen kann, anstatt die gesamte mehrdeutige Anforderung auf einmal hineinzuwerfen. Prompt- und Kontext-Engineering: Die Aufgabe so aufbereiten, dass das Tool in ein oder zwei Durchläufen brauchbare Ergebnisse liefert, anstatt dieselbe vage Anfrage in einer Schleife erneut einzugeben. KI-beschleunigtes Debugging: Den Agenten für die Ursachenanalyse, die Log-Auswertung und Stack-Traces einsetzen, ohne den Schritt zu überspringen, den Fehler selbst zu reproduzieren und zu verstehen. Und Context-Switch-Hygiene: Den Überblick behalten, was jeder Agent gerade tut, zum richtigen zurückzukehren und sich das Wechseln nicht von Benachrichtigungen diktieren zu lassen. Dieser letzte Punkt wird in beiden Sitzungen bewertet, weil er den Engineer betrifft und nicht die Tools, und er ist der entscheidende Faktor dafür, ob Orchestrierung ein Multiplikator ist oder einfach mehrere Dinge, die gleichzeitig falsch laufen.
Das Paper sagt klar, dass die scorecard nicht das ganze Bild zeigt. Drei Dinge zählen genauso viel und passen nicht auf eine Karte. Deshalb achten wir in beiden Assessments darauf. Urteilsvermögen nach Risiko: Eine Textänderung, ein risikoarmes Refactoring und eine Zahlungsmigration verdienen nicht dasselbe Review. Mit Agenten wird das wichtiger, weil das Tool alle drei gleich schnell und gleich selbstsicher liefert. Verantwortung: Wer mergt, trägt die Verantwortung. „Der Agent hat es gemacht“ akzeptieren wir im Assessment nicht, und Ihr Team akzeptiert es im Incident Review auch nicht. Vorarbeit für andere: Die besten Engineers schließen das Ticket ab und hinterlassen das Repo so, dass der nächste Agent besser damit arbeiten kann. Das kann ein wiederverwendbarer Befehl sein, eine präzisere Kontextdatei oder ein Test, der die ganze Fehlerklasse abfängt statt nur den Einzelfall.
Warum veröffentlichen wir alles, auch die Bewertung? Dafür gibt es drei Gründe. Erstens braucht die Branche einen Bezugspunkt. „Wir prüfen auf AI-Kompetenz“ sagt heute so wenig aus wie „Senior“ im Lebenslauf, und ein veröffentlichter Standard lässt sich schwerer imitieren als eine Behauptung. Zweitens haben Kandidaten ein Recht darauf zu wissen, worauf sie sich einlassen. Die Engineers, die wir suchen, lesen den Standard und denken: „Endlich testet jemand die tatsächliche Arbeit.“ Drittens können wir es uns leisten. Unser Vorsprung liegt woanders als in den Scorecards: Die Leute, die die Sessions leiten, bauen jeden Tag Produktionssoftware mit diesen Tools. Nur so erkennt man, wie eine falsche Antwort aussieht. Ein Personaldienstleister könnte unser Raster morgen kopieren und könnte es trotzdem nicht bewerten.
Die Veröffentlichung hat auch einen Nutzen für Auftraggeber, und wir meinen das als Einladung, nicht als Kritik. Wenn Sie jemandem für Engineers zahlen, messen Sie deren Auswahlverfahren an einem veröffentlichten Standard, unserem oder einem besseren. Fragen Sie, was getestet wird, wie bewertet wird, woran Kandidaten scheitern. Die Firmen, die das sorgfältig machen, antworten ausführlich und stellen die Frage wahrscheinlich gern. Die anderen schicken Ihnen eine Folie über ihren Talentpool.
Das Whitepaper führt durch beide Sitzungen mit den Scorecards, die wir dabei ausfüllen. Wenn Sie nur ein Kapitel lesen, lesen Sie das zur AI-native-Bewertung. Dort verbirgt sich die nächste Fehleinstellung.
Den Standard finden Sie unter Unser Auswahlverfahren. Laden Sie The Next 10X Engineer herunter.
