Wie man die Nutzung von Cursor und Copilot in Coding-Interviews erkennt

Warum die ChatGPT-Strategie bei Cursor und Copilot fehlschlägt

Die Standard-Betrugserkennung für Coding-Interviews basiert auf einer Annahme: Der Kandidat wechselt mit Alt+Tab zu einem Chat-Fenster, fordert eine Lösung an und fügt sie ein. Paste-Größe, Tab-Wechseldauer und Schreib-Bursts sind alle auf diesen Workflow ausgerichtet.

2026 ist diese Annahme falsch für die KI-Tools, die Kandidaten tatsächlich nutzen. Cursor, GitHub Copilot, Windsurf, Continue und die neue Generation von unsichtbaren Overlay-Tools wie Cluely funktionieren nicht durch Einfügen. Sie sitzen im Editor, akzeptieren Vorschläge per Tab und geben Zeichen auf eine Weise in den Buffer aus, die viel mehr wie Tippen aussieht als wie ein Einfügen-Event. Ein Kandidat, der Cursor geschickt nutzt, wird niemals einen Paste-Alert auf Ihrer Plattform auslösen und wird nie wieder den Tab wechseln. Der Integritätsbericht eines naiven Screening-Tools liest sich sauber.

Das ist ein anderes Problem und erfordert einen anderen Signal-Stack. Dieser Beitrag geht durch den Verhaltens-Fingerabdruck von Editor-integrierten KI-Assistenten, die spezifischen Momente, wo sie sich verraten, und wie man die Live-Runde so gestaltet, dass ein ehrlicher Nutzer dieser Tools immer noch interpretierbare Signale erzeugt.

Wie integrierte KI-Assistenten für die Plattform aussehen

Drei Kategorien von Tools, drei verschiedene Spuren:

• Tab-Completion-Agenten (Copilot, Cursor Tab, JetBrains AI). Ein „Ghost Text"-Vorschlag erscheint nach einer kurzen Pause; der Kandidat drückt Tab; 40–300 Zeichen landen in einer einzigen Aktion im Buffer. Für einen Keystroke-Recorder kann diese Aktion entweder wie eine Sequenz von schnellen Tastenanschlägen oder als einzelnes Insertion-Event aussehen, je nachdem, wie der Editor die Eingabe verarbeitet.
• Agentic Editors (Cursor Composer, Windsurf Cascade, Claude Code, Aider). Der Kandidat tippt oder spricht eine Anweisung in natürlicher Sprache in ein Seitenpanel; der Agent schreibt einen Teil der Datei um. Von außen sieht das wie eine Reihe von mehrzeiligen Änderungen ohne entsprechende Tastenanschläge dazwischen aus.
• Unsichtbare Overlay-Tools (Cluely, Interview Solver, Interview Coder). Ein separater Prozess liest den Bildschirm und zeigt dem Kandidaten eine Antwort in einem Overlay, das vor Screen-Capture-APIs verborgen ist. Der Kandidat tippt oder transkribiert sie dann ab. Die On-Platform-Spur ist „Kandidat hat es selbst getippt", aber der Rhythmus stimmt nicht.

Der Kandidat fügt nicht ein. Er akzeptiert, transkribiert oder erteilt Anweisungen. Jede dieser Handlungen hat ein Merkmal.

Signal 1: Tab-Accept-Bursts in einem Tipp-Stream

Der sauberste Fingerabdruck eines Tab-Completion-Tools ist die Form des Keystroke-Streams. Von Hand getippter Code auf einer 30-Zeichen-Zeile sieht wie 30 Tastenanschläge mit Abständen von 80–250 ms aus, mit gelegentlichen 1–2 Sekunden Pause. Ein Copilot-Tab-Accept auf der gleichen Zeile sieht wie ein Event bei +0 ms gefolgt von 30 Zeichen bei je +1 ms aus — oder in manchen Editoren ein einzelnes Buffer-Insertion ohne Timing pro Zeichen.

ClarityHires Keystroke-Recorder klassifiziert jeden zusammenhängenden Eingabe-Run, bei dem die Verzögerung zwischen Tasten unter ~5 ms fällt, als Machine-Emitted Block. Der Block wird getrennt von getippten Zeichen protokolliert und erscheint im Integritätsbericht als eigener Event-Typ — nicht Paste, nicht Keystroke, ein Accept.

Was im Bericht zu suchen ist:

