Live-Coding-Interviews messen nur Stress, nicht die Programmierfähigkeit

• Live-Coding-Interviews messen in der Praxis eher die Stressreaktion als die Programmierfähigkeit von Ingenieur:innen
• Wissenschaftliche Studien zeigen, dass in einer Umgebung unter Beobachtung kognitive Fähigkeiten nachlassen und starke Leistungsschwankungen auftreten
• Besonders bei Bewerberinnen wurde beobachtet, dass in einer öffentlichen Umgebung alle durchfielen, während sie in einer privaten Umgebung alle bestanden
• In den meisten Unternehmen wird Stressresistenz gar nicht verlangt, dennoch wird sie durch Coding-Tests fälschlich bewertet
• Mock-Tests, schrittweise Exposition und bestimmte Nahrungsergänzungsmittel können helfen, Stress zu lindern

---

Persönliche Erfahrungen mit Live-Coding-Interviews

• Manche Menschen mögen Live-Coding-Interviews, der Autor jedoch nicht
• Im Bewerbungsprozess bei Toptal scheiterte der Autor am Live-Coding-Test, konnte dieselbe Aufgabe später allein aber schnell lösen
• Durch diese Erfahrung wurde ihm klar, dass er unter Echtzeitbeobachtung wegen Stress seine eigentliche Leistungsfähigkeit nicht abrufen konnte

Das Gehirn unter Stress

• In Situationen mit hohem Risiko und Zeitdruck wird die Amygdala im Gehirn aktiviert und der Cortisolspiegel steigt
• Dadurch wird die Funktion des präfrontalen Cortex beeinträchtigt, der für komplexes Denken und Gedächtnis zuständig ist
• Das Arbeitsgedächtnis ist der wichtigste Maßstab zur Beurteilung der Fähigkeit, neue Probleme zu lösen, und es wird in Live-Coding-Situationen stark eingeschränkt
• Schon bei leichter Leistungsangst wird klares Denken nahezu unmöglich
• Konzentration fällt schwer, mehrere Schritte können nicht gleichzeitig im Gedächtnis gehalten werden, und man fühlt sich, als wäre man „deutlich schlechter als sonst“

Ausschlaggebende Forschungsergebnisse

• In einer Studie von Microsoft-Forschenden wurde dieselbe Coding-Aufgabe einmal in einer privaten Umgebung und einmal in einer öffentlichen Umgebung bearbeiten lassen
• In der privaten Umgebung arbeiteten die Teilnehmenden allein in einem Raum, in der öffentlichen Umgebung mussten sie die Aufgabe vor einer Aufsichtsperson lösen und dabei ihren Gedankengang laut erläutern
• Das Ergebnis: Unter Beobachtung halbierte sich die Leistung, und besonders die Streuung der Ergebnisse nahm stark zu
• Anders als bei den männlichen Bewerbern fielen in der öffentlichen Umgebung alle Bewerberinnen durch, während sie in der privaten Umgebung alle bestanden
• Live-Coding-Umgebungen wirken damit als wissenschaftlich belegter Ausschlussfilter, der kompetente Ingenieur:innen aussortiert

Die Realität von Leistung unter Stress

• Live Coding ist letztlich nur ein Ersatzmaß für Leistung unter Stress
• Manche Unternehmen suchen tatsächlich Menschen, die unter Stress gut funktionieren, aber die meisten machen das in ihren Stellenausschreibungen nicht klar
• Da die meisten Aufgaben keinen dauerhaften Echtzeitstress erzeugen, ist es unangemessen, hervorragende Ingenieur:innen auszusortieren, nur weil sie im Live Coding Fehler machen
• Es ist plausibler zu sagen, dass Live Coding eher den Spiegel der Stresshormone als die Programmierfähigkeit misst

Wege zur Stressreduktion

