KI-resistente Coding-Interviewfragen entwerfen

Du kannst die KI nicht verbieten. Du kannst um sie herum entwerfen.

Es ist 2026. Kandidaten dazu aufzufordern, auf KI-Assistenten in einem Interview zu verzichten, ist Theater. Der Maßstab, den Kandidaten mit ChatGPT auf dem anderen Tab erfüllen, ist der Maßstab, gegen den deine Konkurrenz einstellt. Die Frage ist nicht, wie man KI-Nutzung erkennt — das ist die Hälfte der Arbeit, und wir behandeln das in wie man ChatGPT in Coding-Interviews erkennt. Die andere Hälfte ist das Entwerfen von Problemen, die nicht zusammenbrechen, wenn der Kandidat ein LLM zur Verfügung hat.

Dies ist ein Leitfaden zur zweiten Hälfte: Wie man Coding-Interview-Probleme schreibt, die echte Aussagekraft liefern, auch wenn die KI eingeschaltet ist, und wo die Hilfe der KI sauber auf Fähigkeiten abgebildet wird, die du wirklich einstellen möchtest.

Warum Standard-Probleme nicht mehr funktionieren

Ein typisches LeetCode-Problem hat drei Eigenschaften, die es für ein LLM trivial machen:

1. Es ist im Training-Datensatz. Jedes klassische Two-Pointer-, Sliding-Window- und Dynamic-Programming-Problem wurde im Internet beantwortet, erklärt und wieder erklärt.
2. Die Eingabe ist gut spezifiziert. Zwei Integer-Arrays, ein Zielwert, gib die Indizes zurück. Das Modell weiß genau, was es produzieren soll.
3. Die Ausgabe ist binär. Tests bestehen oder scheitern. Es gibt keine Bewertung in der Antwort, die der Kandidat verteidigen müsste.

Ein Problem mit allen drei Eigenschaften ist 2026 ein ChatGPT-Skill-Check, kein Programmier-Skill-Check. Jede Eigenschaft, die du entfernst, macht das Problem schwerer auszulagern.

Prinzip 1: verankere das Problem in Code, den das LLM noch nie gesehen hat

Der sauberste Weg, den Training-Set-Vorteil auszuschalten, besteht darin, den Kandidaten in einer spezifischen Codebasis arbeiten zu lassen. Ein LLM kann einen Graph-Traversal-Algorithmus aus dem Nichts schreiben. Es kann aber nicht zuverlässig ein 400-Zeilen-Repo erweitern, bei dem zwei der Module eine interne Konvention verwenden, auf die es noch nie gestoßen ist.

So sieht das in der Praxis aus:

• Fehler beheben. Ein 200-400 Zeilen großes Repo mit einem nicht offensichtlichen Fehler. Das Symptom ist gegeben, die Ursache nicht. Der Kandidat muss lesen, eine Hypothese aufstellen, testen und patchen. Wir skizzieren das Format in unserem Leetcode-freien Interview-Leitfaden.
• Features erweitern. Eine funktionierende App mit einer kleinen, gut definierten Feature-Anfrage. Die Diff-Qualität ist die Bewertung. Ein LLM kann einen plausiblen Diff generieren; es kann aber nicht garantieren, dass der Diff mit den bestehenden Konventionen übereinstimmt und die bestehenden Tests beim ersten Versuch besteht.
• Umgestalten unter einer Einschränkung. „Diese Datei ist 600 Zeilen groß und schwer zu lesen. Teile sie in drei Dateien auf, ohne das Verhalten zu ändern. Tests müssen weiterhin bestehen." Die richtige Antwort ist ein Urteilsspruch. Es gibt keine kanonische Lösung zum Auswendiglernen.

Diese Formate neutralisieren den Training-Set-Vorteil, weil das LLM das Repo nicht gesehen haben kann. Die Fähigkeit des Kandidaten, sich durch unbekannten Code zu navigieren, wird zum Signal.

Prinzip 2: mache die Eingabe absichtlich mehrdeutig

LLMs sind am stärksten, wenn die Spezifikation präzise ist. Sie sind am schwächsten, wenn die Spezifikation Informationen vermisst, die ein Mensch bemerken und nachfragen würde.

Ein Standard-Problem: „Gegeben ein CSV mit Bestellungen, berechne den monatlichen Umsatz."

Eine schwerer auszulagernde Version: „Hier ist ein CSV mit Bestellungen. Berechne den monatlichen Umsatz. Einige Zeilen sind Rückgaben und werden als negative Beträge dargestellt. Einige Zeilen sind Teilrückgaben und verwenden einen anderen status-Wert. Einige Zeilen stammen aus einer eingestellten Produktlinie, die nie wirklich versandt wurde. Entscheide, welche davon du einbeziehen möchtest, und erkläre deine Begründung, bevor du Code schreibst."

Der Begründungsschritt ist die Bewertung. Ein LLM wird bereitwillig Code produzieren, der den kanonischen Fall behandelt und den Rest stillschweigend weglässt. Ein echter Ingenieur wird innehalten, die Mehrdeutigkeiten auflisten und eine Klärungsfrage stellen — oder die Annahmen dokumentieren, die er gemacht hat.

Bewerte die Klarstellungen und Annahmen des Kandidaten separat vom Code, der danach folgt. Die Klarstellungsliste ist schwerer zu fälschen als die Implementierung.

Prinzip 3: verlagere das Gewicht auf die Konversation um den Code

Ein Submission ist ein Beispiel, keine Antwort. Ein LLM kann ein Submission produzieren. Nur der Kandidat kann es unter Live-Befragung verteidigen.