• Eine Serie von 5–10 Accept-Events pro Minute, jeweils 40–250 Zeichen lang, vermischt mit normalem Tippen. Das ist der kanonische Copilot/Cursor-Rhythmus.
• Accept-Blöcke, die ganze Funktionen in einem Event abschließen (300+ Zeichen). Das ist Agentic-Editor-Verhalten, nicht Tab-Completion.
• Null Pastes, null Tab-Wechsel, aber der Kandidat produziert eine funktionierende 200-Zeilen-Lösung in 22 Minuten flach. Das Volumen selbst ist das Signal.

Keines davon ist ein smoking gun. Alle zusammen, gegen ein Problem, das der Kandidat noch nie gesehen hat, ist es.

Signal 2: Cursor-Sprünge, die der Kandidat nicht von Hand machen kann

Wenn ein Mensch Code schreibt, bewegt sich der Cursor wie Menschen Cursor bewegen: Pfeiltasten, Home/End, gelegentliche Klicks in eine andere Zeile. Wenn ein Agentic Editor einen Bereich umschreibt, teleportiert sich der Cursor — die nächste Änderung ist zwei Funktionen weg von der vorherigen, ohne dazwischenliegende Navigation. Wenn ein Tool über Dateien hinweg refaktoriert, ändert sich die aktive Datei ohne Cmd-P Fuzzy-Find.

Der Collaborative Editor, der in Live-Coding-Runden verwendet wird, protokolliert Cursor-Position und aktives Dokument bei jeder Änderung. In der Zeitleiste fallen „Teleport-Edits" auf: Eine Änderung in Zeile 80 unmittelbar gefolgt von einer Änderung in Zeile 12 einer anderen Datei, ohne sichtbare Navigation und ohne Scroll. Ein Mensch kann das mit Hotkeys machen, aber die Häufung solcher Moves über eine Runde ist das Entscheidende. Zwei oder drei sind normal. Zwanzig in 20 Minuten ist der Agent am Werk.

Signal 3: Tipp-Rhythmus, der nicht zur eigenen Baseline des Kandidaten passt

Tab-Acceptance gibt dem Kandidaten eine fertige Zeile. Er muss immer noch die Anweisung tippen, die sie hervorrief, oder die nächste Zeile selbst tippen. Der Keystroke-Stream wird also bimodal: lange Strecken von Machine-Emitted Code unterbrochen von kurzen Strecken menschlichen Tippens.

Keystroke-Biometrie auf den getippten Teilen ist immer noch nützlich — der Dwell-and-Flight-Fingerabdruck des Kandidaten sollte während der Sitzung konsistent sein. Aber das Verhältnis ist das neue Signal: Ein Cursor-intensiver Kandidat tippt vielleicht 15–25% der Zeichen in der endgültigen Datei. Ein Nicht-Nutzer tippt 95%+. Das Verhältnis ist im Bericht sichtbar und hängt nicht davon ab, dass ein einzelnes Event korrekt klassifiziert wird.

Das ist auch das Signal, das die unsichtbaren Overlay-Tools erwischt. Ein Kandidat, der von einem Cluely-Overlay liest und die Antwort umschreibt, tippt in einem ungewöhnlich gleichmäßigen Tempo mit sehr wenigen Korrektionen, weil er transkribiert statt verfasst. Der Edit-Abstand zwischen dem Keystroke-Stream und der endgültigen Datei kollabiert gegen null. Echte Urheberschaft hat Backspaces, Umbenennungen und zurückgenommene Versuche; Transkription nicht.

Signal 4: Die Einreichung ist kohärenter als der Prozess

Führe Code-Kohärenzanalyse auf der endgültigen Datei durch und du bekommst eine separate Sichtweise. Cursor Composer und Claude Code produzieren hochgradig kohärente Dateien — durchgehend idiomatisch, konsistente Namensvergabe, defensive Fehlerbehandlung für Fälle, die der Kandidat nicht durchgearbeitet hat. Das ist eine andere Ausfallart als ChatGPT-stitched-Code, der dazu neigt, inkohärent zu sein. Cursor-Code ist zu sauber für den sichtbaren Prozess.

Die diagnostische Frage ist die, die der Kohärenz-Judge schon stellt: Sieht das aus, als hätte eine Person es von Anfang bis Ende in 30 Minuten geschrieben, während sie mit mir im Video sprach? Ein Mensch unter Interview-Druck produziert eine Datei mit mindestens einer rauen Stelle — ein zurückgelassenes console.log, eine Funktion, die sie umbenennen wollte, ein Kommentar, der dem Code widerspricht. Eine Cursor-Composer-Datei hat selten etwas davon. Das Fehlen von Unordnung ist das Signal.