• Weil Live Coding in der Branche verbreitet ist, braucht es Training zur Stressanpassung
• Durch wiederholtes Üben in realitätsnahen Bedingungen (Pramp, Interviewing.io, LeetCode-Mock-Tests usw.) kann das Gehirn an Stress gewöhnt werden
• Es ist wirksam, den Druck schrittweise zu erhöhen, etwa mit Timer, Selbstaufzeichnung oder indem man Freund:innen zuschauen lässt
• Zusätzlich kann man Nahrungsergänzungsmittel wie L-tyrosine (zur Unterstützung von Neurotransmittern unter Stress) und L-theanine (für Entspannung und bessere Konzentration) ausprobieren
• Vor dem eigentlichen Interview sollte man in Mock-Übungen unbedingt testen, welche Methode am besten zu einem selbst passt

Fazit

• Wenn man in Live Coding schwach ist, ist das kein Mangel an Eignung als Ingenieur:in, sondern eine allgemeine menschliche Eigenschaft

[GN⁺]

Hacker-News-Kommentare

• Ich möchte meinen Fall nicht verallgemeinern, aber ich will meine persönliche Erfahrung teilen. Ich bin heute ein erfolgreicher selbstständiger Indie-Developer. Einer der Hauptgründe, warum ich die Indie-Entwicklung selbst in schwierigen Zeiten nicht aufgegeben habe, war, dass ich faktisch nicht mehr anstellbar geworden war. Ich bin ein Mann mittleren Alters in einer Tech-Branche mit starker Altersdiskriminierung, habe keinen Computer-Science-Abschluss und erlebe in Live-Coding-Interviews Blackouts. Ich möchte darauf hinweisen, dass nicht jeder Stress gleich ist. Feuerwehrleute rennen in brennende Gebäude, haben aber oft Angst davor, vor Fremden zu sprechen. Bei mir ist es ähnlich: Alltäglichen Arbeitsstress halte ich gut aus, aber wenn andere mir über die Schulter schauen und dabei über meine finanzielle Zukunft entscheiden, ist das für mich kaum auszuhalten. Nach dem Interview kann ich die Coding-Probleme oft problemlos lösen. Interviewer mögen denken, ich sei ein Hochstapler, aber fast 20 Jahre Berufserfahrung sprechen dagegen. Viele scheinen "false negatives" so zu behandeln, als wären sie zufällig verteilt, aber es gibt auch Leute wie mich, die immer aussortiert werden. Bei audition-artigen Interviews falle ich immer durch, denn ich bin niemand, der auf der Bühne performt.

  • Dass man beurteilt wird, während andere zusehen, kann ich nur zu gut nachvollziehen. Ich bin Anfang 60. In meinen 20ern und 30ern kam ich mit Interviews noch einigermaßen zurecht, aber mit der Zeit hatte ich immer stärker das Gefühl, dass Interviews selbst immer konfrontativer geworden sind. Früher wirkte es eher wie ein "wir wollen dich irgendwie einstellen", heute eher wie ein "wir suchen nach einem Grund, dich nicht einzustellen". Das mag mit Altersdiskriminierung zu tun haben, aber ich denke auch, dass sich die Stimmung in der Branche verändert hat. In den letzten 15 Jahren wurden Interviews für mich zunehmend unangenehm, und ich hatte währenddessen sogar Panikattacken. Irgendwie wurde ich trotzdem eingestellt, und dank meiner Referenzen hatte ich auch Vertragsjobs ganz ohne Interview. Das letzte Startup, bei dem ich war, ging Ende 2022 das Geld aus, woraufhin ich beschloss aufzuhören. Die Arbeit selbst mochte ich wirklich sehr, und ich habe mit aktueller Technologie gearbeitet, aber am schwersten wog, dass ich Interviews einfach nicht mehr ertragen konnte.

  • Ich halte die Struktur selbst für das Problem. Aktuelle Coding-Interviews scheinen dafür gebaut zu sein zu prüfen, ob junge Leute ihre CS-Aufgaben zu Datenstrukturen gemacht haben. Für Massenrekrutierung wie bei FAANG in den 2010ern mag das einen Sinn gehabt haben, aber bei kleinen und mittleren Unternehmen wäre es viel besser, sich auf reale Arbeitssituationen zu konzentrieren, etwa tatsächlichen Code zu lesen oder über Edge Cases zu sprechen. Ich arbeite seit über 20 Jahren in Startups und bestehe diese Tests trotzdem immer noch nicht. Ich weigere mich auch, mir das einfach stumpf anzutrainieren. Wenn ich nicht in so ein System passe, dann ist es vielleicht besser so. Ich war CTO, habe mehrere Firmen gelauncht und Teams gut geführt, und trotzdem werde ich wieder wie ein Berufseinsteiger behandelt. Früher bin ich mal durchgefallen, weil ich einen LRU-Cache nicht schnell und sauber genug implementieren konnte, aber ich frage mich, wie oft man das in heutigen Startups wirklich braucht. Ich habe so etwas zuletzt vor langer Zeit benutzt. Nur weil ich solche Probleme nicht sofort lösen kann, wirke ich womöglich unfähig, aber ich sehe nicht ein, warum man Dinge prüft, die in der Praxis gar nicht gebraucht werden. Das ist, als würde man Architekten nach ihren Fähigkeiten mit dem Rechenschieber auswählen. Solche Einstellungsverfahren führen am Ende nur zu komplexen Codebasen, obwohl es eigentlich darum gehen sollte, Geschäftsziele zu erreichen statt Komplexität zu maximieren. Ich möchte mit Kolleginnen und Kollegen arbeiten, die Probleme zerlegen und Logik und Struktur einfach halten. Mit LeetCode kann man zwar schlaue Leute erkennen, aber besser sind Menschen, die reale Probleme dauerhaft effektiv lösen.

  • Ich habe so eine Situation aus der Perspektive eines Einstellenden erlebt. Ich hatte ein Telefoninterview mit einem Studenten, der lange an einem Projekt beteiligt war, und es wirkte so, als könne er wegen verschiedener Stressfaktoren und Sprachbarrieren sein Können nicht richtig zeigen. Ich wäre bereit gewesen, das Format anzupassen, aber der Bewerber sagte selbst, dass er es nicht weiter versuchen wolle. Wenn man dagegen auf asynchrone Coding-Interviews umstellt, testet man am Ende womöglich nur noch, ob jemand ein LLM benutzt. Wenn ich also wählen muss, ob ich eher Leute herausfiltere, die im Interview einfrieren, oder völlig unfähige Betrüger, dann halte ich es für die bessere Wahl, Ersteres zu filtern.

  • Ich sehe diese Persönlichkeits-Diskrepanz oft in Unternehmen. Viele Programmierer sind introvertiert, aber auf der Einstellungsseite sitzen oft extrovertierte Leute. Wenn man diesen Unterschied nicht gut handhabt, führt das dazu, dass introvertierte Talente ausgeschlossen oder missverstanden werden. Open-Space-Umgebungen sind ein ähnliches Problem. Manager mögen Zusammenarbeit lieben, aber für Introvertierte ist das oft eine sehr belastende Umgebung.

  • Mich würde interessieren, was der Auslöser dafür war, dass du als Indie-Developer erfolgreich geworden bist. Ich bin selbst fast 40 und programmiere schon lange als Hobby, habe mich aber erst letztes Jahr entschieden, das beruflich ernsthaft zu verfolgen. Ich habe viele öffentliche Projekte auf GitHub, Erfolgserfahrungen in anderen Bereichen und bin kommunikativ nicht schlecht. Trotzdem habe ich Schwierigkeiten mit Live Coding. Mich würde interessieren, wie du über Wege denkst, auf denen man durch eigenständige Beiträge seine echte Leistungsfähigkeit zeigen kann. Wenn man wirklich etwas kann, möchte man dafür schließlich auch bezahlt werden.

