Code-Review-Interview: Fragen, Bewertungsschema und warum es Algorithmen schlägt

Was ein Code-Review-Interview wirklich ist

Ein Code-Review-Interview ist genau das, was es klingt: dem Kandidaten wird ein funktionierendes Pull-Request gegeben – 100 bis 400 Zeilen, eine einzelne Funktion oder Fehlerbehebung – und er wird gebeten, es zu überprüfen, als hätte es ein Teamkollege eröffnet. Sie markieren Probleme, schlagen Änderungen vor und führen den Interviewer durch ihre Argumentation. Manchmal gibt es absichtliche Fehler. Immer gibt es Ermessensentscheidungen.

Es ist das am wenigsten genutztes Format in der technischen Einstellung. Die meisten Prozesse greifen immer noch auf eine Whiteboard-Algorithmen-Runde oder einen Take-Home-Build zurück. Beide sind gute Signale für bestimmte Dinge. Keines testet die Fähigkeit, auf die Ingenieure nach ihrer Einstellung die meiste Zeit verwenden.

Warum es die Algorithmen-Runde schlägt

Drei Gründe, in der Reihenfolge ihrer Auswirkungen.

1. Es testet die eigentliche Arbeit. Ingenieure verbringen mehr Zeit mit der Überprüfung von Code als mit dem Schreiben von Grund auf. Ein Prozess, der die Überprüfungsfähigkeit nicht misst, misst die falsche Dimension und nennt sie Ingenieurwesen.
2. Es ist schwierig, mit KI zu fälschen. LLMs können den Diff schreiben. Sie haben Schwierigkeiten zu argumentieren, warum eine Funktion aufgeteilt werden sollte, wenn ein erfahrener Reviewer einen vertretbaren Fall für die andere Seite hat. Das Signal liegt in dem Hin-und-Her, wo KI-gestützte Kandidaten zusammenbrechen.
3. Es skaliert über alle Erfahrungsstufen. Junior-Ingenieure bemerken Syntax und Bugs. Mid-Level-Ingenieure bemerken die Struktur. Senior-Ingenieure bemerken die Designentscheidungen, die der Diff verbirgt (was gelöscht wurde, was bewusst nicht geändert wurde). Gleiches Artefakt, sehr unterschiedliche Lesarten – das bedeutet, dass ein PR Interviews von L3 bis L6 mit angepassten Rubrik-Gewichtungen statt separater Fragenpools durchführen kann.

Dies ist das Format, das Teams wählen, wenn sie erkannt haben, dass LeetCode nicht vorhersagbar ist und ein reines Work-Sample-Take-Home zu teuer ist, um es in großem Volumen am Anfang des Trichters einzusetzen.

So wählen Sie die Codebasis

Der PR, den Sie verwenden, bestimmt, ob das Interview Urteilsfähigkeit oder Triviales misst. Drei Dinge sind wichtig:

• Verwenden Sie echten, anonymisierten Code. Ein Spielzeug-Snippet mit drei offensichtlichen Bugs trainiert Kandidaten, nach Tricks zu suchen. Ein echter Diff mit Änderungen gemischter Qualität zwingt sie tatsächlich zu lesen.
• Wählen Sie eine Domäne, die der Kandidat nicht auswendig gelernt hat. Vermeiden Sie eine TODO-App oder einen LeetCode-ähnlichen Algorithmus. Verwenden Sie etwas mit Geschäftslogik – eine Preisregel, eine Berechtigungsprüfung, eine Wiederholungsrichtlinie. Domänenkompetenz ist nicht das Signal.
• Stellen Sie sicher, dass es mindestens eine vertretbare Ermessensentscheidung gibt. Das beste Code-Review-Interview hat null „falsche" Antworten und drei Stellen, an denen ein nachdenklicher Reviewer in beide Richtungen Einwände erheben könnte. Dort messen Sie die Erfahrungsstufe.

Bestücken Sie die Runde mit dem Diff, der in einem echten Editor geladen ist – nicht in einem statischen PDF. Die kollaborativen Coding-Räume von ClarityHire öffnen die Datei mit Anmerkungen und einem Kommentar-Thread, den der Interviewer in Echtzeit beobachten kann, damit sich die Überprüfung wie ein normales GitHub-PR anfühlt und nicht wie ein Verhör.

Das vierdimensionale Bewertungsschema

Leihen Sie sich die Struktur aus einem System-Design-Bewertungsschema, aber bauen Sie die Dimensionen für Review-Arbeit neu auf.

1. Problemidentifikation

Haben sie die Dinge gefangen, die eine echte Überprüfung erfassen würde? Bewertung nach Dichte und Schweregrad:

• 4 — das kritische Problem gefangen (Sicherheit, Korrektheit oder Architektur) plus die kleinen Dinge
• 3 — das kritische Problem oder die meisten kleinen Dinge gefangen
• 2 — oberflächliche Probleme gefangen, aber das strukturelle Problem verpasst
• 1 — das kritische Problem verpasst und Formatierung kritisiert

2. Priorisierung

Zwei Probleme haben niemals das gleiche Gewicht. Bewertung, ob der Kandidat zwischen „das ist ein Bug", „das könnte sauberer sein" und „ich würde dies nicht blockieren" unterscheidet. Erfahrene Ingenieure verankern Reviewer um die Bugs; Junior-Ingenieure behandeln jeden Kommentar als gleich-priorisiert.

