Wie man KI-resistente Coding-Interview-Fragen schreibt

Die Voraussetzungen haben sich verändert

Mitte 2026 ist die interessante Frage nicht, ob der Kandidat ChatGPT offen hat. Es ist, ob dein Interview noch aussagekräftig ist, wenn er es hat. Die meisten Teams reagierten mit Überwachung — Keystroke-Biometrie, Paste-Flaggen, Code-Kohärenz-Scoring. Überwachung hilft. Fragendesign hilft mehr. Ein Problem, das ein LLM in acht Sekunden löst, sagt dir nichts über die Person hinter der Tastatur, egal wie sauber du den Paste kennzeichnest.

Das ist ein Leitfaden zum Schreiben von Programmierungsfragen, die noch immer aussagekräftig sind, wenn KI-Unterstützung vorausgesetzt wird.

Was macht eine Frage leicht für ein LLM

Drei Eigenschaften spielen gegen dich:

1. Sie erscheint im Trainingskorpus. LeetCode, HackerRank, Codeforces, GitHub-Trending-Repos — alles ist in den Gewichten. Wenn deine Frage einen Wikipedia-artigen Namen hat (Two Sum, Word Ladder, Longest Increasing Subsequence), gehe davon aus, dass die Antwort auswendig gelernt ist.
2. Die vollständige Spezifikation wird gleich zu Beginn übergeben. Ein vollständiger, eindeutiger Prompt ist exakt die Form, auf die ein LLM trainiert ist. Das Modell braucht nichts vom Kandidaten.
3. Die Ausgabe ist geschlossen. Eine Funktion mit einem Input, einem Output, einer korrekten Antwort ist trivial bewertbar — und trivial generierbar.

LeetCode #1 erfüllt alle drei Kriterien. Genauso wie die meisten Fragen deiner geerb​ten Bibliothek.

Gestaltungsprinzip 1: Verstecke die Spezifikation, zeige das Symptom

Statt "implementiere eine Funktion, die den längsten Substring ohne wiederholte Zeichen zurückgibt," gebe dem Kandidaten einen fehlgeschlagenen Test und einen vagen Bug-Bericht: "Kunden sehen nach diesem Endpoint doppelte Artikel in ihrem Warenkorb. Hier ist ein fehlgeschlagener Input. Mache es rückgängig."

Der Kandidat muss jetzt:

• Den bestehenden Code lesen
• Eine Hypothese darüber bilden, was falsch ist
• Entscheiden, was "korrekt" überhaupt bedeutet

Das Modell kann noch helfen — aber erst, nachdem der Kandidat das Problem eingeordnet hat. Diese Einordnung ist sowieso die Fähigkeit, die du messen wolltest.

Gestaltungsprinzip 2: Übergebe die Codebasis, nicht den Prompt

Ersetze eigenständige Puzzles mit einem kleinen Repository. 100–300 Zeilen, mehrere Dateien, ein bis zwei absichtliche Bugs, eine knappe README. Frage: "Finde den Bug, der die 500 auf POST /orders verursacht, und behebe ihn."

Ein Modell, das dein Repository nicht gesehen hat, ist nicht besser darin als der Kandidat. Es wird plausibel raten und dabei falsch liegen — weil die Antwort im umgebenden Code liegt, nicht im Prompt.

Dieses Format funktioniert auch als LeetCode-freies Interview für Teams, die lieber echte Ingenieursfähigkeit statt Puzzle-Geschwindigkeit messen wollen.

Gestaltungsprinzip 3: Baue eine Wendung in der Mitte ein

Halbe Zeit durch, ändere die Anforderung. "Der Kunde möchte nun Teilrückerstattungen unterstützen — erweitere deine Lösung." Oder: "Dieser Endpoint muss jetzt idempotent sein. Was ändert sich?"

Die Wendung leistet drei Dinge:

• Zwingt den Kandidaten zu zeigen, dass er seinen eigenen Code versteht (ein frischer Copy-Paste aus einem Chat-Fenster kann das nicht).
• Bringt Architektur-Instinkte ans Licht, die eine Eins-zu-Eins-Lösung verbirgt.
• Macht Prompting eines Modells während des Interviews offensichtlich — der Kandidat stoppt entweder, bittet um ein paar Minuten oder erzeugt einen zweiten sauberen Paste, der nichts mit dem ersten zu tun hat. Alles wird zum Signal im Integrity-Bericht.

Gestaltungsprinzip 4: Frage nach Urteilsvermögen, nicht nach Output

Einige der aussagekräftigsten Fragen haben überhaupt keinen Code zu schreiben:

• Code-Review-Übungen. Übergebe einen 60-zeiligen Diff. Bitte den Kandidaten, Kommentare zu hinterlassen, als würde er der Reviewer in einem PR sein. LLMs produzieren aufrichtige, generische Code-Reviews ("erwäge, hier einen Kommentar hinzuzufügen"). Senior Engineers produzieren spezifische, priorisierte Kritik ("dieser Lock wird über den Netzwerkaufruf hinweg gehalten — das wird unter Last zu einem Deadlock führen").
• Tradeoff-Gespräche. "Du hast zwei Optionen für diese Cache-Invalidation. Welche würdest du wählen und warum?" Der Kandidat muss eine Wahl verteidigen. Das Modell hat kein Risiko und wird abwägen.
• Ein unbekanntes PR lesen. "Gehe mir durch, was diese Änderung tut und was schiefgehen könnte."