• Ich habe diese Woche Kandidaten für Data Engineering interviewt. Ich gab ihnen vier sehr grundlegende SQL-Abfragen. Ein Kandidat las die Aufgaben laut vor und lieferte sofort die richtige Antwort in korrekter Syntax. Die letzte war minimal schwerer, und da stockte er. Ich sagte: "Prüf doch mal das Ergebnis", aber er verstand es nicht und reagierte defensiv. Ich sagte dann: "Dump die Tabelle", und auch das verstand er überhaupt nicht, sondern brachte nur Ausreden. In die final eingefügte SQL stand schließlich [redacted].ai in der Ausgabe. Vermutlich hatte er die vorherigen Aufgaben mit AI gelöst, und bei der letzten wurde es offensichtlich. Ohne solche technischen Fragen hätten wir den Betrug nicht entdeckt.

  • AI-Tools zum Betrügen in Interviews sind unter jungen Leuten inzwischen extrem verbreitet. In manchen Fällen fliegt das sofort auf, aber erfahrenere Bewerber kaschieren die Nutzung von AI zwischendurch mit Dingen wie "Ich kann Sie nicht hören" und ähnlichen Tricks. In der Manager-Gruppe, zu der ich gehöre, ist das aktuell das meistdiskutierte Thema im Recruiting. Unternehmen, die es sich leisten können, machen das letzte Interview deshalb persönlich vor Ort. Auf Remote-Screens wirken manche Kandidaten okay, aber wenn man sie real trifft, können sie nicht einmal grundlegende Fragen beantworten und fallen dadurch durch. Das ist zwar Zeit- und Geldverschwendung, aber immer noch besser als die Kosten einer Fehlbesetzung. AI-Nutzung betrifft inzwischen nicht nur technische Interviews, sondern auch Lebensläufe, Verhaltensfragen und sogar von ChatGPT erzeugte Antworten im S.T.A.R.-Format. Vertrauenswürdige Referenzprüfungen sind wichtiger denn je. Ich habe mehrfach erlebt, dass das, was ein früherer Vorgesetzter über die Arbeit einer Person sagte, völlig anders war als das, was im Lebenslauf stand. Hätte jemand von Anfang an ehrlich gesagt, dass direkte Erfahrung in unserer Domäne fehlt, hätten wir die Person vielleicht trotzdem eingestellt. Aber wenn die Lügen so massiv sind, entsteht überhaupt kein Vertrauen.

  • In aktuellen Kandidateninterviews haben ungefähr 50 % live GenAI in Echtzeit genutzt. Bisher war es sehr leicht zu erkennen, wer AI verwendet. In natürlicher Unterhaltung fällt das schnell auf. Ironischerweise wiederholte auch der letzte Kandidat immer erst die Aufgabe und wartete dann jeweils 10 bis 15 Sekunden. Das zeigt, dass diese Art von Test das Grundproblem nicht löst. Stattdessen schafft sie neue Probleme und sorgt dafür, dass starke Kandidaten aussortiert werden.

  • Was, wenn der Einsatz von AI kein Betrug ist, sondern nur eine Vorwegnahme dessen, was man im realen Arbeitsalltag ohnehin tun würde? Aus dieser Perspektive war das Interview in Wirklichkeit ein sehr effektives, kleines Beispiel für <i>Anforderungsinterpretation</i>. Ich denke deshalb, man sollte eher in die Richtung gehen, Bewerbern die freie Nutzung der Tools zu erlauben, die sie im Job tatsächlich einsetzen würden, und innerhalb dieses Rahmens ihr Verständnis der Aufgabe und der Sprache selbst zu prüfen. Die Anforderung sollte nicht nur darin bestehen, LeetCode hinter sich zu lassen, sondern insgesamt bessere Methoden zu finden.