3. Qualität der Begründung

Können sie für jeden Kommentar, den sie hinterlassen, den Kompromiss artikulieren? „Ich würde diesen Helper extrahieren" ist ein B-Tier-Kommentar. „Ich würde diesen Helper extrahieren, weil die gleiche Logik im Bestellstornierungsfluss erscheint und wir möchten, dass sie zusammen weiterentwickelt werden" ist die Version eines erfahrenen Ingenieurs. Bewertung nach Spezifität, nicht Wortschatz.

4. Ton und Zusammenarbeit

Code Review ist eine Beziehungsfähigkeit. Ein Reviewer, der technisch richtig ist, aber Kommentare schreibt, die Ihr Team nicht mag, ist ein Nachteil. Bewertung für: landet der Kommentar als Vorschlag, auf den der Autor einwirken kann, oder als Kritik?

Dies ist die Dimension, die die meisten Interview-Formate überhaupt nicht messen können. Code-Review-Interviews bringen sie sauber zum Vorschein.

Beispielfragen zum Verankern des Gesprächs

Dies sind die Aufforderungen, die Interviewer bis nach dem ersten Durchgang des Kandidaten zurückhalten sollten:

• „Führen Sie mich durch die Kommentare, die Sie tatsächlich posten würden, in der Reihenfolge, in der Sie sie posten würden."
• „Welchen einzelnen Kommentar würden Sie blockierend machen?"
• „Wenn der Autor gegen Ihren größten Kommentar argumentiert, was ist Ihr zweitbestes Argument?"
• „Was ist nicht in diesem Diff, das sein sollte? Was würden Sie in der PR-Beschreibung fragen?"
• „Was würden Sie nicht ansprechen, obwohl Sie es bemerkt haben?"

Die letzte Frage ist die am stärksten zwischen erfahrenen und unerfahrenen Kandidaten unterscheidende in der Reihe. Zu wissen, was man ignorieren kann, ist die Hälfte einer effektiven Code-Überprüfung.

So bewerten Sie eine offene Überprüfung

Das Interview produziert vielfältige Artefakte – Inline-Kommentare, ein Transkript des mündlichen Durchgangs, manchmal eine schriftliche Zusammenfassung. Drei Regeln für konsistente Bewertung:

• Verwenden Sie pro Rolle ein gemeinsames Bewertungsschema. Bauen Sie es einmal aus Ihrer Bewertungsschema-Bibliothek auf und verwenden Sie es wieder für Kandidaten.
• Bewerten Sie das Artefakt und das Gespräch separat. Ein Kandidat, der großartige Kommentare schrieb, aber in der Live-Diskussion schlecht argumentierte, ist ein anderer Einstellungsfall als einer, der es umgekehrt tat.
• Führen Sie eine reine Schrift-Runde in großem Maßstab durch, live persönlich für Finalisten. KI-gestützte Bewertung der schriftlichen Kommentare gibt einen nützlichen ersten Durchgang in Bezug auf Dichte und Spezifität am Anfang des Trichters, wo Sie sich keine Live-Zeit leisten können. Die Live-Runde erfasst das Gesprächssignal, das die automatisierte Bewertung nicht erfasst.

KI-Unterstützung während der Runde widerstehen

Wenn der Kandidat den Diff in einem anderen Tab durch Claude oder GPT führt, sind die Kommentare, die er einfügt, technisch dicht, aber stilistisch inkonsistent mit seiner eigenen Argumentation in der Diskussion. Zwei Wege, das zu erfassen:

• Beobachten Sie das Bearbeitungsmuster – saubere, große Einfügungen strukturierter Prosa, gefolgt von Stille, sind das Zeichen, genau wie in einer Coding-Runde
• Machen Sie die Live-Diskussion obligatorisch und kontradiktorisch: Wählen Sie den stärksten Kommentar des Kandidaten und argumentieren Sie dagegen. Von KI verfasste Kommentare brechen zusammen, wenn der Kandidat die spezifische Formulierung, die er gewählt hat, nicht verteidigen kann.

Sie müssen KI nicht verbieten, damit die Runde funktioniert. Sie müssen sie so gestalten, dass ein nur auf KI gestützter Kandidat die Gesprächshälfte nicht bestehen kann.

Was man als nächstes tun sollte

Wählen Sie einen PR aus Ihrer Codebasis, anonymisieren Sie ihn und führen Sie die Runde nächste Woche mit zwei aktuellen Ingenieuren durch. Lassen Sie sie den Diff kalt überprüfen und sich selbst gegen das Schema bewerten. Jeder Unterschied zwischen ihrer Bewertung und Ihrem Bauchgefühl, wie sie tatsächlich bei der Arbeit überprüfen, ist der Unterschied, den Ihr Schema behebt. Führen Sie es dann in Ihrem nächsten Einstellungsprozess aus und vergleichen Sie die Kandidatenbewertungen mit Ihren bestehenden Coding-Assessment-Ergebnissen. In unserer Kundenbasis verschiebt sich die Rangfolge – und die neue Ordnung passt besser zu denen, die nach der Einstellung tatsächlich funktionieren.