Was wir ohne KI-Tools bewerten

Die unkonventionellste Stunde in unserem Einstellungsprozess kommt ganz ohne KI aus. Eine Codebasis, die der Kandidat noch nie gesehen hat, eine Handvoll echter Tickets, darunter ein Produktionsfehler, sechzig Minuten mit einem Tech Lead – und keine Agents erlaubt. Kandidaten sind davon regelmäßig überrascht. Einige haben gefragt, ob wir nicht mit der Zeit gehen.

Das Gegenteil ist der Fall. Die Fundamentals-Session existiert gerade wegen der Agents, nicht trotz ihnen.

Die Begründung lautet, und auf diesem Satz beruht das gesamte Whitepaper: Wer ohne den Agent nicht über das System nachdenken kann, erkennt auch nicht, wenn der Agent falsch liegt. Bei unseren Projekten werden 80 bis 90 Prozent des Produktionscodes von einem Modell geschrieben. Das bedeutet, dass der eigentliche Beitrag eines Entwicklers in allem liegt, was um die Generierung herum stattfindet: zu wissen, was man anfordert, das Ergebnis zu lesen und den selbstsicheren Fehler zu erkennen. All das beruht auf Grundlagenwissen. Code zu schreiben ist einfach geworden; zu verstehen, wie ein System zusammenhängt, nicht. Deshalb nehmen wir den Agent weg, bevor wir jemandem beim Arbeiten mit einem Agent zusehen, um zu sehen, was übrig bleibt.

Die Session ist bewusst unspektakulär. Keine Rätsel, kein Whiteboard, keine binären Bäume. Der Kandidat nimmt die Tickets entgegen und legt los, und wir beobachten die Arbeitsweise, dabei bewerten wir sechs Dinge.

Technisches Verständnis steht an erster Stelle und zeigt sich am schnellsten: Tiefe im Stack, in den komplexen Abläufen der Anwendung und im Terminal. Die stärksten Kandidaten starten die Anwendung und untersuchen die Codebasis, bevor sie irgendetwas ändern. Die schwächsten starten die Anwendung überhaupt nicht, was unmöglich klingt, bis man es erlebt hat, und bearbeiten Code, den sie nicht gelesen haben.

Debugging geschieht anhand des Produktionsfehlers. Gut sieht so aus: strukturiert vom Symptom zur Ursache vorzugehen und die Lösung zu testen, bevor man sie für fertig erklärt. Schlecht sieht so aus: Trial and Error, bis kein Fehler mehr erscheint, dann das Ticket schnell schließen und das Problem ungelöst lassen. Dieser Punkt überträgt sich direkt auf die Agent-Ära, denn generierten Code zu debuggen, den man selbst nicht geschrieben hat, ist heute ein Großteil der Arbeit.

Priorisierung ist ein stilles Diagnosemittel. Die Tickets haben eine angegebene Dringlichkeit, und der Produktionsfehler kommt immer zuerst. Ein Entwickler, der das interessante Ticket vor dem dringenden bearbeitet, zeigt Ihnen damit, wie er sich auf Ihrer Roadmap verhalten wird.

Kommunikation wird daran gemessen, ob Kandidaten Abwägungen erläutern und sagen, was sie nicht geschafft haben, anstatt zu schweigen, und ob sie bei einem unklaren Ticket nachfragen, statt zu raten. Zu schweigen, wenn man nicht weiterkommt, ist eines der eindeutigsten negativen Signale, die wir kennen. Das Englischniveau ist ein weiterer Punkt: verständlich und verständnisvoll, mündlich wie schriftlich, ausreichend, um unter einer Rückfrage eine Position zu vertreten, statt nur eine vorgefertigte Antwort zu wiederholen. Wenn der Großteil des Codes von Agents geschrieben wird, ist die Art, wie jemand Kontext weitergibt, mindestens ebenso wichtig wie die fachliche Kompetenz. Deshalb folgen auf die technischen Sessions ein Culture-Interview und eine Referenzprüfung.

Und schließlich Task-Tracking-Disziplin: den Überblick darüber behalten, welche Tickets offen sind und wo jedes steht, eine Aufgabe wieder aufnehmen, ohne alles neu lesen zu müssen. Diesen Punkt bewerten wir erneut in der zweiten Session mit laufenden Agents, denn er betrifft den Entwickler, nicht die Werkzeuge, vier Agents mit schlechtem Task-Tracking zu orchestrieren, erzeugt schlicht vier unkoordinierte Workstreams statt einem.

Achten Sie darauf, was diese Scorecard wirklich misst. Nichts darin ist neu. Jeder Punkt hätte einen guten Engineer auch im Jahr 2015 beschrieben. Was sich geändert hat, ist der Zweck dieser Punkte: Früher waren sie die Arbeit selbst, heute sind sie die Voraussetzung dafür, das, was die Überprüfung von Agentenausgaben durch einen Engineer überhaupt aussagekräftig macht. Deshalb kommt die Grundlagensitzung vor der AI-native-Sitzung, und deshalb beendet ein Scheitern daran den gesamten Prozess. Für die zweite Sitzung bliebe dann nichts mehr zu messen.

Damit schließen sechs Wochen des Publizierens rund um The Next 10X Engineer ab: was die Stelle heute bedeutet, was AI-native heißt, warum die alten Filter versagt haben, der AI-native-Scorecard und nun die zugrundeliegenden Grundlagen. Das Paper enthält beide Sessions und beide Scorecards vollständig, und der Bewerbungsstandard ist öffentlich.

Daher abschließend eine Frage im Sinne der Eröffnungsfrage. Ihr Bewerbungsprozess prüft mit großer Wahrscheinlichkeit nach wie vor Grundlagenkenntnisse. Aber wenn am ersten Arbeitstag ein Agent neben Ihrer letzten Einstellung säße, hätte Ihr Prozess Ihnen verraten, ob diese Person seine Arbeit überprüfen kann, oder nur, ob sie die Arbeit selbst hätte erledigen können, so wie im Jahr 2021?

Laden Sie The Next 10X Engineer herunter, um beide Assessments und beide Scorecards zu erhalten. Der Engineering Leader Benchmark ist offen, und Beitragende erhalten den Bericht zuerst.