Ingenieure bei KI-gestütztem Programmieren interviewen: Ein praktischer Leitfaden

Die Kompetenz, die niemand abfragt

Mitte 2026 nutzen die meisten Ingenieure einen KI-Assistenten für einen Teil ihrer täglichen Arbeit. Die Frage, die Ihr Interview beantworten sollte, ist nicht „kann dieser Kandidat ohne KI programmieren" — das ist eine hypothetische Frage. Sie lautet: „kann dieser Kandidat schneller und sicherer mit KI arbeiten als der Ingenieur neben ihm?"

Das ist eine andere Kompetenz, und sie erfordert ein anderes Interview. Eine Hausaufgabe mit versteckter No-AI-Regel misst sie nicht. Ein LeetCode-Test misst sie nicht. Selbst die meisten offenen Notizbuch-Formate lassen einen Kandidaten durchkommen, indem die KI wie eine aufgepimpte Suchmaschine behandelt wird. Im Folgenden finden Sie einen praktischen Leitfaden zur Gestaltung einer Runde, die die KI-Kompetenz direkt misst und bewertet, ohne Theater zu belohnen.

Wie KI-Kompetenz wirklich aussieht

Beobachten Sie einen starken Ingenieur, der eine Stunde lang mit einem Assistenten arbeitet. Sie werden sehen, wie er fünf Dinge tut:

1. Die Anfrage um Einschränkungen, nicht um Lösungen rahmen. Er erklärt dem Modell, was der Code tun muss und nicht tun darf, und iteriert dann.
2. Selbstbewusst ablehnen. Wenn das Modell etwas subtil Falsches vorschlägt — eine falsche API-Version, eine erfundene Bibliothek, ein fragiles Muster — erkennt er es innerhalb von Sekunden und steuert dagegen.
3. Den Assistenten vor allem bei den langweiligen Teilen einsetzen. Boilerplate, Test-Scaffolding, Format-Konvertierungen — hochgradig sinnvolle Anwendungen. Er schreibt die tragende Logik selbst oder gibt dem Modell eine enge Spezifikation vor.
4. Vor dem Vertrauen verifizieren. Er führt den Code aus, liest den Diff und prüft die Randfälle. Er committed nicht aus dem Bauchgefühl heraus.
5. Wissen, wann man es nicht mehr braucht. Wenn das Modell im Kreis läuft, wechselt er zurück zum Nachdenken und Lesen.

Ein schwacher KI-Nutzer macht das Gegenteil: stellt breite Fragen, akzeptiert lange Generationen unkritisch, lässt das Modell die Lösung entwerfen, und deployed was immer funktioniert. Die Aufgabe des Interviews ist es, diese beiden zu unterscheiden.

Das Frageformat, das es enthüllt

Die Form der Frage ist wichtiger als das spezifische Problem. Wählen Sie eine mit diesen Eigenschaften:

• Die naive KI-Antwort ist subtil falsch. Nicht als Trick — eine echte Einschränkung, die der Kandidat bemerken muss. Eine häufige Variante: Sie bitten ihn, etwas gegen eine neuere oder ungewöhnliche API zu implementieren, wo die Trainingsdaten des Modells veraltet sind.
• Das Problem ist zu groß für einen Kandidaten ohne KI zum Fertigstellen, und zu subtil für einen Kandidaten mit voller KI zum Durchschießen. Dies zwingt zu beiden Werkzeugen und Urteilskraft.
• Die Akzeptanzkriterien sind eindeutig. Nicht „etwas Nettes bauen" — explizite Muss-Haves, die der Kandidat überprüfen kann.
• Es gibt eine absichtliche Mehrdeutigkeit in der Spezifikation. Ein vernünftiger Ingenieur würde sie durch Nachfragen oder durch eine Annahme auflösen. Ein schwacher KI-Nutzer fügt die Spezifikation in das Modell ein und deployed, was immer herauskommt.

Ein funktionierendes Beispiel: „Schreiben Sie ein kleines Programm, das eine CSV-Datei mit Bestellungen liest, monatliche Gesamtsummen pro Kunde berechnet und JSON ausgibt. Zwei Mehrdeutigkeiten, die Sie klären sollten: Zeitzonen von Bestellungen und wie man Rückgabezeilen behandelt. 60 Minuten. Welches Werkzeug Sie auch immer möchten."

Live durchführen, nicht asynchron

Eine rein asynchrone Hausaufgabe kann die beiden Profile nicht unterscheiden. Das Artefakt sieht in beiden Fällen gleich aus. Führen Sie dies als eine 60–75-minütige Live-Programmier-Session mit Screen Share oder einem kollaborativen Editor durch, mit expliziter Erlaubnis zur Nutzung von KI.

Grundregeln, die von Anfang an angekündigt werden:

• Jedes KI-Werkzeug ist zulässig. Sagen Sie uns, welche Sie verwenden.
• Wir werden für die Nutzung von KI nicht abzüglich nehmen. Wir werden hinterfragen, wie Sie sie nutzen.
• Wir werden hinterfragen, was die KI Ihnen gegeben hat. Seien Sie bereit, alles zu erklären, was Sie behalten.

Dieser Rahmen verlagert den Kandidaten von defensiv zu demonstrativ. Starke Kandidaten sind dabei. Schwache bekommen Angst, weil ihr Arbeitsablauf einer Überprüfung nicht standhält.

Was man in Echtzeit beobachten sollte

Fünf konkrete Signale während der Session:

• Prompt-Qualität. Erklären sie Einschränkungen, Beispiele und die Form der gewünschten Ausgabe? Oder fügen sie die Spezifikation ein und hoffen?
• Ablehnungsquote. Wie oft verwerfen sie eine Generation? Starke Ingenieure lehnen mindestens ein paar ab — manchmal still, manchmal laut. Ingenieure, die alles behalten, lesen nicht, was sie verschieben.
• Wo sie KI allein lassen. Schreiben sie die kritische Logik selbst? Oder lassen sie den Assistenten den Teil übernehmen, der die Korrektheit bestimmt?
• Verifikationsgewohnheiten. Führen sie den Code mit echten Eingaben aus? Lesen sie den Diff vor der Annahme? Schauen sie sich Randfälle an?
• Wiederherstellung. Wenn das Modell im Kreis läuft, treten sie einen Schritt zurück und denken nach, oder fördern sie weiterhin?

Diese sind in einem 60-Minuten-Fenster beobachtbar, wenn Sie die Tastenanschläge beobachten, nicht nur das Artefakt. Der kollaborative Editor von ClarityHire zeichnet die gesamte Session mit separat gekennzeichneten Paste-Events auf — nützlich, wenn Sie sich während des Durchgangs eine bestimmte Wahl mit dem Kandidaten ansehen möchten.

Ein Bewertungsschema

Fünf Dimensionen, je 1–4, vor der Besprechung bewertet:

Bewerten Sie jede unabhängig. Die strukturierten Interviews von ClarityHire sperren diese Bewertungskarten, damit die Reviewer nicht abdriften, nachdem sie das Artefakt sehen.

Der Post-Session-Durchgang

Verbringen Sie die letzten 15 Minuten mit drei Fragen:

1. „Zeigen Sie mir eine Generation, die Sie abgelehnt haben. Warum?"
2. „Führen Sie mich durch den Teil davon, den Sie selbst geschrieben haben, und warum Sie die KI nicht machen lassen haben."
3. „Welcher ist der fragilste Teil von dem, was wir versendet haben? Was würden Sie als nächstes beheben?"

Kandidaten, die während der Session tatsächlich nachgedacht haben, können diese ohne zu zögern beantworten. Kandidaten, die alles akzeptiert haben, was das Modell produziert hat, können nicht — und die Lücke zeigt sich in den ersten zehn Sekunden jeder Antwort. Dies ist derselbe Urheberschaftstest, den Sie bei einer Hausaufgabe durchführen würden, angewendet auf die Live-KI-Nutzung.

Wo dies in die Schleife passt

Behandeln Sie diese Runde als Ersatz für den Standard-Live-Coding-Screen, nicht als Zusatz. Ihre Schleife sollte weiterhin eine System-Design-Runde und eine verhaltensbezogene Runde enthalten; die Frage, die diese Runde beantwortet, ist diejenige, die früher vom geschlossenen Coding-Screen beantwortet wurde, der in der LLM-Ära die meisten seiner Signale verloren hat.

Was zu tun ist

Drei konkrete Maßnahmen vor Ihrem nächsten KI-zugelassenen Round:

1. Wählen Sie eine Rolle und schreiben Sie die Live-Coding-Frage um auf eine, die KI nicht durchschießen kann, die aber ein Kandidat ohne KI nicht fertigstellen kann.
2. Trainieren Sie Ihre Interviewer, den Arbeitsablauf zu bewerten, nicht das Artefakt. Das Artefakt ist jetzt Table Stakes. Der Arbeitsablauf ist das Signal.
3. Entscheiden Sie vorher, was „verifiziert" bedeutet. Das Sperren des Schemas im Voraus verhindert die nachträgliche Rationalisierung, die die Kalibrierung ruiniert.

Die Teams, die dies 2026 richtig hinbekommen, werden die Teams übertrumpfen, die so tun, als wäre das Modell nicht im Raum. Die Kompetenz ist real, der Unterschied zwischen starken und schwachen Benutzern ist enorm, und das Interview-Format, um es zu messen, ist nicht schwieriger durchzuführen als das, das es ersetzt.