• Am Ende hängt alles vom Kontext ab. Das gilt auch für Live-Coding-Interviews. Aus Sicht von Bewerbern ist das sicher nicht die beste Erfahrung, aber in großen Unternehmen wie Meta oder Google reduzieren sie false positives, also die Fehlentscheidung, ungeeignete Leute einzustellen, besser als andere Verfahren. Allerdings sind Interviewer oft nicht ausreichend geschult, und die Aufgaben sind häufig zu sehr rätselhaft, sodass es schwer ist, wenn man nicht viel LeetCode geübt hat oder gerade frisch aus der Uni kommt. Ich habe sechs Jahre im Assessment-Bereich gearbeitet und direkte Einblicke in sehr unterschiedliche Einstellungsprozesse bekommen, von Fortune-10-Unternehmen bis zu Startups. Ich empfehle Beurteilungen, die der tatsächlichen Arbeit ähneln, und ich mag die Formulierung "echte Arbeit" für etwas, das an unbezahlte Arbeit grenzt, inzwischen nicht mehr. Ein Assessment sollte ein Mittel sein, damit ein Unternehmen guten Gewissens ein hoch dotiertes Gehalt anbieten kann. Durch AI ist es schwieriger geworden, selbst bei kurzen Take-Home-Aufgaben Fairness zu gewährleisten. Deshalb greifen manche Firmen wieder zu extremen Methoden wie Onsite-Interviews oder Echtzeitüberwachung. Meine Idealvorstellung wäre eine Lösung, in der alle Kandidaten unter denselben Zeit-, Umgebungs- und Tool-Bedingungen ihre beste Leistung zeigen können. Ich denke ständig über dieses Problem nach, habe aber noch keine Antwort gefunden.

  • Es heißt zwar immer, "auf dem Niveau von Meta und Google funktioniert es", aber in Wirklichkeit gibt es dafür keine Daten. Ich habe mit F-Klasse-Entwicklern gearbeitet, die von Facebook oder Google kamen. Tatsächlich entlassen auch solche Großunternehmen 3 bis 5 % ihrer Belegschaft, was zeigt, dass Interviews false positives eben nicht zuverlässig verhindern. Verglichen mit der Zeit, die Interviewer investieren, ist eine Fehlerquote von 3 % meiner Ansicht nach viel zu hoch. Im Grunde unterscheidet sich das kaum vom alten 'Fizzbuzz'-Niveau.

  • Man lässt einen Maurer ja auch nicht erst eine Wand bauen, sondern stellt ihn anhand seiner Qualifikation direkt ein. Viele Berufe funktionieren so. Wenn die Leistung nicht passt, kann man die Person nach der Einstellung wieder entlassen. Es gibt keinen Grund, diesen demütigenden Unternehmens-Interviewprozess durchlaufen zu müssen.

  • Die besten Ingenieure, die ich erlebt habe, landeten oft bei false negatives. In Live-Coding-Interviews waren sie nervös und konnten nicht zeigen, was sie wirklich können. Deshalb halte ich es für falsch, pauschal zu behaupten, solche Interviews "funktionieren gut".

  • Nach "es kommt darauf an" direkt zu behaupten, "Live-Coding-Interviews funktionieren", ist widersprüchlich. Genauso gut könnte ich sagen: "Es kommt darauf an, aber Live-Coding-Interviews funktionieren nicht." Logisch ist das kein Unterschied.

  • LeetCode kann nützlich sein, um Leute ohne echte Problemlösungskompetenz auszusortieren. Die beste Lösung wäre aber eine Umgebung, in der Kandidaten mit ihren eigenen Tools und in ihrer eigenen Arbeitsumgebung ihr Maximum zeigen können. Gleichzeitig denke ich, dass LeetCode offline am Whiteboard zusammen mit dem Interviewer im Pair Programming vielleicht tatsächlich am fairsten wäre. Das wäre dann wirklich eine komfortable Umgebung.

