Im Februar 2013 veröffentlichte 37signals „Why we don't hire programmers based on puzzles and tricks“ im Firmenblog, und der Beitrag landete am selben Tag auf Hacker News. Die Diskussion begann mit den Schwächen trivia-getriebener Einstellung: Ein Microsoft-Interviewter hatte sich mit How Would You Move Mount Fuji? vorbereitet und wurde gebeten, C's strcmp() aus dem Gedächtnis zu schreiben, Amazon-Interviews stützten sich auf das Rezitieren von Big-O und „zähle alle Sterne im Universum“, und Interviewer suchten oft einfach nach „programming interview questions“, ohne zu fragen, was die Antworten belegten.

Der Gegenzug von 37signals bestand darin, das Genre rundheraus abzulehnen: keine Einstellung anhand von Rätseln und Tricks. Kommentatoren beschrieben die Alternative als „trying them out for size“ – Kandidaten vor tatsächliche Arbeit zu stellen statt vor synthetische Denksportaufgaben. Praktiker drängten mit konkreten Mechanismen in dieselbe Richtung: ITA Software fand persönliches Abfragen weit weniger nützlich als das Lesen von Code, den jemand offline geschrieben hatte, und ein Einstellungsmanager baute Interviews um einen Tag des Pairings herum, der drei Fragen stellte – können sie die Arbeit erledigen, passen sie ins Team, und können sie sich anpassen, wenn sich das Spiel ändert?

Die beiden Filter prüfen unterschiedliche Dinge. Trivia und Denksportaufgaben sind trainierbar – es existiert eine ganze Überlieferung erwarteter Fragen und Vorbereitungsbücher – und sie selektieren auf Abruf und Fassung unter künstlichem Druck. Kommentatoren merkten an, dass einsichtsorientierte Denker eine Stunde prozeduralen Abfragens scheitern können, sich aber über eine längere reale Aufgabe gut schlagen, und ein Kandidat mitten in einer Panikattacke könnte an FizzBuzz scheitern und dennoch ein guter Programmierer sein. Beobachtete Arbeit beantwortet die Frage, die Trivia nicht beantworten kann: wie die Person eine unbekannte Codebasis liest, Fehler erkennt, Code schreibt und mit Fremden zusammenarbeitet.

Lass den Rätsel-Parcours fallen: Erprobe Kandidaten in der Praxis und lass echte Arbeit, nicht Abruf, über Einstellungen entscheiden

Rätselfilter sind trainierbar: Eine Überlieferung erwarteter Fragen und Vorbereitungsbücher ermöglicht Kandidaten das Üben, sodass der Test Vorbereitung und Gedächtnis misst, nicht die Fähigkeit für die Arbeit.

Kandidaten in der Praxis zu erproben beobachtet die tatsächliche Arbeit – eine reale Codebasis lesen, Fehler erkennen, Code schreiben und zusammenarbeiten – Belege, die keine Denksportaufgabe liefern kann.

Künstlicher Druck verzerrt Ergebnisse: einsichtsorientierte und ängstliche Kandidaten können an einstündigen Rätseln scheitern und sich dennoch über eine längere Zeitspanne bei realer Arbeit gut schlagen.

Die öffentliche Haltung signalisiert, was dem Unternehmen wichtig ist, und eröffnete eine Debatte mit 442 Kommentaren, die die Idee öffentlich auf die Probe stellte.

Wenn ein Einstellungsfilter mehr die Vorbereitung misst als die Arbeit, ändere die Belege: Erprobe Kandidaten an realer Arbeit und lass die Leistung entscheiden

Der Essay erhielt 648 Punkte und 442 Kommentare auf Hacker News und machte 37signals zum Referenzpunkt der Anti-Rätsel-Seite. Befürworter sagten, harte Denksportaufgaben zeigten Problemlösung unter Druck; Gegner hielten mit einem Tag des Pairings, FizzBuzz als billigem Negativfilter und ITAs Praxis des Lesens von Offline-Code dagegen. Der Erprobungsansatz wurde als gut, aber für weniger bekannte Arbeitgeber als unpraktisch bezeichnet, die Rätsel weiterhin als Talentmagneten bräuchten. In der Diskussion erscheint kein gemessenes Einstellungsergebnis; die Wirkung war normativ – „trying them out for size“ wurde zur Hauptalternative zu Trivia-Interviews.

DEN BELEGEN FOLGEN

Die Quellen

  1. Why we don't hire programmers based on puzzles and tricks | Hacker News Hacker News · news.ycombinator.com ·