Diese clustern besser mit System-Design-Rubriken als mit Algorithmus-Scorecards. Bewerte sie nach der Begründung, nicht nach dem Ergebnis.

Gestaltungsprinzip 5: Ungewöhnliche Einschränkungen statt ungewöhnlicher Probleme

Du brauchst keine neue Problemklasse zu erfinden. Du brauchst nur eine ungewöhnliche Einschränkung auf eine vertraute.

• "Implementiere einen Rate-Limiter — aber die Uhr kann durch NTP-Drift um bis zu 30 Sekunden rückwärts laufen."
• "Baue eine Queue — aber enqueue muss O(1) im schlimmsten Fall sein, nicht amortisiert, weil wir das in einer echten Echtzeit-Kontrollschleife ausführen."
• "Parse diese Config-Datei — aber die Spezifikation entwickelt sich weiter. Zeige mir, wie du Abwärtskompatibilität drei Versionen von jetzt an handhaben würdest."

LLMs können diese lösen. Sie verpassen oft die Einschränkung. Der Kandidat, der sie bemerkt, danach fragt und drumherum entwirft, ist der Kandidat, den du haben willst.

Was du nicht tun solltest

Ein paar häufige Reaktionen, die nach hinten losgehen:

• KI verbieten ohne die Frage zu ändern. Du wirst Top-Kandidaten verlieren, die KI bereits gut nutzen, die Cheater behalten, denen deine Regeln egal sind, und nichts Neues lernen.
• Probleme absichtlich schwerer machen, um "den Modellen voraus zu sein". Adversarische Schwierigkeit wählt Menschen aus, die bereit sind, unter Druck zu schuften, nicht Menschen, die den Job machen können. Die Erfolgsquote bricht zusammen und der Funnel staut sich.
• Alles auf Whiteboard / No-Laptop-Interviews umstellen. Das ist eine echte Option, aber es hat seine eigenen Tradeoffs — Barrierefreiheit, Kandidaten-Stress und die Tatsache, dass kein Engineer so in seinem echten Job codiert.
• Den Labels "KI-resistent" von Frage-Anbietern vertrauen. Einige Anbieter überprüfen, dass eine Frage einen Schwellwert unterschreitet, wenn sie heute GPT-4 eingegeben wird. Das Modell von morgen testet anders. Behandle das Label als Startpunkt, nicht als Garantie.

Kombiniere Fragendesign mit der Messbarkeitssicht

Selbst eine gut gestaltete Frage profitiert von einer Integritätssicht, die dir eine zweite Signal-Achse gibt. ClarityHires Code-Kohärenz-KI liest die Entwicklung einer Einreichung, nicht nur den finalen Code — hat der Kandidat iteriert, getestet und umgestaltet, oder kam die Lösung in einem großen kohärenten Paste an? Kombiniert mit Keystroke-Timing und Paste/Tab-Events erhältst du eine Konfidenzquote, die sich mit den oben genannten Designentscheidungen paart, statt sie zu ersetzen.

Das stärkste Muster, das wir sehen: eine KI-resistente Frage für die async Stage, gefolgt von einem 30-minütigen Live-Follow-Up-Walkthrough, bei dem der Kandidat Entscheidungen erklären muss, die er Stunden zuvor getroffen hat. Die Kombination ist erheblich schwerer zu fälschen als jeder Schritt alleine.

Was du als nächstes tun solltest

Nimm die drei Fragen, die du am häufigsten stellst, und bewerte sie anhand der oben genannten Prinzipien:

1. Versteckt jede Frage einen Teil der Spezifikation, den der Kandidat herausarbeiten muss?
2. Erfordert die Frage das Lesen von Code, den der Kandidat nicht zuvor gesehen hat?
3. Gibt es eine Wendung oder einen Urteilsspruch, den ein vorgefertigtes Modell nicht einfach übernehmen kann?

Für jede Frage, die schlecht abschneidet, schreibe sie einmal um und teste die neue Version mit fünf echten Kandidaten, bevor du sie ausrollst. Messe zwei Dinge: die durchschnittliche Einreichungsqualität deines oberen Quartils und die Durchgangsquote zur nächsten Runde. Wenn sich die Qualität verbessert und der Durchsatz gleich bleibt, hast du eine bessere Frage. Wenn der Durchsatz zusammenbricht, ist die neue Version adversarial, nicht selektiv — überarbeite und versuche es erneut.

KI in Programmier-Interviews ist nicht das Problem. KI-förmige Fragen sind. Behebe die Fragen und der Rest des Integritätsstacks beginnt zu tun, was er schon immer tun sollte: das Signal bestätigen, nicht erzeugen.