• Ich denke, beide Erklärungen können gleichzeitig zutreffen. Es gibt tatsächlich "Senior"-Entwickler, die ihre Arbeit nicht gut machen, und Live Coding kann helfen, sie herauszufiltern. Aber man kann auch aus anderen Gründen im Interview scheitern.

  • Es gibt auch viele Entwickler, die in Live Coding gut sind, aber keine Erfahrung mit groß angelegtem Systemdesign haben. Solche Leute bringen oft Technical Debt, Anti-Patterns und Inkonsistenzen in die Codebasis und verschlechtern sie weiter. Das ist eigentlich genau der Typ, den man vermeiden will. Unternehmen glauben oft, ihre vorhandenen Seniors würden die Juniors schon kontrollieren, aber da ohnehin jede Firma behauptet, "unsere Codebasis ist Müll", scheint auch dieses Gegenmittel wenig wirksam zu sein.

  • Wenn man Leute einfach allein in einem Raum sitzen und coden lässt, würde man starke Talente nicht verlieren, die nur in unnatürlichen Umgebungen nicht funktionieren.

  • Heutiges Live Coding geht oft weit über einfache Coding-Tests hinaus. Man muss viele Algorithmen auswendig kennen und in 30 Minuten zwei oder drei davon kombinieren, um das Problem zu lösen. Dadurch verbringt man die ganze Zeit mit dem eigentlichen Knobeln und hat gar keine Gelegenheit mehr, echte Coding-Fähigkeiten zu zeigen.

  • In 20 Jahren Berufspraxis habe ich nie wirklich mit einem solchen "inkompetenten Senior" zusammengearbeitet. Mit Lebenslauf und einem 15-minütigen Gespräch konnte man sie immer ausreichend herausfiltern. Dagegen habe ich deutlich mehr Leute gesehen, die Whiteboard-Interviews bestanden und später der Teamproduktivität schadeten.

  • Ich verstehe nicht, warum eine Umgebung mit knapper Zeitvorgabe und gleichzeitiger Pflicht, vor dem Whiteboard zu denken und alles zu erklären, zwingend nötig sein soll. Wenn das Ziel ist, Leute herauszufiltern, die die reale Arbeit nicht beherrschen, braucht man es nicht so weit zu treiben.

