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

Um im Zeitalter, in dem KI die Antworten faken 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 Denkweise, Validierung des Outputs und 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. Die eine steuert einen KI-Assistenten mit Urteilsvermögen, fängt seine Fehler ab und liefert etwas Solides. Der andere promptet dasselbe Modell, bekommt funktionierend aussehenden Code und hat keine Ahnung, dass er falsch ist. Beide bestehen das Take-Home. Der Unterschied zeigt sich erst später: in der Produktion, in der Review-Queue 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 Hiring-Teams 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, dass sein Kurs für lineare Algebra für Hausaufgaben und Prüfungen eine „Open-Internet-, Open-KI-Politik“ gefahren habe. 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 arbeitender Engineer 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 eines verpatzten Screenings in die Höhe treibt. 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“ verfällt also in dem Moment, in dem Sie sie ausrollen.

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 keinem Screenshare auftauchen. Fabric berichtet, dass 59 % der Hiring-Manager bereits vermuten, dass in Assessments KI zum Einsatz kommt, und Karats Führungskräfte schätzen, dass mehr als die Hälfte der bewerbenden Personen 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 selbst vor dem Bildschirm 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 reparieren, wenn nicht. 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 Begutachten von KI-Code koste mehr Aufwand als das Begutachten von Code eines Menschen. Die Verifikationskosten verschwinden auch am QA-Tor 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. Genau 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 die bewerbende Person eine korrekte Funktion produziert hat. Beginnen Sie zu bewerten, wie sie den Assistenten steuert, seinen Output überprüft und wieder auf Kurs kommt, wenn er danebenliegt. Das ist das Modell, das die führenden Programme bereits übernommen haben, und es lässt sich sauber auf eine Startup-große Schleife übertragen.

Googles berichteter KI-unterstützter Pilot erlaubt einen freigegebenen Assistenten in der Coding-Runde für Junior- und Mid-Level-Rollen in den USA und bewertet „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: Fluency 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 konvergieren auf dieselbe Validierungssprache: Starke Bewerberinnen und Bewerber „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 Person nicht geschrieben hat

Die aussagekräftigste Einzelübung ist das Lesen und Reparieren von Code, den die bewerbende Person nicht selbst geschrieben hat. „Kannst du den Code von jemand anderem lesen, finden, was falsch ist, und es beheben?“ ist die Frage, die KI-Abhängigkeit nicht faken kann – denn die Arbeit besteht aus Überprüfung, nicht aus Erzeugung. Geben Sie ihr eine kleine, teilweise funktionierende Codebasis mit einem eingebauten logischen Fehler – der Sorte Bug, die korrekt aussieht und einen naiven Test besteht. Bitten Sie sie 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 selbstbewusst etwas Falsches vorschlägt. Eine abhängige Person fügt die Fehlermeldung in einen Prompt ein und liefert, was zurückkommt. Eine kompetente Person nutzt den Assistenten, um schneller voranzukommen, während sie jede Entscheidung selbst verantwortet.

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ürdest du das cachen, wo bricht es unter Last, was gibst du auf, wenn du die einfachere Option wählst? KI kann ein Architekturdiagramm skizzieren. Was sie im lebendigen Hin und Her nicht kann: eine Entscheidung verteidigen, auf die Sie Druck ausüben, und nachjustieren, wenn Sie eine Bedingung hinzufügen. Das Gespräch zeigt, ob die Denkleistung der bewerbenden Person gehört oder dem 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 jede bewerbende Person 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 Scope, steht für das Ergebnis ein.

Warum Arbeitsproben Abschlüssen und LeetCode überlegen sind

Eine nachgewiesene Arbeitsprobe gehört zu den aussagekräftigsten Hiring-Signalen, die 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 ein Kompositum aus allgemeiner kognitiver Fähigkeit plus 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 Proxys.

Die schwachen Proxys sind genau die, die KI jetzt zerbricht. 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 konsistent. 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 Coding-Aufgabe rund um die Überprüfung und ein strukturiertes Live-Debrief 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 durchzugehen, 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 jeder bewerbenden Person 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. Genau 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 KI nicht ghostwriten kann, und ein Raster, das bewertet, wie die bewerbende Person den Assistenten steuert, überprüft und korrigiert. So unterscheiden Sie den Engineer, der KI kommandiert, von dem, der schlicht von ihr abhängig ist – und das ist der Unterschied zwischen einem Hire, der liefert, und einem, der Ihre Review-Queue füllt.

Häufig gestellte Fragen

Sollte ich im Coding-Interview KI erlauben?

Ja – in den Runden, in denen Sie messen wollen, wie sie 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 bewerbende Person den Assistenten steuert und überprüft – nicht, ob sie allein eine korrekte Funktion produziert hat.

Wie erkennt man, ob eine bewerbende Person zu abhängig von KI ist?

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 bewerbende Person den Output des Assistenten überprüft oder ihm blind vertraut. Abhängigkeit zeigt sich in dem Moment, in dem das Modell selbstbewusst falschliegt und die Person es nicht merkt.

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

Eine Debug-und-Erweitern-Arbeitsprobe an Code, den die bewerbende Person nicht geschrieben hat, kombiniert mit einem eng umrissenen System-Design-Gespräch – beides mit erlaubter KI und einem Raster, das Denkweise 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 Denker, die nicht den Standard-CS-Weg gegangen sind.