Was man im Gespräch fragen sollte

Erkennung ist die halbe Antwort. Die andere Hälfte ist, die Frage zu stellen, der ein Agent-Nutzer nicht ausweichen kann:

1. Wähle eine nicht offensichtliche Zeile und frag warum. „Du hast hier Map statt eines Objekts verwendet — was war der Kompromiss?" Ein echter Autor erklärt einen. Ein Accept-and-Move-On-Nutzer zuckt mit den Schultern.
2. Erzwinge eine kleine Erweiterung. „Füge ein Flag hinzu, das diese Fälle case-insensitiv macht." Fünf Zeilen, kein Tab-Accept erlaubt. Der Kandidat schreibt es entweder fließend oder bleibt stecken. Beide sind Signal.
3. Frag nach einem Fehler, den du sehen kannst. Verstecke ein subtiles Problem in der Aufgabe oder im Scaffold. Agentic Tools neigen dazu, es „zu beheben" ohne es anzuerkennen. Frag den Kandidaten, dir zu erklären, was er geändert hat und warum. Der ehrliche Nutzer erklärt; der Agent-Nutzer erzählt vom Diff.

Diese Follow-up-Fragen sind das gleiche Instrument, das du für eine KI-eingefügte Take-Home nutzen würdest. Der Punkt ist nicht, das Tool zu erwischen — es geht darum, herauszufinden, ob der Kandidat die Beziehung zum Code hat, die die Rolle erfordert.

Wie man die Runde so gestaltet, dass das Signal interpretierbar ist

Zwei strukturelle Entscheidungen machen all das oben Gesagte leichter lesbar:

• Stelle die Regel vor der Runde auf. „Du kannst jedes Tool verwenden, das du möchtest. Cursor, Copilot, deine eigenen Snippets. Wir werden dich fragen, zu erweitern und zu verteidigen, was du schreibst." Das ist der Open-Book-Rahmen und er wandelt ein Erkennungsproblem in ein Interpretationsproblem um. Ein Kandidat, der die Cursor-Nutzung vorab deklariert und seine Arbeit erklärt, ist in Ordnung. Ein Kandidat, der das versteckt und nicht erklären kann, ist der, den du filtern möchtest.
• Reserve fünf Minuten der Runde für ungestützte Edits. Sage dem Kandidaten voraus: Die letzten fünf Minuten sind eine kleine Erweiterung, keine KI-Tools. Beobachte, wie sie tippen, wenn der Assistent weg ist. Dieser einzelne Block produziert eine saubere Baseline zum Vergleich mit dem Rest der Runde.

Diese zwei Regeln geben deinem Integritätsbericht etwas, woran man sich anlehnen kann. Ohne sie versuchst du, Rhythmus gegen einen leeren Prior zu rekonstruieren; mit ihnen hast du in jedem Interview einen bekannten-Baseline-Abschnitt.

Was als Nächstes zu tun ist

Wenn du technische Interviews durchführst und dein aktueller Integritätsbericht nur Pastes und Tab-Wechsel verfolgt:

1. Füge einen Accept-Block-Detektor zu deinem Keystroke-Logging hinzu, oder wähle eine Coding-Plattform, die einen ausliefert. Ohne ihn sind Cursor-Nutzer für dich unsichtbar.
2. Füge den Ungestützten-Fünf-Minuten-Block diese Woche zu jeder Live-Runde hinzu. Es kostet dich fast nichts und gibt dir eine Baseline für jeden Kandidaten, nicht nur die verdächtigen.
3. Aktualisiere deine Kandidaten-Anweisungen, um zu sagen, was erlaubt ist und was nicht. Die meisten Kandidaten werden eine klare Regel respektieren; die wenigen, die das nicht tun, werden es schlecht verstecken.
4. Höre auf, dich auf Tab-Wechsel-Counts als primäres Signal zu verlassen. 2026 erfordert das Betrugstool, das der Kandidat verwendet, nicht, den Editor zu verlassen.

Das Wettrüsten gegen Editor-integrierte KI ist nicht durch Erkennung allein zu gewinnen. Es ist zu gewinnen durch Interview-Design, das ehrliche Tool-Nutzung von Nicht-Nutzung nicht zu unterscheiden macht und unehrliche Tool-Nutzung im Gespräch unmöglich zu verteidigen macht. Das Signal, das du möchtest, ist nicht „haben sie Cursor verwendet" — es ist „kennen sie, was ihr eigener Code macht." Gestalte die Runde um diese Frage und das Erkennungsproblem löst sich größtenteils selbst.