Entwickler interviewen, wenn die KI den Code schreibt

CTOs und Engineering Manager interviewen jeden Tag immer noch Entwickler, daran hat sich in den letzten 20 Jahren nichts geändert. Aber das Interview, das CTOs heute führen sollten, sieht nicht mehr aus wie das, das ich zwanzig Jahre lang geführt habe. Denn in den meisten Firmen, mit denen ich arbeite, schreibt die KI bereits den größten Teil des Codes. In einigen den ganzen Code, und das, was Engineering Manager früher im Interview wissen wollten, ist heute nicht mehr relevant.

Zwei Jahrzehnte lang bewegte sich der Interview-Prozess praktisch kaum - von einigen Fashion Trends abgesehen (“Was macht Google? Was macht Google?”) Man hat einen Kandidaten eingeladen, ihm das Internet weggenommen und zugesehen, wie er ein Rätsel oder ein Problem am Whiteboard löst - eine verkettete Liste umdrehen, einen Baum balancieren, Duplikate in nur einem Durchlauf finden - oder eine Suchmaschine, einen E-Commerce-Shop entwerfen oder deine Infrastruktur skalieren. Du hast ihn auch Code schreiben lassen - und manchmal hast du ihn Code lesen und erklären lassen (super!). Was du gemessen hast - im Kern - war, wie viele korrekte Zeilen Code er pro Stunde aus seinem eigenen Kopf ziehen konnte - wirklich (abhängig natürlich von der Definition von korrekt). Man wollte Coder, also hat man danach interviewed (glaubst du mir nicht, frag den CEO, was er denkt, was der Job eines Entwicklers ist (war (sieht jetzt aus wie LISP))).

Die AI Ubernimmt jetzt aber das Coding. Sie schreibt korrekten (ja, das tut sie wirklich) Code schneller als jeder Kandidat, sie erinnert sich an jedes Framework und jeden Standard-Library-Aufruf (mit Recherche sind Halluzinationen heute kein Problem mehr), und sie grübelt nie über den Syntax für eine Closure - und wenn doch, fixt sie den Syntax gewissenhaft, bis alles läuft. Und das 24/7. Darauf zu screenen heißt, auf etwas zu screenen, das Entwickler nicht mehr machen - wozu also?

Was die alte Latte gemessen hat

Was die Leute in einem Interview gefragt haben, unterschied sich: LeetCode, Syntax-Verständnis, Programmiersprachen-Edge-Cases, Framework-Trivia, die Geschwindigkeit, mit der man Boilerplate auf den Bildschirm bekommt - oder einen String-Reverser schreiben. Auch ich habe diese Art von Interviews lange geführt, jahrelang, und ich habe die ganze Zeit das Falsche gemessen (zum Glück habe ich meine Interviews schon vor einem Jahrzehnt umgestellt, um nach Motivation, Business-Verständnis und Ownership zu suchen).

Das Signal, das zeigte, wer nützlich sein würde - kann diese Person eine Codebase öffnen, die sie nicht geschrieben hat, sie im Kopf jonglieren und sie ändern, ohne drei andere Dinge dabei kaputtzumachen - war das, wonach Hiring Manager Ausschau gehalten haben.

Wen ich stattdessen einstelle

Was die KI nun ändert, ist, wie viel ein einzelner Entwickler ownen kann. Wenn das Tippen nicht mehr das Bottleneck ist und Skills (PM, Coding) nicht mehr ein begrenzender Faktor sind, kann ein einzelner Entwickler eine Idee von „ein Kunde hat sich über X beschwert" bis zu einem Feature in Production bringen, ohne mehrere Handoffs (Sales, PM, Entwickler, QA) und drei weitere Leute dazwischen. Die Entwickler, die das gut machen, nennen viele in unserer Branche inzwischen Product Engineers, und Product Engineers sind genau die, die ich heute einstellen würde.

Ein Product Engineer owned das komplette Ergebnis, von einer Idee über ein Kunden-Need bis zum Feature, das dann in Production läuft. Er kann sich zu einem Kunden setzen und herausfinden, was der Kunde braucht (siehe wie der Kunde arbeitet, “Job to be done”) im Gegensatz zu dem, was der Kunde will (die beiden Dinge sind selten dasselbe aus meiner Erfahrung). Er steuert eine AI auf die Arbeit aus, so wie ein Senior früher vier Juniors in einem Daily daraufhin gesteuert hat, und er behält das Urteil darüber, was es wert ist, gebaut zu werden, und ob das, was die AI gebaut hat, irgendetwas taugt. Das Coding war nie der Teil, auf den es ankam. Das Entscheiden was das Richtige ist, war es. Bau die richtigen Dinge!

Jeder ist jetzt Manager. Jeder Entwickler ist nun auch ein Manager von einem Team von KIs. Mit den gleichen Problemen von Accountability, Delegation und Vertrauen. Womit Manager in ihren Jobs gekämpft haben, ist jetzt dasselbe, womit Entwickler kämpfen, wenn sie mit einem Team aus KIs arbeiten. Stell Leute mit dieser Erkenntnis im Kopf ein.

