Fünfundvierzig Minuten, ein geteilter Editor, ein Fremder, der jeden Tastendruck beobachtet, und ein Problem, das du noch nie gesehen hast: eine verkettete Liste umkehren, das Teilarray mit der größten Summe finden. Keine Dokumentation, keine Suche, manchmal nicht einmal Autovervollständigung. Und obendrein sollst du "laut denken". Das ist Live Coding, und in vielen Bewerbungsprozessen ist es immer noch der Moment, der alles entscheidet.
Ich bin dagegen. Nicht weil es schwierig ist, sondern weil es das Falsche misst. Ich habe Vorstellungsgespräche auf beiden Seiten des Tisches geführt, und in einem anderen Artikel habe ich beschrieben, wie ich technische Fragen im KI-Zeitalter ändern würde. Hier komme ich direkt zur Sache: warum klassisches Live Coding nicht funktioniert, was ich seinen Verteidigern zugestehe und was ich stattdessen tun würde.
Welches Live Coding ich meine
Zuerst eine Unterscheidung. Ich bin gegen die zeitlich begrenzte Algorithmus-Aufgabe, live beobachtet, ohne Hilfsmittel, zu einem Problem ohne Bezug zur Arbeit, deren Ergebnis allein darüber entscheidet, ob du weiterkommst. Ich bin nicht dagegen, gemeinsam mit einem Kandidaten an einer realistischen Aufgabe zu arbeiten, mit Dokumentation und Werkzeugen, um zu sehen, wie er denkt. Das wirkt wie dasselbe, ist es aber nicht: Darauf komme ich am Ende zurück.
Es misst Stress, nicht Kompetenz
Das ist nicht nur ein Eindruck. 2020 haben Forschende der North Carolina State University und von Microsoft eine kontrollierte Studie mit 48 Informatikstudierenden veröffentlicht: Die Hälfte löste eine Aufgabe am Whiteboard vor einem Interviewer, die andere Hälfte allein in einem separaten Raum. Wer beobachtet wurde, schnitt mehr als doppelt so schlecht ab. Die Autoren weisen darauf hin, dass das Format dem Trier Social Stress Test unheimlich ähnelt, einem Protokoll, das in der Psychologie gezielt eingesetzt wird, um Stress auszulösen.
Die Studie ist klein und wurde mit Studierenden durchgeführt, deshalb nehme ich sie nicht als Gesetz. Aber sie bestätigt, was jeder kennt, der schon einmal ein Vorstellungsgespräch hatte: Unter Beobachtung schrumpft das Arbeitsgedächtnis, man verliert den Faden, macht banale Fehler, die einem unter normalen Bedingungen nie passieren würden. Das Ergebnis beantwortet nicht die Frage "Kann er programmieren?", sondern eine andere: "Wie gut programmiert er, während ihn jemand live bewertet?". Und in der echten Arbeit gibt es diese Situation nicht.
Echte Arbeit sieht nicht aus wie Live Coding
| Beim Live Coding | In der echten Arbeit |
|---|---|
| 45 Minuten für ein nie gesehenes Problem | Stunden oder Tage, mit Zeit, das Problem zu verstehen |
| Keine Dokumentation, keine Suche | Dokumentation, Suche und Beispiele immer offen |
| KI-Assistent verboten | KI-Assistent im Editor, jeden Tag |
| Ein Fremder, der jeden Tastendruck beobachtet | Konzentration, und das Review kommt danach |
| Lehrbuch-Algorithmen | Bestehenden Code lesen, APIs integrieren, Bugs beheben |
| Es zählt, zu einer Lösung zu kommen | Es zählen Lesbarkeit, Tests und Wartbarkeit über die Zeit |
Wer eingestellt wird, verbringt seine Tage damit, Code anderer zu lesen, eine Bibliothek auszuwählen und herauszufinden, warum ein Test nur in der CI fehlschlägt. Ihn danach zu beurteilen, ob er in einer halben Stunde und unter fremden Blicken einen Algorithmus aus dem Gedächtnis implementieren kann, heißt, eine Fähigkeit zu messen, die er selten braucht, unter Bedingungen, unter denen er nie arbeiten wird.
Es belohnt, wer für das Format trainiert, nicht wer gut arbeitet
Algorithmisches Live Coding ist zu einer eigenen Disziplin geworden, mit Plattformen, Kursen und Hunderten von Aufgaben, die man so lange wiederholt, bis man sie auf den ersten Blick erkennt. Wer wochenlang Zeit zum Trainieren hat, kommt vorbereitet. Wer Vollzeit arbeitet, eine Familie hat oder seine Zeit einfach damit verbringt, echte Software zu bauen statt Rätsel zu lösen, startet im Nachteil. Am Ende wählt das Vorstellungsgespräch vor allem die Vorbereitung auf das Vorstellungsgespräch aus.
Und es benachteiligt systematisch bestimmte Menschen: wer unter Angst leidet, wer neurodivergent ist, wer das Gespräch in einer Sprache führt, die nicht die eigene ist, und laut denken muss, während er im Kopf übersetzt. Nichts davon sagt etwas darüber aus, wie diese Person im Team Code schreiben wird.
Es kostet auch das Unternehmen
Meistens spricht man über die Kandidaten, viel weniger über das Unternehmen. Jedes falsch-negative Ergebnis ist ein fähiger Entwickler, der aussortiert wird, weil er zehn Minuten lang blockiert war. Und erfahrene Leute mit Alternativen meiden Prozesse mit Live Coding oft ganz: Das Unternehmen bekommt diese Kandidaten gar nicht erst zu sehen.
Es gibt auch einen weniger sichtbaren Effekt. Wer jemanden unter Druck beobachtet, bewertet am Ende eher die Selbstsicherheit als die Substanz: Wer flüssig redet, wirkt besser als jemand, der schweigt und nachdenkt. Dieser Bias existiert in jedem Vorstellungsgespräch, aber dieses Format verstärkt ihn.
Was ich seinen Verteidigern zugestehe
- Zu prüfen, ob jemand wirklich programmieren kann, ist legitim. Ein Lebenslauf lässt sich aufblähen, und heute kann sogar eine Aufgabe für zu Hause eine KI lösen.
- Lange Hausaufgaben haben echte Kosten: Stunden unbezahlter Arbeit, oft unverhältnismäßig für die Stelle.
- Live Coding ist günstig und einheitlich: dieselbe Aufgabe für alle, eine Stunde und fertig.
Das sind ernsthafte Einwände. Aber die Antwort auf "Wir müssen die Kompetenzen prüfen" kann kein Format sein, das sie schlecht misst. Es braucht ein Format, das dasselbe prüft, ohne den Teil, der das Ergebnis verzerrt.
Was ich stattdessen tun würde
- Ein Code Review von echtem Code. Ein plausibler Ausschnitt mit einem Bug und ein paar fragwürdigen Entscheidungen, zu kommentieren wie der Pull Request eines Kollegen. Man sieht sofort, wer den Code versteht, und niemand muss nach Diktat schreiben.
- Das eigene Projekt des Kandidaten. Ein Repository, eine frühere Arbeit, ein privates Projekt: "Erklär mir diese Entscheidung", "Was würdest du heute ändern?". Eine echte Erfahrung hält fünf Nachfragen stand; eine auswendig gelernte Geschichte bricht bei der zweiten zusammen.
- Eine kurze Aufgabe für zu Hause, gefolgt von einem Gespräch. Höchstens zwei oder drei Stunden, wenn möglich bezahlt, und danach ein Gespräch, in dem der Kandidat seine eigene Lösung erklärt und ändert. Hat eine KI sie geschrieben und er versteht sie nicht, reichen ein paar Minuten Fragen, um es zu merken.
- Pair Programming an einer realistischen Aufgabe. Wenn man wirklich sehen will, wie jemand Code schreibt: ein kleines echtes Repository, Dokumentation und KI erlaubt, keine Stoppuhr für das Ergebnis. Der Interviewer arbeitet mit dem Kandidaten, statt ihn zu überwachen.
- Eine Debugging-Session. Ein fehlschlagender Test und Zeit, um herauszufinden, warum: Das kommt einem normalen Arbeitstag am nächsten.
Wenn Live Coding bleibt, dann wenigstens so
Ich verstehe, dass nicht jedes Unternehmen seinen Prozess von heute auf morgen ändert. Wenn Live Coding bleibt, machen es ein paar Mindestregeln weniger unfair:
- Format, Dauer und Programmiersprache vorab mitteilen;
- ein Problem mit Bezug zur Arbeit wählen, kein Lehrbuch-Rätsel;
- Dokumentation und Suche erlauben, wie an jedem normalen Arbeitstag;
- das Denken bewerten, nicht nur das Endergebnis;
- dem Kandidaten ein paar Minuten geben, um in Ruhe zu lesen und nachzudenken, bevor er reden soll.
Und wenn du der Kandidat bist
Du kannst höflich um eine Alternative bitten: ein Code Review, ein Gespräch über eines deiner Projekte, eine kurze Aufgabe für zu Hause. Nicht jedes Unternehmen wird zustimmen, aber fragen kostet nichts. Und die Antwort sagt schon viel darüber, wie dort gearbeitet wird: Ein Unternehmen, das nicht erklären kann, warum es ein bestimmtes Format verwendet, hat sich die Frage wahrscheinlich nie gestellt.
Fazit
Ich bin gegen klassisches Live Coding, weil es misst, wie jemand den Stress aushält, beobachtet zu werden, und nicht, wie er arbeitet. Das ist ein schlechtes Geschäft für die Kandidaten und auch für das Unternehmen, das fähige Leute aussortiert und diejenigen auswählt, die für das Format trainiert haben. Es gibt Alternativen, die dasselbe prüfen, nämlich ob jemand programmieren kann, ohne das Ergebnis zu verzerren. Weitere Ideen, wie man technische Vorstellungsgespräche erneuern kann, habe ich in diesem Artikel gesammelt, und wenn du dich auf ein Gespräch vorbereitest, findest du die technischen Fragen nach Level sortiert im Leitfaden mit den 25 Interviewfragen für Frontend/Angular.
