Wie Sie im KI-Zeitalter echtes Können bei Engineers erkennen

Um im Zeitalter, in dem KI die Antworten vortäuschen kann, echtes Können bei Engineers zu erkennen, erlauben Sie KI im Assessment und bewerten Sie, wie die Kandidatin oder der Kandidat sie steuert, überprüft und korrigiert. Geben Sie eine Debug-und-Erweitern-Aufgabe an Code, den die Person nicht selbst geschrieben hat, und arbeiten Sie dann mit einem strukturierten Bewertungsraster, das Argumentation, Validierung des Outputs und das Abwägen von Trade-offs höher gewichtet als die reine Korrektheit des Ergebnisses. Der Flaschenhals der Arbeit hat sich vom Schreiben des Codes zum Überprüfen des Codes verschoben – Ihr Interview sollte also genau diese Überprüfung messen.

Sie können die beiden Kandidaten nicht mehr an ihren Einreichungen unterscheiden. Der eine steuert einen KI-Assistenten mit Urteilsvermögen, fängt seine Fehler ab und liefert etwas Solides. Der andere gibt demselben Modell einen Prompt, bekommt Code, der funktionsfähig aussieht, und hat keine Ahnung, dass er falsch ist. Beide bestehen das Take-Home. Der Unterschied zeigt sich erst später: in der Produktion, in den Code-Reviews und im Vertrauen, das Ihr Team verliert. Das ist ein Problem des Assessment-Designs, und es lässt sich lösen, ohne KI zu verbieten oder Detektiv zu spielen. Den größeren Marktwandel dahinter beleuchten wir im Gesamtbild zum Kollaps der Abschlüsse als Qualifikationsnachweis.

Das Angebotsproblem, das Einstellungsteams gerade geerbt haben

Der Bewerberpool füllt sich zunehmend mit Engineers, die mit einem Assistenten liefern, aber ohne ihn nicht denken können. Der deutlichste Beleg kommt von den Institutionen, die sie ausbilden: Die Durchfallquoten sind sprunghaft gestiegen, und Lehrende benennen die exzessive KI-Nutzung öffentlich als Ursache.

Im Frühjahrssemester 2026 erreichte die Durchfallquote im Kurs CS 10 der UC Berkeley 35,3 % – nach unter 10 % in den Frühjahrssemestern 2024 und 2025, so die Notendaten, über die der Daily Californian berichtet. CS 61A verzeichnete 10,6 % „F“-Noten, EECS 127 16,8 %. Der Notendurchschnitt des Semesters fiel auf etwa ein „C+“ (2,3 GPA) – deutlich unter dem Richtwert des Fachbereichs von 2,8 bis 3,3.

Lehrprofessor Dan Garcia führte den Einbruch auf eine „enorme Zunahme akademischer Unehrlichkeit“ durch den Einsatz großer Sprachmodelle zurück und verwies auf knapp 30 Studierende, die allein in CS 10 beim Schummeln in Take-Home-Prüfungen erwischt wurden. Professorin Gireeja Ranade beobachtete, dass Studierende mit den Grundlagen der linearen Algebra kämpften; einer berichtete, in seinem Kurs für lineare Algebra habe bei Hausaufgaben und Prüfungen eine „Open-Internet-, Open-KI-Politik“ gegolten. Mehr als 1.300 Lehrende der University of California haben seither eine Petition unterzeichnet, die die Wiedereinführung von SAT und ACT für MINT-Zulassungen fordert.

Dieser Kurs mit „Open-KI-Politik“ für lineare Algebra ist das ganze Problem im Kleinen. KI half Studierenden nicht nur, in einer CS-Prüfung zu schummeln. Sie kaschierte die fehlenden Grundlagen eine Ebene weiter oben, sodass jemand einen Kurs besteht, dessen Voraussetzungen er nie wirklich verinnerlicht hat. Wenn diese Person in Ihrer Pipeline ankommt, ist die Lücke auf dem Papier unsichtbar – und tritt erst zutage, wenn etwas kaputtgeht und der Assistent falsch liegt.