Das ist der Shift, über den ich in Creators und Coders geschrieben habe: die Person mit Intent und Geschmack, mit einer KI im Rücken, kommt weiter als die Person, die nur ein Ticket, das ihr jemand hingelegt hat, in Quellcode übersetzen kann. KI schrumpft die Lücke zwischen der Idee und der laufenden Software auf fast nichts, und sobald diese Lücke weg ist, owned eine Person das Kundenbedürfnis und das Release, wo es früher drei Abteilungen und eine Warteschlange aus Tickets brauchte.

Was heute eine Einstellung verdient

Worauf muss man dann heute achten? Taste und Urteilsvermögen, vor allem anderen Dingen sind es was mit AIs zählt. Können die Kandidtaten sich drei Wege ansehen, ein Problem zu lösen, und den auswählen, der in einem Jahr der Firma nicht auf die Füsse fällt und zur Business Strategie passt. Kreativität - können die Kandidaten ein Produkt entwickeln, das es wert ist, gebaut zu werden, denn das Bottleneck steckt jetzt auf der Seite der Ideen-Generierung. Ob sie eine KI steuern können: wissen sie, wonach sie fragen müssen, wie sie erkennen, wann die Antwort falsch ist, und wie sie die KI wieder auf den richtigen Weg bringen?

Verifizieren sie, was die KI zurückgibt? - das ist Responsible Engineering. Entwickler, die Code auf Production schieben, ohne zu den Code verifizieren, richten jetzt mehr Schaden an, als es der langsamste Entwickler je tat. Verantwortungsvolles Engineering hieß früher, alle Tests zu schreiben. Jetzt heißt es aber auch, eine KI zu nutzen, um Bugs zu finden und zu verhindern, zu prüfen, was die KI geschrieben hat, Sicherheitslücken zu suchen, und zur die Requirements nehmen, um zu sehen, ob der geschriebene Code das Problem löst, das gelöst werden sollte (zurück zum Ticket, zur Spec, zur Anforderung oder zur Idee).

Produktgespür, Geschäftsverständnis (das für Seniors immer wichtig war, um die richtigen Tradeoffs zu treffen, aber selten interviewt wurde), und das eine, das sich nicht geändert hat: Ownership, auch wenn niemand hinsieht. Es ist nun schwerer, alles zu faken, denn wenn du das Ergebnis verantwortest, kann sich keiner mehr hinter dem Team verstecken, Also erkennst du wenigstens deine Mishirings früher als zuvor.

Was ich nicht mehr teste

Algorithmus-Rätsel und ob die Kandidaten ein Framework in- und auswendig kennen, runter bis zur jeder Methodensignatur und allen Edge-Cases braucht man heute nicht mehr. Welche Programmierprachen auf dem Lebenslauf stehen: Programmiersprachen interessieren mich nicht mehr, dich sollten sie auch nicht interessieren. Mit Claude sollte ein Senior-Entwickler auf einer Codebase sofort loslegen können - in jeder Sprache, auch der, die er nie verwendet hat - die KI ist in allen Sprachen top (am besten natürlich in Go ;-), und mit der KI ist es der Kandidat auch.

Wie das Interview jetzt läuft

Gib dem Kandidaten einfach Claude. Kämpf nicht gegen die KI, versuch nicht, sie aus dem Interview herauszuhalten. Setz den Kandidaten mit den Tools hin, die er im Job nutzen würde, gib ihm etwas Komplexes aus deiner eigenen Codebase und sieh zu, wie er arbeitet.

Zuzusehen, wie er arbeitet, entscheidet ob du ihn einstellst. Drückt er nur Tab für Autocomplete, oder promptet er mit Intent. Weiß sie, wie sie die KI aus Doom-Loops heraushält? Weiß sie, wo KIs Schwierigkeiten haben, und promptet entsprechend? Stellt sie DIR die richtigen Fragen darüber, was gebaut werden soll? Ergibt ihr Prompting Sinn? Wenn die KI zweihundert Zeilen zurückgibt, liest sie diese oder shippt sie diese einfach? Lässt sie die KI erklären was passiert, verifiziert sie das Ergebis der KI mit der KI? Lässt sie die KI nach Bugs und Sicherheitsproblemen suchen, nach unausgewogener Architektur und inkonsistenten Domain-Klassen? Denkt sie an den Edge-Case, an den Case, den das Ticket vergessen hat zu erwähnen. Erwischt sie die KI dabei, wie sie das Falsche tut, und bringt sie die KI wieder on Track? Kann sie Tokens sparen? Kennt sie die Unterschiede zwischen Frontier-Modellen? Open Source Modellen? Nutzt sie bereits Lokal-AI?

Urteilsvermögen, such nach den Instinkt, das richtige Produkt zu bauen, auf verantwortungsvolles Engineering, auf Kandidaten, die Ownership übernehmen, und auf die, die motiviert sind. Größtenteils das, was du immer schon wolltest, aber nocht nicht wusstest, dass du es willst.

Wenn du deine Entwickler dahin bekommen willst, bring die KI zu ihnen, bevor dein CEO wütend wird, weil sich die Firma nicht schnell genug bewegt.

Was das für Berufseinsteiger bedeutet, steht in Die Zukunft des Juniors. Und warum “auf Augenhöhe” mit deinem Team eine Illusion ist, die dir das Führen schwerer macht: Augenhöhe.