• Soweit ich es sehe, gibt es nur eine einzige Möglichkeit, wirklich zu prüfen, ob jemand eine bestimmte Tätigkeit ausführen kann: Man lässt die Person diese Tätigkeit tatsächlich ausführen. Selbst wenn es alternative Bewertungsmethoden gibt, sehe ich keinen Grund, diese zu verwenden, wenn man echte Arbeit testen kann. Wenn die Arbeit im Unternehmen so komplex ist, dass man sie nicht in einen interviewtauglichen Ausschnitt zerlegen kann, dann besteht eine gute Chance, dass das Unternehmen ohnehin unnötig komplexe Dinge tut. Wenn man zum Beispiel prüfen will, ob jemand 10 Kilogramm heben kann, lässt man die Person einfach 10 Kilogramm heben. Stattdessen veranstaltet man seltsame Tests nach dem Motto: "Wir wollen Kraft messen, also zieh die Hose aus und heb einen 1-kg-Eimer mit dem Hintern hoch." Am Ende muss man nur die Fähigkeiten prüfen, die für die tatsächliche Arbeit nötig sind. Bei einem Koch lässt man in einer echten Küche kochen, bei einer Beratungsstelle beobachtet man Kommunikation in einer simulierten Situation. Selbst beim Telefon-Screening kann man einfach einen Live-Screen betrachten.

  • Dagegen wird eingewandt: "Wenn man im Interview echte Arbeit machen lässt, entstehen dann nicht Probleme mit Betrug oder Lohnausbeutung?" Wenn das Unternehmen die Interviewaufgabe tatsächlich verwertet, kann das rechtlich problematisch werden.

  • Es gibt auch den Vorschlag, Leute für einen Tag, eine Woche oder einen Monat direkt zu beschäftigen und dann bei Eignung fest einzustellen. Allerdings passt so etwas nicht gut zum US-amerikanischen employer-healthcare-System.

  • Aus Unternehmenssicht kostet das schlicht zu viel Zeit. Deshalb nutzt man Proxys, die eher in Richtung false negatives verzerrt sind als in Richtung false positives.

  • Mich würde interessieren, wie du auf die Sorge reagierst, dass echte Arbeit im Interview wie die Forderung nach "kostenloser Arbeit" wirkt.

  • Da die Eingewöhnung in eine neue Organisation lange dauert, kann ein Test mit echter Arbeit sogar ineffizient sein. Ich denke, Live-Coding-Assessments sind besser, um Kommunikation, Problemlösung und reine Coding-Fähigkeit zu messen.

