- Da AI-Tools schnell auch in die Bereiche Code-Erstellung und Review vordringen, sollte der Einsatz von AI in Interviews grundsätzlich ausgeschlossen und stattdessen die Beurteilung auf grundlegende Fähigkeiten fokussiert werden
- Gute Interviews lassen sich anhand von zwei Achsen bewerten: Signalqualität (signal quality) und Kosten für das Unternehmen (cost to company); beide Faktoren sind nicht vollständig unabhängig voneinander
- Interviewtypen lassen sich in vier Kategorien einteilen: Take-home, Live exercise, Presentation, Actual work; jede davon hat eine andere Signalqualität und andere Kosten
- Durch AI Coding werden Take-home-Aufgaben zu einfach, während der Review-Aufwand steigt; außerdem fungiert AI bei geleakten Fragen als starker Coach
- AI-Kompetenz ist nur eine instrumental skill; Unternehmen sollten sich daher auf die Bewertung von foundational skill konzentrieren
Kernthese
- Angesichts der schnellen Entwicklung von AI-Modellen und -Tools stellt sich die Frage, ob Engineers in sechs Monaten überhaupt noch Code schreiben oder reviewen werden und ob sich, falls Kernfertigkeiten verschwinden, auch die Interviewmethoden weiterentwickeln müssen
- Die meisten Unternehmen haben sich für den Status quo entschieden, auch solche, die diese Revolution selbst vorantreiben
- Die Hiring-Guidelines von Anthropic verlangen, dass Take-home-Aufgaben „ohne Claude abgeschlossen werden, sofern nicht anders angegeben“
- Einige Unternehmen erlauben, empfehlen oder verlangen den Einsatz von AI, und AI-Kompetenz selbst wird mitunter zum Gegenstand des Interviews
- Die Schlussfolgerung lautet, dass AI in Interviews im Allgemeinen ausgeschlossen werden sollte; zugleich werden konkrete Wege aufgezeigt, wie Interviews an AI angepasst werden können
Zwei Dimensionen guter Interviews
-
Signalqualität (Signal quality)
- Die Fähigkeit, für ein gegebenes Set an Kompetenzen starke Kandidaten zu identifizieren und Rauschen zu ignorieren, also Faktoren, die für die Rolle nicht zentral sind oder leicht vermittelt werden können
- Unempfindlichkeit gegenüber Vorbereitung (Invulnerability to preparation): Wenn die Leistung vor allem von Umfang und Intensität der Vorbereitung abhängt, erhält man nur ein Signal über genau diese Eigenschaft
- Realitätsnähe (Realism): Ein Interview sollte der täglichen Arbeit ähneln, darf aber nicht zum Selbstzweck werden. Interviews zu „algorithm & data structure“ haben sich lange gehalten, obwohl sie in der Praxis nicht direkt eingesetzt werden
- Gleichheit (Equality): Manche Kandidaten sind durch vorhandene Domain-Expertise, bezahltes Mentoring, mehr freie Zeit, geleakte Online-Fragen oder Bekannte mit frischer Interviewerfahrung im Vorteil. Idealerweise braucht es für alle ein faires Umfeld
- Schwierigkeit (Difficulty): Ein gutes Interview ist schwer genug, dass viele scheitern. Am besten sind breite und mehrdeutige Probleme, die mehrere Einsichten erfordern
-
Kosten für das Unternehmen (Cost to company)
- Interviewfragen erfordern erhebliche Zeitinvestitionen: Entwurf erster Versionen und Freigabe durch Erprobung, Erstellung von Scorecards nach Rolle und Level, Tests mit internen und externen Kandidaten sowie Dokumentation und Schulung der Interviewer
- Fragen und Scorecards werden laufend nachkalibriert, daher muss diese Investition dauerhaft aufrechterhalten werden
- Schwierigkeit (Difficulty): Schon das Erstellen von Fragen ist anspruchsvoll, aber ausreichend schwierige Fragen zu erstellen ist noch herausfordernder. Zu leichte oder zu schwere Fragen verschwenden auf beiden Seiten Zeit
- Attraktivität für Kandidaten (Appeal to candidate): Prozesse, die zu viel Zeit kosten, oder langweilige Fragen vertreiben starke Engineers und verschlechtern die Conversion. Fragen zeigen auch die Engineering-Kultur eines Unternehmens
- Beide Dimensionen sind nicht vollständig unabhängig; etwa beeinflusst die Schwierigkeit beide Seiten. Schwierige Interviews lassen starke Kandidaten glänzen, können aber false negatives verursachen
- Interviews müssen nicht perfekt sein; false negatives und false positives wird es immer geben. False negatives sind schwer zu erkennen, aber false positives lassen sich mit gutem Onboarding und klaren Meilensteinen im ersten Halbjahr schnell aussortieren
Einteilung der Interviewtypen
-
Take-home
- Der Kandidat reicht eine Lösung für (1) ein mehrdeutiges Problem, etwa eine Produktspezifikation, ein und beachtet dabei (2) einige technische Einschränkungen, etwa eine Liste zulässiger Programmiersprachen
- Oft folgt darauf ein Review-Interview, in dem der Kandidat die Arbeit präsentiert und spontan Änderungen vornimmt
- Signalqualität: (vor AI) hoch — liefert breite Signale zu Design, Coding, Detailgenauigkeit, Tests usw.; ein Einsatz von über 6 Stunden belegt zudem Motivation
- Kosten für das Unternehmen: mittel — die Bewertung kann automatisiert werden, und das Artefakt (Code) lässt sich asynchron reviewen; zugleich kann das Format Kandidaten abschrecken
- Sehr anfällig für AI und hoch motivierte Personen
-
Live exercise
- Dazu zählen algorithm & datastructure, live coding, system design, postmortem review usw., meist über eine Stunde oder länger. Probleme wie „Netflix-Architektur entwerfen“ oder „einen rate-limiter schreiben“ werden direkt vor dem Interviewer gelöst
- Signalqualität: mittel — bei guter Gestaltung und Durchführung objektiv, aber das Signal ist meist auf ein Thema konzentriert
- Kosten für das Unternehmen: mittel — um weniger anfällig für Kandidatenvorbereitung zu sein, braucht man viele unterschiedliche Fragen
- Manche Unternehmen nutzen zur Kostensenkung automatisierte Services
-
Presentation
- Der Kandidat wählt Problem und Antwort selbst, etwa bei „Erzählen Sie von einem Projekt, das Sie geleitet haben“, „Architekturdiagramm“ oder „eine Erfahrung, die Sie gemacht haben“
- Signalqualität: niedrig — es gibt viele Fehlermodi
- keine Erfahrung mit interessanten Problemen gemacht (z. B. Junioren), Wahl eines langweiligen Problems, Übertreibung von Wirkung oder eigenem Beitrag, schlechte Vorbereitung der Präsentation, starker Kommunikator ohne Umsetzungskraft oder ungenaue Bewertung wegen fehlender Domain-Kenntnis des Interviewers
- Kosten für das Unternehmen: niedrig — aus Kalibrierungssicht ist wenig Vorbereitung nötig
- Die niedrige Signalqualität lässt sich durch Reflexionsfragen wie „Was würden Sie anders machen?“ oder hypothetische Fragen wie „Was wäre, wenn Anforderung X geändert würde?“ etwas abfedern. Dann nähert sich das Format einer nicht kalibrierten live exercise an und verlangt mehr Aufwand sowie mehr Expertise vom Interviewer
-
Actual work (kein Interviewtyp)
- Eine Woche bezahlte Zusammenarbeit. Unternehmen wie Linear nutzen dieses Modell
- Signalqualität: hoch / Kosten für das Unternehmen: hoch
- Die meisten Unternehmen kombinieren diese Formate, wobei Live exercise dominiert
Frage-Leaks sind nur eine Frage der Zeit, unabhängig von AI
- Dass Fragen geleakt werden, ist nur eine Frage der Zeit; Websites wie Glassdoor listen Interviewgeheimnisse vollständig auf. Manche Kandidaten durchlaufen Interviews sogar, um Fragen anschließend zu verkaufen
- Ignoriert man das, wird das Signal schwächer, und der wichtigste Leistungsfaktor wird zu „Hat diese Person unseren Interviewprozess recherchiert?“
-
Gegenmaßnahmen
- Vorbereitung steuern (Control the preparation): Presentation in den Mix aufnehmen oder präzise Leitlinien geben, etwa „System Design fokussiert auf Datenbanken“ oder „Algorithmen zu Graphen“, um ein faireres Umfeld zu schaffen
- Fragen je Typ variieren: Alte Fragen regelmäßig archivieren. Wenn Kandidaten die exakte Frage nicht vorhersagen können, müssen sie sich breiter vorbereiten — genau das ist das Ziel. Kostenlos ist das allerdings nicht
- Leaks erschweren (Make it harder to leak): Vor-Ort-Interviews, Whiteboards und die verletzlichsten Fragen erst spät im Prozess einsetzen, wenn weniger Kandidaten übrig sind und die Leak-Wahrscheinlichkeit sinkt
AI Coding bedroht das aktuelle Interviewmodell
-
(1) Take-home wird für Kandidaten zu einfach und für Unternehmen zu teuer
- Bis 2026 werden die meisten Einreichungen vermutlich AI-generiert oder AI-unterstützt sein; selbst Aufgaben, die heute noch standhalten, werden mit dem nächsten Modell-Release wahrscheinlich lösbar
- Dadurch bestehen am Ende die meisten Kandidaten die erste Stufe, was zu hohem Review-Aufwand führt. Von AI erzeugte Einreichungen wiederum mit AI zu reviewen ist nicht sinnvoll
- AI Coding verschiebt die Interviewkosten von den Kandidaten zu den Interviewern
- Zitat zu Brandolinis Gesetz: Das Widerlegen schlechten Codes kostet eine Größenordnung mehr Energie als seine Erzeugung
-
(2) Wenn weniger Zeit für das Schreiben von Code nötig ist, ist es naheliegend, den Anteil von live coding zu reduzieren
- So wie man statt Maschinensprache Hochsprachen nutzt, erscheint es vernünftig, auch die im Interview erlaubten Tools an den Arbeitsalltag anzugleichen
-
(3) Wenn Fragen geleakt sind, ist AI ein starker Coach
- Früher kostete es viel Zeit und Ressourcen, Fragen zu finden und sich darauf vorzubereiten; heute liefert AI die stärkste und günstigste Hilfe
Wie das klassische schulische Bewertungsmodell Technik widerstanden hat
- Prüfungen an französischen Gymnasien und Hochschulen haben weitgehend dieselbe Form behalten
- Keine Hilfsmittel wie Unterlagen aus Vorlesungen oder Büchern, fast keine Tools erlaubt, insbesondere keine Taschenrechner, Inhalte vorab nicht offengelegt, nicht vorhersagbar, da jede Prüfung anders ist und nur einmal verwendet wird, sowie breite und mehrdeutige Probleme
- Der Kern der französischen Literaturprüfung ist die dissertation: Zu einem einzigen Satz als Thema wird ein Essay von 5 bis 10 Seiten geschrieben; dieses Format existiert seit 1830. Naturwissenschaftliche Prüfungen folgen mit 3 bis 4 mehrdeutigen Aufgaben einem ähnlichen Muster
- Andere Bewertungsformen wie Take-home, Multiple-Choice-Wissensfragen, Gruppenaufgaben oder Präsentationen ergänzen das zwar, bleiben aber Ausnahmen statt Regel
- Erneute Anwendung der Einteilung
- Signalqualität: hoch — der Vorbereitungsraum ist sehr groß und erfordert dauerhafte Anstrengung
- Kosten: sehr hoch — für jede Prüfung müssen neue Themen und Bewertungsschemata entwickelt werden, und alle Kandidaten schreiben gleichzeitig dieselbe Prüfung; für Unternehmensinterviews völlig unrealistisch
- Interessant ist, dass sich dieses Modell trotz gewaltiger Fortschritte bei kognitiven Werkzeugen wie Copy-and-paste, Internet, Taschenrechnern oder Solver-Systemen kaum verändert hat
- Bildung sollte sich auf grundlegende Fähigkeiten konzentrieren, nicht auf die jeweils verfügbaren Werkzeuge; das entspricht einem aristotelischen Modell, das eher auf Urteilskraft (phronesis) als auf Gedächtnis (mneme) fokussiert
Warum Unternehmen die Nutzung von AI während Interviews einschränken sollten
-
Unterschied zwischen grundlegenden und instrumentellen Fähigkeiten
- Foundational traits & skills sind Fähigkeiten, Haltungen oder Gewohnheiten, deren Aufbau schwierig oder teuer ist
- rohe intellektuelle Fähigkeiten, tiefe Expertise aus jahrelangem Lernen etwa zu verteilten Systemen mit Millionen Requests pro Sekunde oder zur Umwandlung von Hunderten Microservices in einen Monolithen, sekundäres Schlussfolgern sowie Tugenden wie Berufsethik, integrity und Resilienz
- Es handelt sich um internalisiertes Wissen (fundamentals), das hilft, Probleme zu erkennen, zu abstrahieren und zu lösen, und die Grundlage für den Aufbau weiterer Fähigkeiten bildet. Das ist der Grund, warum man über manche Menschen sagt: „Die Person ist klug, sie wird das schon lösen“
- Instrumental skills lassen sich günstig oder schnell aufbauen
- mittlere Beherrschung einer Programmiersprache, angemessene Nutzung eines Texteditors, Suchen in Dokumentation oder Feinjustierung von AI-Prompts
- In Interviews werden oft Signale aus mehreren instrumentellen Fähigkeiten genutzt, um grundlegende Eigenschaften eines Kandidaten zu validieren, etwa die Bereitschaft, in Produktivität zu investieren, oder strukturiertes Lernen
- Foundational traits & skills sind Fähigkeiten, Haltungen oder Gewohnheiten, deren Aufbau schwierig oder teuer ist
-
Rationale 1: AI-Kompetenz ist keine grundlegende Fähigkeit
- Engineering-Tools haben sich stetig weiterentwickelt, doch Interviews sind weitgehend gleich geblieben; es gibt etwa keinen Interviewtyp für low-code, und system design stützt sich meist auf grundlegende und nicht gemanagte Technologien
- Die besten Unternehmen suchen keine Kompetenz in genau einem Tool; mit dem Aufstieg von LLMs wird die Bedeutung des Expert Generalist sogar größer
- Dass Programmiersprachen-Expertise im Interview meist keine große Rolle spielt, hat denselben Grund: Die Sprache ist nur ein Werkzeug für das übergeordnete Ziel der Problemlösung
- Gleiches gilt für AI-Nutzung: Prompt/context engineering, Definition von MCP/skills, multi-agent workflow oder harness engineering erfordern zwar feine Techniken, bleiben aber instrumentelle Fähigkeiten und setzen dieselben grundlegenden Fähigkeiten voraus, die man zum Schreiben und Reviewen von Code oder zum Entwerfen skalierbarer Architekturen braucht
- Unternehmen stellen Gehirne ein, nicht Hände, die gedankenlos Anweisungen in einen AI-Agenten tippen
- Review und Produktion sind zwei Seiten derselben Medaille; Code-, Architektur- und Analyse-Reviews verlangen ähnliche Fähigkeiten wie Schreiben, Design und Analyse. Weil Menschen geschäftliche Anforderungen erzeugen und validieren müssen, wird Code-Review so bald nicht verschwinden; eine hinreichend detaillierte Spezifikation ist bereits fast Code
- Engineering-Tools haben sich stetig weiterentwickelt, doch Interviews sind weitgehend gleich geblieben; es gibt etwa keinen Interviewtyp für low-code, und system design stützt sich meist auf grundlegende und nicht gemanagte Technologien
-
Rationale 2: AI verdeckt grundlegende Eigenschaften und Fähigkeiten
- In Anlehnung an Peter Drucker: Man kann nicht nur Hände einstellen, der ganze Mensch kommt mit
- Mit Lewis Mumfords Unterscheidung zwischen tool (vom menschlichen Arbeiter gesteuert) und machine (arbeitet nach eigener Logik und besitzt agency) wird deutlich: Bei übermäßigem AI-Einsatz ist der Beitrag des Engineers kaum noch vom Beitrag des AI-Modells zu trennen
- Vorsicht ist geboten bei Engineers, die AI eher wie eine machine als wie ein tool verwenden. AI ist mehr als starkes Autocomplete; sie bedeutet einen gewaltigen Produktivitätssprung und erlaubt die Auslagerung großer Teile des Denkens. Selbst menschlich wirkende Bereiche wie „taste“ geraten unter Druck, sodass selbst Fitts' list veraltet wirkt
- Wie bei Platons pharmakon, das Derrida analysiert hat, ist AI zugleich Heilmittel und Gift: nützlich für wiederholtes Refactoring oder das schnellere Erlernen von Bibliotheksbesonderheiten, aber riskant, weil grundlegende Fähigkeiten verkümmern können
- Interviews, die AI überbetonen, riskieren, nicht den Menschen, sondern das Modell („machine“) zu bewerten. Daher braucht es Aufgaben, die menschliches Schlussfolgern bewusst zum Mittelpunkt des Interviews machen
-
Rationale 3: AI entwickelt sich zu schnell
- Laut Arthur Mensch, CEO von Mistral, gewinnen AI-Modelle etwa alle 12 Monate ein weiteres Jahr Software-Engineering-Erfahrung. Der alte Witz, AI-Agenten seien wie Praktikanten, ist kaum noch zu hören
- Die meisten Unternehmen haben weder die Mittel noch die Zeit, dauerhaft AI-resistente Fragen zu erzeugen und zu pflegen, die grundlegende Fähigkeiten erzwingen. Wenn Modelle sich monatlich weiterentwickeln und man nicht einmal Zugang zu allen Modellen hat, ist das Erstellen von Fragen, die stets gegen die besten Modelle bestehen, ein verlorener Kampf
- Anthropics „Designing AI resistant technical evaluations“ ist ein Beispiel dafür, eher gegen AI als gegen Kandidaten zu „kämpfen“
- Schwierigere Take-home-Aufgaben zu erstellen, ist ähnlich, als würde man Taschenrechner erlauben und dann schwierigere Kopfrechenaufgaben stellen
- Auch Best Practices für AI ändern sich monatlich; je besser Modelle Anweisungen verstehen, desto weniger wichtig wird prompt engineering. Ob Kandidaten die neuesten Tricks kennen, ist kein nützliches Signal
- Fundamentals hingegen verändern sich per Definition nicht
Antworten auf Einwände
- Zum Einwand, es gebe keine Daten: (1) Echte statistisch signifikante Experimente, also randomisierte kontrollierte Studien, sind praktisch unmöglich, und kein Unternehmen würde die dadurch entstehenden false negatives akzeptieren. (2) Die meisten Entscheidungen im Interviewdesign beruhen ohnehin nicht auf klinischen Studien, sondern auf abstraktem Schlussfolgern
- Betrug mit AI, etwa während des Interviews: Wenn AI-Nutzung explizit verboten wurde, ist der Einsatz von AI-Tools ein unmittelbarer Ablehnungsgrund
- In Anlehnung an Warren Buffett: Bei Einstellungen zählen integrity, intelligence und energy; fehlt integrity, ruinieren die anderen beiden Eigenschaften die Person nur noch mehr. Wenn man schon jemanden ohne integrity einstellt, soll die Person lieber dumm und faul sein
- Sollte man Kandidaten mit AI bewerten? Nein. (1) Es ist ethisch falsch — man stellt menschliche Wissensarbeiter ein, und eine Maschine kann nicht alles beurteilen. (2) AI-Bewertungen sind nicht deterministisch und für Halluzinationen bekannt, weshalb am Ende doch wieder Menschen die Bewertung der AI reviewen müssten
Konkrete Empfehlungen für Unternehmen
- Den Einsatz von AI in den meisten Interviews nicht erlauben. Einzelne Tools nicht überbetonen, sondern sich auf grundlegende Fähigkeiten konzentrieren
- In Live exercise investieren. Sie müssen weder künstlich noch langweilig noch signalarm sein und auch nicht kurz. data structure & algorithm Interviews sollten neu bewertet werden — sie bleiben intellektuell oft am anspruchsvollsten. Aufgaben sollten echte menschliche Anstrengung verlangen, und um Übervorbereitung auf Einzelfragen zu verhindern, sollte man viele Fragen vorrätig haben
- Interviewtypen kombinieren, um kosteneffizient ein breites Signal zu erhalten
- Take-home anpassen. Entweder AI-Nutzung ausdrücklich verbieten oder sie zulassen, dann aber keine Zeit mit dem Review von AI-Artefakten verschwenden. Take-home sollte zwingend in eine darauf aufbauende live exercise münden, in der der Kandidat die Arbeit präsentiert und Trade-offs, geänderte Anforderungen oder Skalierbarkeit erläutert
- Mindestens ein Interview zur Bewertung von Review-Fähigkeiten einplanen. Es ist günstig zu erstellen, liefert interessante Signale und belastet Kandidaten weniger. Beispiele: AI-Plan, postmortem, bestehende Codebase (Bug squash), Product Requirements Document, Trade-off-Analyse oder Systemarchitektur-Review
- Erwägen, Kandidaten vor Ort einzuladen. Das ist der einfachste Weg, Betrug zu verhindern, und erschwert auch Frage-Leaks etwas. Gilt allerdings nur für Unternehmen mit RTO
- Klare Vorbereitungshinweise für Interviews geben, um ein faires Umfeld zu schaffen
3 Kommentare
Für mich scheint jemand geeignet zu sein, mit dem man gut eine Woche lang zusammenarbeiten kann.
Den Artikel hat wohl auch die KI geschrieben, haha.
Man wird bei der Arbeit sowieso AI nutzen, daher frage ich mich, ob es sinnvoll ist, das auszuschließen. Wäre es im AI-Zeitalter nicht passender, stattdessen Remote-Interviews abzuschaffen, sie nur vor Ort durchzuführen und anhand gut konzipierter Fragen sowie Beobachtung zu beurteilen, wie jemand AI einsetzt und dabei denkt?
Selbst bei derselben Aufgabe kann man viel über eine Person erfahren, wenn man sieht, wie sie ihre Prompts formuliert.