Zwei Wege, um das zu nutzen:

• Asynchron-dann-synchron. Führe zuerst die Take-Home- oder asynchrone Coding-Runde durch, dann plane eine 30-minütige Live-Runde ein, in der der Kandidat sein Submission durchgeht. Fordere ihn auf, es zu erweitern, eine Einschränkung zu ändern oder zu argumentieren, warum er eine Datenstruktur über eine andere gewählt hat. Wir haben dieses Format in Folgefragen für Take-Home-Submissions ausgeleuchtet.
• Live-Pairing auf dem eigenen Code des Kandidaten. Ändern Sie während des Interviews eine Anforderung und bitten Sie ihn, vor dir zu refaktorisieren. Der Kandidat, der die ursprüngliche Lösung von einem LLM eingefügt hat, wird Schwierigkeiten haben, sie ohne erneutes Prompting zu entwickeln.

In ClarityHire statten wir die Live-Runde mit Code-Kohärenz-Checks für das ursprüngliche Submission aus, damit der Interviewer mit dem Wissen ins Gespräch kommt, welche Abschnitte des Kandidaten-Codes LLM-generiert aussehen und welche handgeschrieben aussehen. Das Gespräch kann dann die verdächtigen Abschnitte gezielt angehen.

Prinzip 4: wähle Probleme, bei denen KI-Hilfe ein Feature ist, kein Bug

Wenn deine Stellenausschreibung sagt „du wirst jeden Tag KI-Tools in dieser Rolle verwenden", dann entwerfe Probleme, die dir ermöglichen zu beobachten, wie Kandidaten sie tatsächlich verwenden. Das ist nicht dasselbe, wie ihnen zu erlauben, die Antwort einzufügen.

• Open-Book mit Attribution. Erkläre explizit: „Du darfst ChatGPT oder eine beliebige Dokumentation verwenden. Dokumentiere jeden Prompt, den du verwendet hast, und den Teil der Lösung, den er produziert hat." Ein starker Kandidat nutzt das Modell chirurgisch; ein schwacher promptet fünfmal für dieselbe kaputte Funktion. Die Trace ist das Signal.
• KI als Gegner. Gib dem Kandidaten eine fehlerhafte, KI-generierte Funktion als Ausgangspunkt. Seine Aufgabe besteht darin, zu identifizieren, was falsch ist, warum und es zu beheben. Dies testet die Fähigkeit, die die Rolle tatsächlich erfordert: KI-Ausgaben vor dem Versand kritisch überprüfen.
• KI-unterstütztes Debuggen. Übergib ihnen ein unbekanntes Repo mit einem echten Fehler, erlaube Tool-Nutzung und beobachte, wie sie die Ursache eingrenzen. Ingenieure, die das Modell für enge Fragen nutzen („was bedeutet dieser Stack Trace?"), sehen sehr anders aus als diejenigen, die die ganze Datei einfügen und beten.

Wir erkunden das größere Bild dieses Formats in open-book coding assessments.

Prinzip 5: verbinde Prävention mit Erkennung — verlasse dich auf keine allein

Selbst das best-entworfene Problem leckt Signal nur in eine Richtung. Kombiniere die obigen Design-Entscheidungen mit passiven Integritätssignalen:

• Keystroke-Biometrie kennzeichnet Burst-Paste-Ereignisse, die nicht mit menschlichen Autorenschaft übereinstimmen.
• Code-Kohärenz-Analyse fängt stilistische Verschiebungen mitten im Submission auf.
• Eine Live-Folgefrage fängt Autoren, die ihren eigenen Code nicht verteidigen können.

Jede allein ist schwach. Zusammen machen sie die Kosten des Betrugs höher als die Kosten der Arbeit.

Eine kurze Checkliste, bevor du die Frage veröffentlichst

Bevor du ein Coding-Problem 2026 vor einem Kandidaten sicherst, frage dich selbst:

1. Könnte ChatGPT das nur von der Problemaussage gelöst werden? Wenn ja, überarbeite es oder reduziere sein Gewicht in der Schleife.
2. Ist die Spezifikation mehrdeutig auf eine Weise, die Klärungsfragen belohnt? Wenn nicht, füge Mehrdeutigkeit hinzu.
3. Muss der Kandidat seine Lösung live verteidigen oder entwickeln? Wenn nicht, plane eine Folgefrage ein.
4. Misst du, wie sie KI verwenden, oder tust du so, als würden sie das nicht? Sei ehrlich mit dem Kandidaten, auf jeden Fall.
5. Hast du ein Integritätssignal, das bestätigt, dass dieselbe Person das Submission geschrieben und die Folgefrage durchgeführt hat? Wenn nicht, füge eins hinzu.

Was du als Nächstes tun kannst

Wenn deine aktuelle Coding-Runde ein einzelnes LeetCode-ähnliches Problem mit einer Take-Home-Dropbox ist, testet du an dieser Stelle Prompt-Engineering, nicht Engineering. Wähle eines der oben genannten Formate, schreibe ein Problem darin und führe es auf drei internen Ingenieuren durch, bevor du es vor einen Kandidaten setzt. Die erste Version wird zu einfach oder zu unklar sein; die dritte wird die sein, die echte Aussagekraft produziert.

Für einen breiteren Kontext darüber, wo Asynchron in die Schleife passt, siehe asynchron vs. Live-technische Interviews. Für die Erkennungshälfte dieses gleichen Problems, starten Sie mit wie man ChatGPT in Coding-Interviews erkennt.