Warum ein KI-Verbot im Interview den Job falsch misst

Ein KI-Verbot im technischen Interview testet einen Workflow, den kein Engineer im Arbeitsalltag mehr nutzt. Es optimiert Ihr Assessment für eine Fähigkeit, die der Job isoliert nicht mehr belohnt – und obendrein lässt es sich nicht durchsetzen.

KI ist heute fest in die normale Entwicklung eingewoben. Sonars State of Code Developer Survey 2026, basierend auf mehr als 1.100 Entwicklerinnen und Entwicklern, ergab, dass 42 % des eingecheckten Codes bereits KI-generiert oder KI-unterstützt sind – mit einer Prognose von 65 % bis 2027. Bei Google berichtete CEO Sundar Pichai in einem Update vom April 2026, dass rund 75 % des neuen Codes KI-generiert und von Engineers überprüft werden – nach 50 % im Herbst zuvor (berichtet über die Exponent- und Tekedia-Berichterstattung zum internen Programm). Wenn drei Viertel des neuen Codes in einer der führenden Engineering-Organisationen mit einem Assistenten beginnen, dann misst ein Interview, das den Assistenten verbietet, eine Fiktion.

Engineering-Führungskräfte spüren den Messfehler bereits. Karats AI Workforce Transformation Report 2025–2026, gestützt auf 400 Engineering-Führungskräfte aus den USA, Indien und China, fand heraus, dass 71 % sagen, KI mache technische Fähigkeiten schwerer einschätzbar. Derselbe Report hält fest, dass starke Engineers heute mit dem Drei- oder Mehrfachen ihrer Gesamtvergütung bewertet werden – was die Kosten in die Höhe treibt, wenn das Screening danebengeht. Die Branche reagiert, indem sie KI erlaubt statt verbietet: Laut der IEEE-USA-Analyse vom April 2026 gestatten inzwischen rund 38 % der Organisationen KI in technischen Interviews, in New York liegt die Verbreitung bei Arbeitgebern nahe 25 % mit Prognose Richtung 50 %. Unternehmen wie Canva, Rippling, Red Hat, Meta und Shopify erlauben sie bereits.

Warum „den Schummler überführen“ ein aussichtsloses Wettrüsten ist

Der Versuch, KI-Nutzung zu ertappen, ist ein Kampf, den Sie immer wieder verlieren werden. Die Erkennungswerkzeuge hinken den Schummelwerkzeugen hinterher, und die Lücke wird größer – jede Strategie nach dem Motto „verbieten und erwischen“ veraltet also in dem Moment, in dem Sie sie einführen.

Die Zahlen sind ernüchternd. Laut Fabric, das mehr als 50.000 Kandidaten analysiert hat, hat sich das KI-Schummeln bei Take-Home-Aufgaben mehr als verdoppelt – von 15 % im Juni 2025 auf 35 % im Dezember 2025. Moderne Tools lösen Standard-Take-Homes in unter fünf Minuten und blenden Antworten über unsichtbare GPU-Overlays ein, die in keiner Bildschirmübertragung auftauchen. Fabric berichtet, dass 59 % der Personalverantwortlichen bereits vermuten, dass in Assessments KI zum Einsatz kommt, und Karats Führungskräfte schätzen, dass mehr als die Hälfte der Kandidaten KI nutzt, selbst wenn es untersagt ist. Mit Blick nach vorn prognostiziert Gartner, dass bis 2028 jedes vierte Bewerberprofil gefälscht sein wird – zusammengesetzt aus synthetischem Text, Stimme oder Deepfakes (zitiert über Fabric).

