LeetCode ist obsolet: So führen Sie Ingenieur-Interviews im KI-Zeitalter

Das algorithmische Coding-Interview ist ein Relikt. Wenn Claude 3.7 Sonnet, GPT-4.5 und DeepSeek V3 “Hard”-LeetCode-Aufgaben in unter einer Sekunde lösen, misst die gleiche Prüfung bei Menschen nichts außer Auswendiglernen und Angsttoleranz. Eine Studie von 2020 der North Carolina State University und Microsoft, veröffentlicht im Journal of Systems and Software, bestätigte, was die meisten Ingenieure bereits vermuteten: Technische Interviews testen in erster Linie, ob ein Kandidat unter Prüfungsangst leidet, nicht ob er Software bauen kann. Der Engpass in der Softwareentwicklung hat sich verschoben: weg vom Schreiben von Code, hin zur Steuerung der Maschinen, die ihn schreiben. Ihr Interviewprozess muss sich entsprechend anpassen.

Warum algorithmische Interviews nicht mehr funktionieren

Die Grundannahme hinter LeetCode-Interviews war einfach: Wer komplexe Syntax im Arbeitsgedächtnis halten und unter Druck abrufen kann, ist vermutlich ein starker Ingenieur. Diese Annahme brach zusammen, als KI genau die Fähigkeiten zur Massenware machte, die diese Tests messen.

Betrachten Sie die Kluft zwischen Maschinen und Menschen bei den Aufgaben, die Whiteboard-Interviews bewerten:

Googles eigene interne Forschung ergab, dass Brainteaser- und Puzzle-Interviews praktisch keine Korrelation mit langfristiger Arbeitsleistung aufweisen. Diese Tests messen zwei Dinge: das reine Auswendiglernen algorithmischer Muster und die psychologische Fähigkeit, unter künstlichem Stress zu funktionieren. Keines von beidem sagt voraus, wie jemand ein verteiltes System entwerfen, einen subtilen Bug in einem Code-Review entdecken oder einem selbstbewusst falschen KI-generierten Pull Request widersprechen wird.

Das Imposter-Syndrom-Paradoxon

Daten zur Kandidatenerfahrung zeigen, dass 93 % der Bewerber unter schwerer interviewbezogener Angst leiden. Das verzerrt Bewertungsergebnisse und unterdrückt kognitive Leistungsfähigkeit. Aber die Verzerrung ist nicht gleichmäßig verteilt.

Senior-Ingenieure mit tiefem architektonischem Wissen und kritischem Selbstbewusstsein schneiden in Whiteboard-Settings oft schlechter ab. Sie sind sich der Randfälle, Produktionsbeschränkungen und der Kluft zwischen Lehrbuchlösungen und realen Systemen sehr bewusst. Dieses Bewusstsein verlangsamt sie unter künstlichem Zeitdruck.

Gleichzeitig gedeihen Kandidaten, die Hunderte Stunden mit LeetCode-Training verbracht haben, ohne jemals Produktionscode auszuliefern, in dieser theatralischen Umgebung. Das Interview selektiert nach Vorbereitungszeit, nicht nach Ingenieurkompetenz.

Verstärkt wird dies durch sozioökonomische Verzerrung. Forschung zu algorithmischer Voreingenommenheit im Recruiting zeigt, dass Puzzle-Interviews eine “algorithmische Monokultur” schaffen und systematisch Kandidaten mit der meisten verfügbaren Zeit zum Üben bevorzugen. Berufstätige Eltern, Quereinsteiger und Ingenieure mit nicht-traditionellem Hintergrund werden herausgefiltert, bevor ihre tatsächlichen Fähigkeiten jemals bewertet werden.

Was KI an der Ingenieurproduktivität verändert hat

Der Abschied vom algorithmischen Interview ist keine ideologische Entscheidung. Er wird durch eine messbare Transformation in der Art und Weise getrieben, wie Software gebaut wird.

Ein kontrolliertes Experiment mit GitHub Copilot ergab, dass Entwickler eine HTTP-Server-Aufgabe 55,8 % schneller mit KI-Unterstützung abschlossen. Weitere Umfragen zeigen, dass 73 % der Entwickler einen tieferen kognitiven Flow aufrechterhalten, wenn sie KI-Tools nutzen, und 87 % berichten von besserer mentaler Ausdauer, weil KI sich um repetitiven Boilerplate-Code kümmert.

Wenn KI Basiscode schneller und sauberer generiert als die meisten Menschen, ändert sich die Definition eines produktiven Ingenieurs grundlegend. Der Engpass ist nicht mehr die Übersetzung von Logik in Syntax. Der Engpass liegt in allem rund um den Code:

• Systemarchitektur: Entwurf fehlertoleranter verteilter Systeme, die exponentielles Wachstum bewältigen
• Urteilsvermögen im Code-Review: Erkennen, wenn KI-generierter Code subtil, aber katastrophal fehlerhaft ist
• Denken in Fehlermodi: Antizipieren von Kaskadenausfällen, Retry-Stürmen, Race Conditions und Randfällen, die KI nicht vorhersehen kann
• Technische Kommunikation: Vermittlung architektonischer Kompromisse an nicht-technische Stakeholder und Mentoring von Junior-Ingenieuren

Die Fähigkeit eines Kandidaten, einen Binärbaum aus dem Gedächtnis zu invertieren, sagt nichts darüber aus, ob er eine verteilte Datenbank absichern, eine idempotente Queue entwerfen oder einen selbstbewusst falschen Pull Request eines KI-Assistenten ablehnen kann.

Das Problem der kognitiven Abdankung

Es gibt eine reale Gefahr im KI-gestützten Workflow. Kognitive Auslagerung (KI die Routineaufgaben überlassen) kann in ungeprüfte Delegation abgleiten, die schließlich zu einer vollständigen Abdankung der Ingenieurverantwortung wird.

Folgendes Szenario spielt sich 2026 täglich ab: Ein Ingenieur bittet einen KI-Assistenten, eine Datenbankmigration zu implementieren. Der generierte Code sieht sauber aus, besteht eine oberflächliche Prüfung und wird gemergt. Drei Wochen später stellt das Team fest, dass die Migration einen nicht-indizierten Fremdschlüssel eingeführt hat, der die Query-Performance im Betrieb um den Faktor 100 verschlechtert. Die KI war “selbstbewusst falsch”, und niemand hat es bemerkt, weil niemand die Ausgabe gegen das tatsächliche Schema geprüft hat.

LLMs sind probabilistische Systeme. Sie halluzinieren nicht existierende APIs, referenzieren veraltete Methoden und produzieren strukturell unsaubere Logik, verpackt in perfekt formatiertem Code. Ihr Interviewprozess muss testen, ob ein Kandidat maschineller Ausgabe blind vertraut oder ob er das Grundlagenwissen besitzt, sie zu prüfen, zu korrigieren und sicher auszuliefern. Das alte Interview hat keines von beidem getestet.

Das Vier-Säulen-Framework für Interviews nach der KI-Wende

Das Whiteboard zu ersetzen erfordert mehr als es einfach zu entfernen. Sie brauchen ein strukturiertes Framework, das misst, was tatsächlich die Arbeitsleistung im Jahr 2026 vorhersagt. Schmidt und Hunters wegweisende Meta-Analyse von 85 Jahren Personalauswahlforschung ergab, dass Arbeitsproben die höchste prädiktive Validität aller Auswahlmethoden besitzen (Validitätskoeffizient von 0,33, steigend auf 0,63 in Kombination mit strukturierten Interviews). Das übertrifft unstrukturierte Interviews und algorithmische Rätsel bei Weitem.

Hier sind die vier Säulen:

1. Repository-Reviews

Statt Code im luftleeren Raum zu schreiben, führen Kandidaten durch ihre tatsächliche Ingenieurarbeit. Evaluatoren analysieren Commit-Historien, Pull-Request-Diskussionen, CI/CD-Konfigurationen und Architekturentscheidungs-Dokumentationen.

Das zeigt Gewohnheiten, die ab dem ersten Tag wichtig sind. Schreiben sie Tests vor dem Deployment? Gehen sie technische Schulden inkrementell an, statt sie auflaufen zu lassen? Dokumentieren sie Designentscheidungen für den Ingenieur, der diesen Code in zwei Jahren warten muss? Geben sie konstruktive, spezifische Code-Reviews, oder stempeln sie alles mit einem “LGTM” ab?

Die Falle, die es zu vermeiden gilt: KI-generierte Portfolios. Kandidaten können mittlerweile makellose README-Dateien, konventionelle Commit-Nachrichten und überentwickelte Nebenprojekte generieren, die beeindruckend aussehen, aber nichts verraten. Das echte Signal liegt in den unordentlichen Teilen: Issue-Tracker-Diskussionen, Merge-Conflict-Resolution, Umgang mit veralteten Abhängigkeiten und tief verschachtelte PR-Threads.

Für Kandidaten, deren Arbeit unter NDAs steht (häufig in Finanzen, Verteidigung, Gesundheitswesen), bieten Sie Alternativen an: kuratierte nicht-vertrauliche Code-Beispiele, schriftliche Architekturentscheidungs-Dokumentationen oder einen direkten Weg zum Take-Home-Projekt.

2. KI-Kompetenz-Bewertungen