• Seit ich Kinder habe, ist meine Interview-Coding-Leistung drastisch eingebrochen. Früher hatte ich so etwas nie, aber heute steht in Interviews einfach zu viel auf dem Spiel. Wenn ich an Krankenversicherung, Kredite und Ruhestand denke, wird der Druck enorm. Im Interview friere ich völlig ein, und erst hinterher fällt mir die Lösung ein. Je mehr Zeit ich ins Üben stecke, desto schlechter werde ich eher. Wegen meiner Unterhaltspflichten habe ich beim Üben außerdem ein schlechtes Gewissen. Der Lerneffekt ist gering, und ich werde eher noch verkrampfter. Meine Erfahrung aus Big Tech ist, dass diese Interviewform mit dem Gedanken eingeführt wurde, "alle gleich zu testen", tatsächlich aber Veränderungen und Ungleichgewichte in den Lebensumständen überhaupt nicht berücksichtigt. Selbst Kolleginnen und Kollegen, die gut mit Stress umgehen, können ein paar Jahre später ganz anders dastehen. Das Ganze beginnt unter dem Vorwand, Bias zu entfernen, aber ich denke, wir müssen die Methode ändern.

  • Mit diesem Gefühl bist du nicht allein. Mit zunehmendem Alter lernt man langsamer, hat weniger freie Zeit, und dadurch wird LeetCode-Training weniger effizient. Es frustriert mich, dass am Ende einfach Leute mit mehr Zeitressourcen stärker belohnt werden.

  • Ich würde empfehlen, Dinge wie Meditation, Atemübungen, L-Theanin und Betablocker zur Stressreduktion auszuprobieren. Außerdem würde ich raten, Herzfrequenz und Blutdruck mit einer Smartwatch zu überwachen. Solche Methoden helfen tatsächlich, den Teufelskreis des Stresses zu durchbrechen.

• Das ist eine ganz andere Art von Stress als der im Arbeitsalltag, und zwar von sehr hoher Intensität. Um eine Erfahrung aus einem Google-Interview zu teilen: Ich bin der Mensch, der die erste lokale Suchmaschine in den Niederlanden gebaut hat, und bei Google saß mir ein Interviewer mit Cowboyhut gegenüber, der wollte, dass ich mit einem Marker am Whiteboard eine Binärsuche aufschreibe. Ich schreibe im Alltag nie von Hand, sondern arbeite nur mit der Tastatur, und außerdem wollte niemand auf meine Erfahrung mit den von mir entworfenen Suchindizes schauen. Vielleicht wollte Google einfach eine Art "Cowboy"-Mentalität.

  • Ich habe mich früher auch von einem Google-Recruiter zu einem Interview überreden lassen, aber die Interviewer waren so schlecht, dass ich trotz übersprungener technischer Runde seitdem jedes Angebot von Google ablehne. Die meisten Fragen waren reine "Fallen" oder betrafen uralte UNIX-Strukturen ohne Bezug zur Realität, etwa die inode-Struktur. Mit der tatsächlichen Rolle hatte das überhaupt nichts zu tun. Unternehmen brauchen unbedingt Prozesse zur Nachverfolgung und zum Feedback von Interviewfragen sowie Schulungen für Interviewer. Noch immer gibt es sehr viele Firmen, in denen die Fragen vom persönlichen Geschmack des Interviewers abhängen.

  • Diese Struktur hat in Wirklichkeit genau so funktioniert, wie sie beabsichtigt war. Solche Unternehmen wollen Menschen, die jede Demütigung aushalten, die ihnen dort begegnet. Dann wart ihr eben kein guter Fit füreinander, und damit haben letztlich beide Seiten gewonnen.

  • Wenn du es als demütigend empfunden hast, nach Binärsuche gefragt zu werden, dann ist dein Ego vielleicht einfach zu groß.

  • Wenn 250.000 Dollar Jahresgehalt plus zusätzliche Google-Aktienoptionen auf dem Spiel stehen, kann man für einen Tag so eine "Demütigung" durchaus in Kauf nehmen.