Sie können ein Rendering-Wettrüsten gegen Software, die sich vor jeder Bildschirmübertragung versteckt, nicht gewinnen. Also hören Sie auf, es zu versuchen. Das Scheitern der Erkennung ist kein Grund zu verzweifeln; es ist das Argument dafür, zu ändern, was Sie messen. Wenn Sie nicht zuverlässig feststellen können, ob KI eingesetzt wurde, dann gestalten Sie ein Assessment, bei dem es egal ist – denn KI gut zu nutzen ist genau das, was Sie beobachten wollen.

Das eigentliche Signal hat sich von der Erzeugung zur Überprüfung verschoben

Die knappe Fähigkeit ist nicht mehr das Produzieren von Code. Sie besteht darin, zu beurteilen, ob der von einem Assistenten produzierte Code tatsächlich korrekt ist – und ihn zu korrigieren, wenn er es nicht ist. Sonar benennt das direkt: Der Nettoeffekt von KI ist ein „Verifikations-Flaschenhals“, kein reiner Produktivitätsschub.

Die Daten hinter diesem Begriff sind ernüchternd. In Sonars Umfrage vertrauen 96 % der Entwicklerinnen und Entwickler KI-generiertem Code nicht voll und ganz, doch nur 48 % überprüfen ihn immer, bevor sie committen, und 38 % sagen, das Prüfen von KI-Code sei aufwendiger als das Prüfen von Code eines Menschen. Die Verifikationskosten verschwinden auch beim QA-Prüfschritt nicht. Lightruns State-of-AI-Powered-Engineering-Report 2026 fand heraus, dass 43 % der KI-generierten Code-Änderungen auch nach bestandenem QA und Staging noch manuelles Debugging in der Produktion erfordern (berichtet über VentureBeat).

Lesen Sie diese beiden Fakten zusammen. Ein großer und wachsender Anteil des Codes ist KI-generiert, und ein großer Anteil davon ist auf subtile Weise falsch – auf Arten, die automatisierte Prüfungen überstehen und in die Produktion gelangen. Wer in dieser Welt Wert schafft, ist die Person, die den Output kritisch liest, eine minimale Reproduktion baut, die Logs prüft und einen Fix beweist, statt dem Modell zu vertrauen. Eben diese Fähigkeit muss Ihr Interview ans Licht bringen. Wenn der Flaschenhals des Jobs die Überprüfung ist, sollte das Assessment die Überprüfung messen.

Was Sie wirklich messen sollten: steuern, überprüfen, korrigieren

Hören Sie auf zu bewerten, ob jemand eine korrekte Funktion produziert hat. Beginnen Sie zu bewerten, wie Kandidaten den Assistenten steuern, seinen Output überprüfen und wieder auf Kurs kommen, wenn er danebenliegt. Das ist das Modell, das die führenden Programme bereits übernommen haben, und es lässt sich sauber auf einen Interviewprozess in Startup-Größe übertragen.

In Googles KI-unterstütztem Pilotprogramm ist ein freigegebener Assistent in der Coding-Runde für Junior- und Mid-Level-Rollen in den USA erlaubt; bewertet wird „KI-Fluency, einschließlich Prompt Engineering, Output-Validierung und Debugging-Fähigkeiten“. Entscheidend: Bewerberinnen und Bewerber, die sich „stark auf KI verlassen, ohne ihr eigenes Verständnis zu zeigen“, erhalten negatives Feedback. Diese eine Designentscheidung ist die ganze These: Kompetenz bringt Punkte, Abhängigkeit kostet sie. DoorDash ging noch weiter und ersetzte seine klassische Coding-Runde durch eine 60-minütige KI-unterstützte Arbeitssitzung an einem realistischen Projekt, bewertet nach „Tooleinsatz, Debugging-Ansatz, Urteilsvermögen und Kommunikation unter realen Bedingungen“. DoorDashs Engineering-Team sagt klar: „Die wahren Unterscheidungsmerkmale sind Entscheidungsfindung, Denken auf Systemebene und Ownership.“