Es geht nicht darum, ob jemand einen Prompt schreiben kann. Das kann mittlerweile jeder Wissensarbeiter. KI-Kompetenz bedeutet epistemologische Skepsis: die Fähigkeit, maschinell generiertem Code zu misstrauen, ihn zu verifizieren und zu korrigieren.

Präsentieren Sie Kandidaten einen realistischen KI-generierten Pull Request, etwa 500-2.000 Zeilen funktionalen, aber fehlerhaften Codes. Der Code sieht sauber aus, enthält aber subtile Probleme: eine nicht-indizierte Datenbankabfrage, die im Betrieb scheitern wird, einen halluzinierten API-Endpunkt, ein Speicherleck versteckt hinter vernünftig aussehender Logik.

Starke Kandidaten werden:

• Das Mergen ohne Tests verweigern
• Die Annahmen der KI gegen die tatsächliche Dokumentation prüfen
• Randfälle identifizieren, die das Modell ignoriert hat
• Die Wartungskosten der Übernahme von brüchigem, generiertem Code benennen

Das misst Engineering Ownership, die wichtigste Eigenschaft in einem KI-gestützten Workflow.

3. Kontextuelles System-Design

Verabschieden Sie sich von den “Entwerfen Sie Twitter”-Aufgaben, die Kandidaten aus Vorbereitungsanleitungen auswendig lernen. Stattdessen präsentieren Sie Probleme, die durch die tatsächlichen betrieblichen Gegebenheiten Ihres Unternehmens eingeschränkt sind: spezifische Latenzanforderungen, Infrastruktur-Kostenbudgets, Datenschutzvorschriften.

Anstelle von “Entwerfen Sie einen URL-Shortener” fragen Sie zum Beispiel: “Unsere Analytics-Pipeline verarbeitet 50 Millionen Events pro Tag mit einer P99-Latenzanforderung von 200 ms. Wir müssen Echtzeit-Anomalieerkennung hinzufügen, ohne unser aktuelles Infrastrukturbudget von 8.000 $/Monat zu überschreiten. Erklären Sie mir Ihren Ansatz.” Diese Art von Problem kann man nicht auswendig lernen. Sie erfordert, dass der Kandidat live Kompromisse durchdenkt, mit realen Einschränkungen.

Hinterfragen Sie aggressiv das Denken in Fehlermodi: Wie degradiert das System bei einem Rechenzentrumsausfall? Wie verhindern Sie, dass verteilte Retry-Stürme nachgelagerte Services zum Absturz bringen? Was passiert, wenn der Traffic bei einem Produktlaunch um das Zehnfache ansteigt?

Das testet auch Kommunikation, eine Kompetenz, die 2026 wichtiger ist als je zuvor. Kann der Kandidat Kompromissentscheidungen gegenüber einem nicht-technischen Stakeholder begründen? Kann er Alternativen diskutieren, ohne defensiv zu werden? Kann er komplexe Architektur erklären, ohne sich hinter Fachjargon zu verstecken? Die besten Architekten sind diejenigen, die technische Einschränkungen in Geschäftssprache übersetzen können.

4. Bezahlte Take-Home-Projekte

Ersetzen Sie die Live-Coding-Runde vollständig durch ein vergütetes, realistisches Projekt. Geben Sie Kandidaten eine tatsächliche (sicher herunterskalierte) Codebasis mit realen betrieblichen Mängeln, komplexer Geschäftslogik und bewusst uneindeutigen Anforderungen. Lassen Sie sie ihre eigene IDE, ihre eigenen KI-Tools und ihren eigenen Workflow verwenden, genau so, wie sie es ab dem ersten Tag tun würden.

Bewerten Sie Einreichungen anhand einer standardisierten Rubrik, die Architekturbeständigkeit, Testabdeckung, Dokumentationsklarheit und Codequalität umfasst. Das neutralisiert Prüfungsangst und lässt echte Ingenieurkompetenz zum Vorschein kommen.

Der Kosteneinwand ist der lauteste und am leichtesten zu widerlegen. Die Vergütung eines Kandidaten für 4-6 Stunden Arbeit kostet ein paar Hundert Dollar. Laut der Society for Human Resource Management (SHRM) kostet eine Fehleinstellung mindestens 30 % des Erstjahresgehalts. Bei einem Senior-Ingenieur mit einem Grundgehalt von 120.000-160.000 $ erreicht der Gesamtschaden (Rekrutierung, Einarbeitung, verlorene Produktivität, Projektverzögerungen und Abfindung) regelmäßig 150.000-240.000 $. Das deckt sich mit dem, was wir in Startup-Post-Mortems beobachten. Das Take-Home-Projekt ist keine Ausgabe. Es ist eine Versicherung.