• Ich behandle ein Live-Coding-Screening als "Gespräch über Code". Ich mache Bewerbern klar, dass das Ziel des Interviews darin besteht zu prüfen, ob die Kommunikation zwischen uns funktioniert. Nur fachlich stark zu sein reicht nicht, man muss auch zusammenarbeiten können. Wenn jemand zum Beispiel im Gespräch wegen eines Missverständnisses etwas falsch implementiert oder zwar gut coden kann, aber kein technisches Gespräch führen kann, dann ist das ein Problem. Deshalb sind Fragen vom Typ FizzBuzz wichtig: nicht nur, um reine Fähigkeit zu testen, sondern auch die Fähigkeit zu einer technischen Diskussion.

  • Genau. Das Wesen eines Live-Coding-Interviews ist nicht, "ob jemand das Problem lösen kann", sondern "ob jemand erklären kann, wie er oder sie es lösen würde". Ein bisschen technisches Grundwissen und Kommunikationsfähigkeit sind der Kern. Ein großer Teil realer Arbeit besteht darin, Dinge nichttechnischen Managern zu erklären, und unter diesem Blickwinkel ergibt dieser Test Sinn.

  • Diese Art gefällt mir. Ich kann FizzBuzz in mindestens drei Sprachen und auf vier Arten lösen, und ich bin sicher, dass ich alle 12 Varianten erklären kann.

• Ich erkenne dieses Problem ebenfalls, und ich stimme zu, dass es keine wirklich überzeugende Alternative gibt. In meiner Laufbahn habe ich mehrfach Menschen erlebt, die wirklich "wie Ingenieure reden und auftreten, aber tatsächlich nicht coden können". Ich habe oft bereut, im Interview die Coding-Fähigkeit nicht geprüft zu haben. Jüngere Entwickler sollten auch verstehen, dass mehrere Stufen im Einstellungsprozess ältere Bewerber oft sogar begünstigen können. Ich weiß, dass es in der Branche viele Ingenieure gibt, die sich mit unnötiger "Expertise" schmücken, aber reale Coding-Fähigkeit nicht mitbringen. Jemanden einzustellen, ohne je auch nur einmal den tatsächlichen Coding-Prozess gesehen zu haben, ist wie einen Gitarristen nur auf Basis von Lebenslauf, Gespräch und Referenzen für eine Band zu engagieren. So kann immer noch ein Gitarrenexperte eingestellt werden, der in Wirklichkeit nie Gitarre gespielt hat. Solche Leute kommen tatsächlich auf diese Weise durch. Wenn man im Interview nur mutmaßen kann, ohne direkten Beleg zu sehen, greifen am Ende zwangsläufig Vorurteile und Voreingenommenheit.

  • Auf das Argument "Es gibt Probleme, aber keine Alternative" würde ich erwidern, dass es auch Systeme auf Basis von Zulassungen oder Berufslizenzen gibt, etwa bei Ärzten und Anwälten. Niemand verlangt vor einer Operation erst eine Vorführung. Dabei sind die Risiken dort noch viel höher. Tatsächlich sind es oft nur niedrigere Berufsgruppen, bei denen so streng überprüft wird, während Manager oder Führungskräfte mit größerer tatsächlicher Wirkung viel leichter durchkommen.

  • Ich halte es für besser, Menschen Pseudocode an ein Whiteboard schreiben zu lassen. Das reduziert Syntaxstress und zeigt die Problemlogik besser. Außerdem passt das gut zu meiner Art der Zusammenarbeit, bei der wir Ideen gemeinsam am Whiteboard entwickeln.

• Das Phänomen "Stress ist etwas anderes als Fähigkeit" taucht immer wieder auf. Auch das Microsoft-Papier war erschreckend. Die meisten Ratschläge laufen nur darauf hinaus, "mach einfach mehr LeetCode", und ignorieren Stress beziehungsweise Cortisol. Ich trainiere deshalb gezielt, mich an die Stressumgebung selbst zu gewöhnen. Freunde können so ein intensives Training nicht leisten, und Coaches sind pro Stunde zu teuer. Deshalb entwickle ich gerade ein Side-Project namens Tough Tongue AI. Es bietet in einem Live-Code-Editor mit Sprachantworten Echtzeitfragen, Unterbrechungen und unmittelbares Feedback. Durch dieses Training gewöhne ich mich allmählich an die Anspannung, dass "mir jemand zuschaut". Wenn Live-Coding-Interviews bleiben, brauchen wir Wege, nicht nur Algorithmen, sondern die physiologische Reaktion auf Stress selbst zu trainieren.

  • Eines der besten Lernwerkzeuge überhaupt.