Interview-Leitfäden von Programmen wie Formation und Sierra kommen zur selben Beschreibung von Validierung: Starke Kandidatinnen und Kandidaten „erstellen eine minimale Reproduktion, lesen die Logs und schreiben gezielte Checks, um zu beweisen, dass ein Fix funktioniert, statt dem KI-Output blind zu vertrauen“. Zwei Aufgabenformate machen das am besten sichtbar.

Die Debug-und-Erweitern-Aufgabe an Code, den die Kandidaten nicht geschrieben haben

Die aussagekräftigste Einzelübung ist das Lesen und Reparieren von Code, den die Kandidatin oder der Kandidat nicht selbst geschrieben hat. „Können Sie den Code von jemand anderem lesen, finden, was falsch ist, und es beheben?“ ist die Frage, die eine KI-Abhängigkeit nicht vortäuschen kann – denn die Arbeit besteht aus Überprüfung, nicht aus Erzeugung. Geben Sie eine kleine, teilweise funktionierende Codebasis mit einem eingebauten logischen Fehler vor – der Sorte Bug, die korrekt aussieht und einen naiven Test besteht. Bitten Sie die Person dann, ihn zu finden, zu beheben und das System um ein realistisches Feature zu erweitern.

KI ist ausdrücklich erlaubt. Worauf Sie achten: wie sie sich in unbekanntem Code orientiert, ob sie den Bug reproduziert, bevor sie ihn „behebt“, ob sie dem ersten Vorschlag des Assistenten vertraut oder ihn prüft – und wie sie reagiert, wenn das Modell mit voller Überzeugung etwas Falsches vorschlägt. Abhängige Kandidaten fügen die Fehlermeldung in einen Prompt ein und liefern, was zurückkommt. Kompetente nutzen den Assistenten, um schneller voranzukommen, und verantworten dabei jede Entscheidung selbst.

Das System-Design-Gespräch, das Trade-offs erzwingt

Kombinieren Sie die Debugging-Aufgabe mit einer System-Design-Diskussion, die explizites Abwägen von Trade-offs erzwingt. Nicht „entwirf Twitter“, sondern eine eng umrissene, konkrete Entscheidung: Wie würden Sie das cachen, wo bricht es unter Last, was geben Sie auf, wenn Sie die einfachere Option wählen? KI kann ein Architekturdiagramm skizzieren. Was sie im laufenden Gespräch nicht kann: eine Entscheidung verteidigen, wenn Sie nachbohren, und nachjustieren, wenn Sie eine Bedingung hinzufügen. Das Gespräch zeigt, ob die Denkleistung vom Kandidaten stammt oder vom Modell.

Das Bewertungsraster: fünf Kriterien, die zählen

Halten Sie das Raster kurz, verhaltensbasiert und stärker auf Urteilsvermögen als auf Output gewichtet. Bewerten Sie alle Kandidaten nach denselben fünf Kriterien, damit das Signal über Ihre gesamte Pipeline vergleichbar bleibt.

1. Steuert KI gut. Klare, gezielte Prompts; weiß, was zu erfragen ist und warum, statt das ganze Problem hineinzutippen und auf das Beste zu hoffen.
2. Überprüft den Output. Reproduziert, liest Logs, schreibt gezielte Checks; committet nicht auf gut Glück.
3. Korrigiert KI-Fehler. Erkennt den plausibel-aber-falschen Vorschlag und erklärt, warum er falsch ist.
4. Denkt über Trade-offs nach. Verteidigt Entscheidungen, wägt Alternativen ab, passt sich neuen Bedingungen an.
5. Kommuniziert und übernimmt Verantwortung. Erzählt den Denkprozess mit, steuert den Umfang, steht für das Ergebnis ein.

Warum Arbeitsproben Abschlüssen und LeetCode überlegen sind

