Wie man AI-Zusammenarbeitsfähigkeiten in Coding-Interviews bewertet

Wenn AI-Nutzung zur Fähigkeit wird, nicht zum Verhalten, das erkannt werden soll

Über das Gros der letzten zwei Jahre war AI in Interviews etwas, das man verhindern musste. Die Bewertungsskala war „hat der Kandidat es genutzt, und haben wir es erwischt?" Dieser Rahmen gilt immer noch in AI-verbotenen Runden, und die Integritätsebene, die Missbrauch dort erkennt, ist echte Arbeit.

Aber in der gleichen Interview-Phase führen immer mehr Unternehmen jetzt eine Runde durch, in der AI erforderlich ist. Meta, Canva, Shopify und Coinbase bewerten Kandidaten explizit auf AI-Zusammenarbeit. Wenn deine Phase sich in diese Richtung bewegt, brauchst du eine Bewertungsskala – denn wenn du einem Kandidaten sagst „nutze beliebige Werkzeuge, die du möchtest" und bewertest ihn danach, ob der finale Code funktioniert, misst du fast nichts. Der funktionierende Code ist der Beitrag der AI. Die Fähigkeit ist diejenige, die der Kandidat mitbringt.

Dieser Artikel ist für Hiring Manager, die diese AI-kollaborative Runde gestalten. Vier Dimensionen zum Bewerten, ein Übungsformat und die häufigen Interviewer-Fehler, die das Signal verwässern.

Die vier Dimensionen, die es wert sind, bewertet zu werden

Eine nützliche AI-Zusammenarbeitsskala testet Fähigkeiten, die in 45 Minuten beobachtbar sind und die den Engineer unterscheiden, der AI gut nutzt, von demjenigen, der einfach deren Ausgabe kopiert. Vier Dimensionen mit Ankerpunkten auf jedem Level.

1. Prompt-Qualität und Problemzerlegung

Starke Kandidaten bitten das Modell nicht, „das Feature zu bauen." Sie zerlegen das Problem erst, dann promten sie nach dem Teil, bei dem sie Hilfe brauchen. Der erste Prompt des guten Engineers sieht aus wie ein gut abgegrenztes Ticket; der des schwachen Engineers sieht aus wie die ursprüngliche Problemstellung.

Worauf du hören solltest:

• Haben sie das Problem in ihren eigenen Worten umformuliert, bevor sie das Modell gefragt haben?
• Haben sie das Modell eingeschränkt – Dateipfade, Funktionssignaturen, die Datenform, Beispiele der erwarteten Ausgabe?
• Haben sie nach einer Sache nach der anderen gefragt, oder haben sie das ganze Briefing reinkopiert und gehofft?

Ein nützliches Indiz: Wie viele Tokens hat der Kandidat im Prompt geschrieben für jede Zeile Code, die die AI produziert hat? Unter einem bestimmten Verhältnis nutzt der Kandidat das Modell als eine Wunderbox und übt kein Urteilsvermögen über die Eingabe.

2. Verifikation und Skepsis

Dies ist die Dimension, die am häufigsten Starke von Schwachen unterscheidet. Das Modell produziert eine Ausgabe. Was macht der Kandidat damit?

Das stärkste Signal ist, ob der Kandidat verifikationsiert, bevor er integriert. Spezifische Verhaltensweisen:

• Den generierten Code Zeile für Zeile lesen, bevor man ihn einfügt
• Ihn gegen einen Test-Fall laufen lassen, den der Kandidat selbst konstruiert hat (nicht einen, den das Modell vorschlägt)
• Eine halluzinierte Funktion oder Bibliothek erkennen und entweder neu promten oder selbst ersetzen
• Bemerken, dass die Ausgabe plausibel wirkt, aber bei Edge Cases falsch ist

Das schwächste Verhalten ist Kopieren-und-Hoffen: Der Kandidat kopiert den Code des Modells in den Editor, lädt den Happy Path, sieht Grün und geht weiter. Das ist das AI-Zusammenarbeit-Äquivalent eines Junior Engineers, der merged, ohne das Diff zu lesen.

Nutze die gleiche Code-Kohärenz-Analyse, die von LLM generiertem Code in asynchronen Bewertungen gekennzeichnet. In einer AI-erforderlichen Runde ist die Bewertung nicht „hat der Kandidat AI genutzt" – das ist erwartet. Die Bewertung ist, ob die Bearbeitungen des Kandidaten des AI-Outputs Belege dafür zeigen, dass gelesen und nachgedacht wurde, oder ob das Diff reines Kopieren ist.

3. Kontrolle über die Schleife

Junior-Kandidaten folgen der AI, wohin sie führt. Starke Kandidaten führen die AI.

Konkrete Verhaltensweisen zum Bewerten:

• Wenn das Modell eine falsche Antwort zurückgibt, diagnostiziert der Kandidat und promptet mit einer korrigierten Einschränkung neu – oder regeneriert ständig, hoffend auf eine andere Antwort?
• Wenn das Modell eine Architektur vorschlägt, mit der der Kandidat nicht einverstanden ist, widerspricht er („Ich würde hier lieber eine State Machine verwenden, kannst du das mit diesem Pattern umarbeiten?") oder akzeptiert er den Vorschlag?
• Wenn das Modell auf eine Tangente abweicht (etwas refaktorisiert, das der Kandidat nicht gefragt hat), bemerkt der Kandidat es und zieht es zurück?

Diese Dimension ist unsichtbar ohne Screen Recording. Stelle sicher, dass die Runde die Prompt-Historie und den Editor-Diff zusammen erfasst, nicht nur den finalen Code.

4. Kommunikation während der Paarung mit AI

Die letzte Dimension ist, ob der Kandidat den Interviewer im Bild behält. Das klingt soft, aber es ist der höchste-Signal-Prädiktor dafür, wie der Kandidat tagtäglich in einem Team arbeiten wird, das mit AI paart.

Das sieht gut aus:

• Narration bevor man promptet: „Ich werde Claude bitten, den Parser zu entwerfen. Ich erwarte, dass es den Tokenizer richtig macht, aber wahrscheinlich die Escape-Zeichen falsch behandelt – ich werde das reparieren müssen."
• Anzeigen des Prompts, bevor man ihn absendet
• Uneinigkeit mit dem Modell auslaut offenbaren, nicht im Stillen
• Unterscheidung zwischen dem, was sie geschrieben haben, und dem, was das Modell geschrieben hat, wenn man den Code erklärt

Die schwache Version: Stilles Prompting, lange Pausen, während der Kandidat die Ausgabe des Modells liest, ohne zu sagen, was er davon hält, Code, der ohne Erklärung, woher er kommt, im Editor erscheint. Ein Kandidat, der still mit AI codiert, wird still mit Menschen codieren, und das ist ein Team-Dynamik-Signal, das du in der Phase erfassen möchtest.

Die Übung, die diese Fähigkeiten offenbart

Die Versuchung ist groß, dem Kandidaten ein Algorithmus-Problem zu geben und ihn AI nutzen zu lassen. Tu das nicht. Die AI wird es in Sekunden lösen und der Kandidat wird 40 Minuten damit verbringen, Kommentare zu bearbeiten. Du wirst nichts lernen.

Eine bessere Übung hat drei Eigenschaften:

1. Multi-Schritt, mit einer eingebauten Überraschung. Beginne mit einer kleinen Aufgabe, die der Kandidat klar lösen kann. Halbwegs durch, führe eine Änderungsanfrage ein, die eine Annahme bricht – ein neues Datenformat, eine Performance-Einschränkung, eine deprecated Library. Die Anpassung ist, wo die AI-Zusammenarbeit-Fähigkeit auftaucht.
2. Ein subtil fehlerhafter Startpunkt. Gib dem Kandidaten Code, der kompiliert und läuft, aber einen subtilen Bug hat – ein Off-by-One, eine geschluckte Exception, eine Race Condition unter Last. Beobachte, ob er es selbst erkennt oder dem Modell vertraut, es zu finden. Die meisten Modelle werden einen subtilen Bug unprompted nicht finden.
3. Eine Dokumentations- oder Forschungskomponente. Die Aufgabe erfordert, dass der Kandidat mit einer unbekannten Bibliothek oder API integriert. Das Modell kennt sie. Der Kandidat muss verifyieren, was das Modell sagt, gegen die tatsächliche Dokumentation. Die Lücke zwischen „Modell behauptet" und „Docs sagen" ist reichhaltiges Signal.

Fünfundvierzig Minuten für die ganze Runde. Der Collaborative Code Editor von ClarityHire lädt Monaco mit integrierter Ausführung und paart es mit Prompt-Historia-Erfassung, damit der Interviewer während des Debriefings den Editor-Diff und die Modell-Konversation Seite-an-Seite sehen kann – nicht nur den finalen Code.

Scoring-Ankerpunkte, 1 bis 4

Bewerte jede Dimension unabhängig auf einer 1–4-Skala. Verankere die Level in Verhaltensweisen, nicht in Adjektiven.

Prompt-Qualität (1–4):

• 1: Kopiert die ganze Problemstellung ins Modell; keine Zerlegung.
• 2: Fragt nach dem Feature insgesamt, fügt aber mindestens eine Einschränkung hinzu.
• 3: Zerlegt die Aufgabe in zwei oder drei Teile; promptet jeden separat mit relevanten Kontext.
• 4: Schreibt gut abgegrenzte Prompts, die die Funktionssignatur, die Datenform und ein durchgearbeitetes Beispiel enthalten.

Verifikation (1–4):

• 1: Kopiert die Modell-Ausgabe, ohne zu lesen.
• 2: Liest die Ausgabe, aber testet nur den Happy Path.
• 3: Konstruiert mindestens einen Test-Fall, unabhängig von den Vorschlägen des Modells; erkennt mindestens ein Problem.
• 4: Behandelt jede Ausgabe als verdächtig; verifyiert gegen echte Docs, echte Test-Daten und Edge Cases, bevor integriert.

Kontrolle (1–4):

• 1: Folgt allem, was das Modell produziert; regeneriert eher, als neu zu promten, bei Fehler.
• 2: Promptet mit dem gleichen Kontext neu, nach Fehler; erkennt manchmal, wenn das Modell von der Spur abweicht.
• 3: Diagnostiziert, warum das Modell falsch ist, und promptet mit einer korrigierten Einschränkung neu.
• 4: Legt die Architektur selbst fest und nutzt das Modell für taktische Teile; widerspricht, wenn das Modell einen anderen Design-Ansatz vorschlägt.

Kommunikation (1–4):

• 1: Stilles Prompting; Ausgabe erscheint unerklärbar im Editor.
• 2: Narration des Endergebnisses, aber nicht des Prozesses.
• 3: Narration vor dem Prompting und zeigt den Prompt dem Interviewer.
• 4: Unterscheidet deutlich ihren eigenen Beitrag vom Modell; offenbart Uneinigkeiten mit dem Modell auslaut.

Nutze einen strukturierten Scorecard, wo jeder Interviewer seinen Score sperrt, bevor das Debriefing. Die Dimensionen sind unabhängig genug, dass Uneinigkeit informativ ist – ein Interviewer könnte den Kandidaten 4 bei Verifikation und 2 bei Kommunikation bewerten, und dieses Muster ist das Ding, das es wert ist, diskutiert zu werden.

Häufige Interviewer-Fehler

Fünf Fehler, die das Signal in dieser Runde verwässern:

1. Den finalen Code bewerten. Der Code ist der AI. Das Urteilsvermögen, die Prompts und die Bearbeitungen sind des Kandidaten. Bewerte die.
2. Den Kandidaten bitten, „zu erklären, was die AI getan hat." Das testet Leseverständnis, nicht Zusammenarbeit. Frag stattdessen „was würdest du an dem Ansatz der AI ändern?"
3. Die Runde im Stillen laufen lassen. Wenn der Kandidat zwei Minuten lang still ist, während die Ausgabe des Modells gelesen wird, promte sie: „geh mir durch, was du ansiehst." Stille ist nicht der Test; du bewertest, wie sie paaren.
4. Ein Problem zu wählen, das das Modell in einem Durchgang lösen kann. Ein triviales Problem bedeutet, dass der Kandidat nie Kontrolle, Verifikation oder Erholung demonstrieren muss. Wähle ein Problem, das mindestens eine Runde der Uneinigkeit mit dem Modell erfordert.
5. Die Integritäts-Baseline vergessen. Dies ist die AI-erforderliche Runde, aber du bist immer noch in der gleichen Phase wie die AI-verbotene Runde. Wenn die Keystroke-Muster eines Kandidaten in dieser Runde identisch mit der verbotenen Runde aussieht, ist das interessant – sowohl aus guten Gründen (der Kandidat tippt wirklich auf diese Weise) als auch schlechten (der gleiche Off-Camera-Helfer lädt beide Runden).

Was du als nächstes tun solltest

Wenn du dabei bist, eine AI-Zusammenarbeit-Runde zu deiner Phase hinzuzufügen:

1. Entscheide, welche der vier Dimensionen für die spezifische Rolle am wichtigsten sind. Ein angewandter ML-Engineer gewichtet wahrscheinlich Verifikation am höchsten; ein Generalist-Software-Engineer könnte Kommunikation gewichten.
2. Entwerfe eine Übung, die eine Überraschung in der Mitte und einen subtilen Starting Bug einschließt. Schreibe die Ankerpunkte, bevor der erste Kandidat es sieht.
3. Erfasse die Prompt-Historia neben dem Editor-Diff. Ohne die Prompts bewertest du Code; mit ihnen bewertest du den Engineer.
4. Kalibriere mit zwei Interviewern in einer aufgezeichneten Sitzung, bevor du es live laufen lässt. Die Uneinigkeit zwischen ihnen ist die Bewertungsskala.
5. Bewerte diese Runde unabhängig von der AI-verbotenen Runde. Sie messen unterschiedliche Dinge, und die Vermischung wird den falschen Kandidaten belohnen.

Das Ziel dieser Runde ist nicht, Kandidaten zu finden, die AI nutzen können – fast alle Kandidaten können das. Es ist, die zu finden, deren Urteilsvermögen, Verifikation und Richtung gut genug sind, dass der Leverage der AI echt wird, anstatt teuer Kopieren-und-Hoffen.