Für eine detaillierte Aufschlüsselung, wie Sie diese Projekte dimensionieren und strukturieren, lesen Sie unseren Leitfaden Wie Sie Code-Aufgaben strukturieren, die Kandidaten nicht hassen.

Wie Bewertungsmethoden im Vergleich abschneiden

Nicht alle Interviewformate sind gleich. Jahrzehnte der Personalauswahlforschung, insbesondere die Meta-Analyse von Schmidt und Hunter im Psychological Bulletin, zeigen klar, welche Methoden Arbeitsleistung vorhersagen:

Am unteren Ende dieser Tabelle operieren die meisten Unternehmen noch immer. Am oberen Ende sollten sie laut Evidenzlage sein.

Der kulturelle Wandel, den das erfordert

Der schwierigste Teil dieses Übergangs ist nicht die Logistik. Es ist die Überzeugung von Engineering-Führungskräften, ein System aufzugeben, das ihre eigenen Karrieren validiert hat. Das algorithmische Interview ist bequem: leicht durchzuführen, leicht zu bewerten, leicht zu verteidigen. Es erlaubt Interviewern, zehn Minuten vor dem Gespräch eine Aufgabe zur dynamischen Programmierung aus einer Fragenbank zu ziehen und ein binäres Bestanden/Durchgefallen zu generieren, ohne sich tiefgehend mit dem tatsächlichen Denken des Kandidaten auseinanderzusetzen.

Das moderne Framework verlangt mehr von den Interviewern:

• Schulung: Evaluatoren müssen lernen, reale Ingenieurumgebungen zu simulieren und auf tiefes Denken zu prüfen, nicht auf auswendig gelernte Antworten
• Kalibrierung: Die Bewertung muss an spezifischen Verhaltensindikatoren verankert sein (Hat der Kandidat selbstständig die halluzinierte Methode im Mock-PR erkannt?)
• Zeitaufwand: Die Überprüfung von Repositories und die Bewertung von Take-Homes dauert länger als jemandem beim Scheitern am Whiteboard zuzusehen

Diese Investition zahlt sich aus. Organisationen, die strukturiertes, evidenzbasiertes Recruiting implementieren, verzeichnen niedrigere Fehleinstellungsraten, geringere Fluktuation (weil Kandidaten, die einen respektvollen Interviewprozess erlebt haben, engagiertere Mitarbeiter sind) und stärkere Engineering-Teams.

Der Talentmarkt verstärkt dies. Top-Ingenieure lehnen zunehmend Unternehmen ab, die sie sechs Runden irrelevanter Whiteboard-Tests unterziehen. In kompetitiven Märkten gewinnen die Unternehmen, die die Zeit der Kandidaten respektieren und relevante Fähigkeiten bewerten, den Kampf um Talente.

Wie Kit technisches Recruiting im Post-KI-Zeitalter unterstützt

Kits Hiring-Pipeline ist genau für diesen Übergang gebaut. Statt moderne Bewertungsmethoden auf ein Legacy-ATS aufzuschrauben, ist Kit ein KI-natives Applicant Tracking System, das die Infrastruktur für evidenzbasierte Bewertungen nativ bereitstellt.

Code-Aufgaben sind direkt in die Hiring-Pipeline integriert: GitHub-Repository-Erstellung aus Templates, automatische Einladungen an Kandidaten, Deadline-Management und Reviewer-Zugang, alles ohne Kit zu verlassen. Kandidaten authentifizieren sich mit einem Magic Link (keine Passwörter, keine Reibung) und reichen über ein übersichtliches Portal ein.

Team-Review und Abstimmung ermöglichen es mehreren Interviewern, Kandidaten unabhängig voneinander anhand strukturierter Rubriken zu bewerten, bevor sie die Bewertungen der anderen sehen. Das reduziert Gruppendenken und Ankereffekte.

Jede Phase der Pipeline, vom Repository-Review über System-Design bis zur Take-Home-Einreichung, lebt an einem Ort mit voller Transparenz für das Hiring-Team. Keine Spreadsheets, keine getrennten Tools, keine Kandidaten, die durch die Maschen fallen.

Das algorithmische Interview hatte seine Ära. Diese Ära endete, als KI lernte, es zu bestehen. Die Organisationen, die 2026 die besten Engineering-Teams aufbauen werden, sind nicht diejenigen, die Ingenieure einstellen, die Sortieralgorithmen am schnellsten schreiben können. Es sind diejenigen, die Ingenieure mit dem architektonischen Urteilsvermögen, der KI-Kompetenz und der kritischen Skepsis identifizieren, um die Maschinen sicher zu steuern. Ihr Interviewprozess selektiert entweder für diese Fähigkeiten oder dagegen.