Eine nachgewiesene Arbeitsprobe gehört zu den aussagekräftigsten Signalen, die in der Personalauswahl je gemessen wurden – und das gilt seit 25 Jahren. Die klassische Metaanalyse von Schmidt und Hunter (1998) aus der Personalpsychologie beziffert die Validität von Arbeitsproben auf rund 0,54 und die Validität strukturierter Interviews auf rund 0,51, wobei die Kombination aus allgemeiner kognitiver Fähigkeit und Arbeitsprobe bei nahezu 0,63 liegt. Eine spätere Revision von Roth, Bobko und McFarland (2005) setzt Arbeitsproben eher bei 0,33 an – immer noch weit über den schwachen Ersatzindikatoren.

Die schwachen Ersatzindikatoren sind genau jene, die KI gerade entwertet. Lebensläufe, Berufsjahre und ungeprüfte Abschlüsse rangieren am unteren Ende der Validitätstabellen, und das Abschluss-Signal verfällt in Echtzeit, wie die Berkeley-Noten zeigen. Auswendig gelernte Algorithmus-Rätsel schneiden nicht besser ab: Eine Live-LeetCode-Runde ist genauso KI-fälschbar und genauso signalarm wie ein Take-Home – weshalb LeetCode-artige Screenings obsolet werden. Die Lehre ist über Forschung und Markt hinweg durchgängig dieselbe. Beobachten Sie die Person bei realistischer Arbeit und beim Nachdenken darüber. Verlassen Sie sich nicht darauf, dass ein Abschluss diese Arbeit für Sie erledigt.

Es gibt zudem eine Fairness-Dividende. DoorDash berichtet, dass KI-unterstützte Formate „Engineers mit nicht-traditionellem Hintergrund wirklich glänzen“ lassen, weil der Assistent die Ausführungslücke schließt und die Runde Urteilsvermögen misst – das sich aus Mathematik, Physik oder dem Selbststudium übertragen lässt. KI zu erlauben ist kein Zugeständnis an Schummler. Es weitet den Trichter für Menschen, die gut denken, aber nicht den Standard-CS-Weg gegangen sind.

So bauen Sie das in Ihrer eigenen Pipeline auf

Sie brauchen weder einen ausgelagerten Interview-Dienst noch einen Proctoring-Anbieter, um das umzusetzen. Sie brauchen zwei Phasen, einmal konfiguriert: eine KI-erlaubte Code-Aufgabe rund um die Überprüfung und ein strukturiertes Live-Auswertungsgespräch mit einem echten Bewertungsraster. Genau diese Lücke füllt Kit für Teams in Startup-Größe. Für Einstiegspositionen liefert die Vorlage „Junior Engineer Pipeline“ beide Phasen bereits vorkonfiguriert mit.

Kit ist ein KI-natives ATS mit einer konfigurierbaren, phasenbasierten Pipeline, und zwei bestehende Phasentypen passen exakt auf dieses Design. Die Code-Aufgaben-Phase ist GitHub-Template-gestützt – statt eines Greenfield-„Baue X“-Prompts stellen Sie ein Debug-diese-Codebasis-/-Erweitere-dieses-Teilsystem-Template bereit, also genau die Aufgabenform, die Überprüfung statt Erzeugung belohnt. Kit übernimmt das Repo-Setup, die Anweisungen, die automatische Abgabe zur Deadline und die Archivierung. Ihre Anweisungen können klar sagen: „KI ist erlaubt; wir werden Sie bitten, uns zu erläutern, wie Sie sie gesteuert und überprüft haben.“ Die Live-Interview-Phase trägt dann das Raster – mit Prüfer-Zuweisungen und strukturierter Teambewertung, damit die fünf Kriterien bei allen Kandidaten gleich bewertet werden und über den gesamten Trichter vergleichbar bleiben.

Eine ehrliche Einschränkung. Kein Tool, auch Kit nicht, erkennt KI-Nutzung zuverlässig; die Daten zu unsichtbaren Overlays machen das deutlich. Gerade diese Grenze ist der Grund, warum die Antwort im Aufgaben- und Rasterdesign liegt und nicht in der Erkennung. Kits Aufgabe ist es, das richtige Design einfach umsetz- und standardisierbar zu machen – nicht, mit Schummelwerkzeugen Katz und Maus zu spielen. Den Begleitartikel zur Aufgabe selbst finden Sie unter Wie Sie Code-Aufgaben strukturieren, die niemand hasst.

Der Wandel ist leicht ausgesprochen und schwerer zu ignorieren, als er sein sollte. Hören Sie auf, KI zu verbieten, denn der Job nutzt sie. Hören Sie auf, KI zu erkennen, denn dieses Rennen können Sie nicht gewinnen. Gestalten Sie stattdessen ein Assessment, bei dem das gute Nutzen von KI die sichtbare Fähigkeit ist: eine Debug-und-Erweitern-Aufgabe an unbekanntem Code, ein Trade-off-Gespräch, das keine KI im Hintergrund für die Kandidaten führen kann, und ein Raster, das bewertet, wie sie den Assistenten steuern, überprüfen und korrigieren. So unterscheiden Sie den Engineer, der KI beherrscht, von dem, der schlicht von ihr abhängig ist – und das ist der Unterschied zwischen einer Einstellung, die liefert, und einer, die Ihre Code-Reviews verstopft.

Häufig gestellte Fragen

Sollte ich im Coding-Interview KI erlauben?

Ja – in den Runden, in denen Sie messen wollen, wie Kandidaten arbeiten. Der Job nutzt KI intensiv, mit bereits 42 % KI-unterstütztem eingecheckten Code laut Sonar, sodass eine KI-freie Runde einen Workflow testet, den niemand mehr nutzt. Halten Sie die KI-Nutzung rundenspezifisch: DoorDash etwa erlaubt sie in der KI-unterstützten Arbeitssitzung, aber nicht in jeder Runde. Bewerten Sie, wie die Kandidaten den Assistenten steuern und überprüfen – nicht, ob sie allein eine korrekte Funktion produziert haben.

Wie erkennen Sie, ob Kandidaten zu abhängig von KI sind?

Nicht durch Proctoring – die Daten zeigen, dass das ein aussichtsloses Wettrüsten ist. Sie machen es über das Aufgabendesign sichtbar. Geben Sie eine Debug-und-Erweitern-Aufgabe an unbekanntem Code mit einem eingebauten logischen Fehler und beobachten Sie, ob die Kandidaten den Output des Assistenten überprüfen oder ihm blind vertrauen. Abhängigkeit zeigt sich in dem Moment, in dem das Modell mit voller Überzeugung danebenliegt und der Kandidat es nicht merkt.

Was ist 2026 das beste Format für ein technisches Interview?

Eine Debug-und-Erweitern-Arbeitsprobe an Code, den die Kandidaten nicht geschrieben haben, kombiniert mit einem eng umrissenen System-Design-Gespräch – beides mit erlaubter KI und einem Raster, das Argumentation höher gewichtet als Output. Arbeitsproben tragen die höchste Vorhersagevalidität in der Literatur zur Personalauswahl (rund 0,33 bis 0,54 laut Schmidt und Hunter sowie späteren Revisionen), weit über Lebensläufen, Berufsjahren oder auswendig gelernten Algorithmus-Rätseln.

Benachteiligt das Erlauben von KI Menschen mit nicht-traditionellem Hintergrund?

Im Gegenteil. DoorDash berichtet, dass KI-unterstützte Formate Engineers mit nicht-traditionellem Hintergrund glänzen lassen, weil der Assistent die Ausführungslücke schließt und die Runde Urteilsvermögen misst – das sich aus Feldern wie Mathematik und Physik übertragen lässt. KI zu erlauben weitet den Trichter für starke Denkerinnen und Denker, die nicht den Standard-CS-Weg gegangen sind.