Die meisten Interview-Fragen, die ich geerbt habe, als ich anfing einzustellen, waren Trivia im Trenchcoat: clever genug, um rigoros zu wirken, spezifisch genug, um fair zu wirken, und nahezu vollständig unkorreliert mit allem, was mich danach interessiert hat. Dieser Post ist die kurze Liste dessen, was ich tatsächlich gelernt habe, als ich sie durch Work Samples ersetzt habe — plus die Fragen, die ich behalten habe, weil sie ihren Platz noch verdienen.

Die Trenchcoat-Signale

Trivia-im-Trenchcoat-Interviewfragen haben eine Familienähnlichkeit. Ich erkenne sie jetzt innerhalb von etwa zehn Sekunden:

  • Sie haben eine richtige Antwort. Gute Kandidaten kommen nicht zu “ungefähr richtig” — sie kennen den Trick, oder sie kennen ihn nicht.
  • Sie belohnen Oberflächenvertrautheit mit einer bestimmten Codebase oder einem Sprachfeature, kein Urteilsvermögen.
  • Ihr Rubrik misst heimlich “Hat dieser Kandidat genau diesen Trick auswendig gelernt?” statt “Kann dieser Kandidat den Job machen?”
  • Der Interviewer, der sie liebt, wurde dieselbe Frage vor drei Jobs gestellt und ist immer noch ein bisschen stolz, sie gelöst zu haben.

Wenn du dich dabei ertappst, so eine Frage zu schreiben, stopp. Der Stolz ist das Signal. Gute Fragen überleben nicht, weil sie clever sind; sie überleben, weil sie langweilig sind und funktionieren.

Vier Fragen, die ich eingestellt habe

Ich nenne die Unternehmen nicht, aber das sind alles Fragen, die ich geerbt und gelöscht habe, sobald ich wirklich zu messen begann, was gute Hires voraussagt.

”Invertier einen Binary Tree auf dem Whiteboard”

Ich habe in einem Jahrzehnt Production-Code exakt null Binary-Tree-Invertierungen geschrieben. Vielleicht zwei gelesen. Die Frage ist vollständig ein Filter für “hat diese Person kürzlich mit genau dieser Frage interviewgeübt.” Sie selektiert hart für Leute, die aktiv auf Jobsuche sind, und gegen Leute, die gerade beschäftigt und zufrieden sind — das ist die falsche Richtung.

”Wie würdest du Twitter designen?”

Systemdesign-Fragen sind nicht das Problem; “Design Twitter” schon. Es belohnt Kandidaten, die sich den spezifischen Rollup von Twitters Architektur eingeprägthaben — User, Tweets, Fanout-on-Write, Cache-Layer — gegenüber Kandidaten, die tatsächlich über ein System nachdenken können, das sie noch nie gesehen haben.

Ich stelle jetzt Systemdesign-Fragen über ein obskures System, von dem der Kandidat noch nie gehört hat. “Designiere ein System, das in Echtzeit Gebote für Ad-Inventory über sechs Regionen hinweg abgleicht.” Novel genug, dass niemand es auswendig gelernt hat; konkret genug, dass die Tradeoffs real sind. Gute Kandidaten stellen Klärungsfragen. Die Auswendiglerner frieren ein.

”Was ist die Zeitkomplexität von sort in [Sprache X]?”

Das ist eine reine Trivia-Frage. Die richtige Antwort ist “nachschlagen.” Ein Senior-Engineer, der sich Standard-Library-Komplexitätsgrenzen einprägt, hat Regalplatz für das getauscht, was wirklich zählt — Urteilsvermögen darüber, wann man sich um Komplexität sorgen soll und wann nicht. Den Auswendiglerner will ich nicht.

”Erklär mir [spezifisches obskures CS-Konzept]”

“Erkläre das CAP-Theorem.” “Was ist der Unterschied zwischen BASE und ACID?” “Was ist ein Merkle Tree?” Das sind gute Gesprächseinstieg. Sie sind katastrophal als Filter, weil sie für Leute selektieren, die das Vokabular kürzlich gelernt haben, statt für Leute, die die zugrundeliegenden Constraints verstehen. Ich habe Engineers getroffen, die das CAP-Theorem im Schlaf rezitieren können und keine Eventual Consistency in einem Production-Setting hinbekommen. Ich habe Engineers getroffen, die das Wort “CAP” nie benutzt haben und seit einem Jahrzehnt korrekte verteilte Systeme bauen. Filtere auf das Verhalten, nicht auf das Vokabular.

Drei Fragen, die ich behalten habe

Die, die mein Rewrite überlebt haben, teilen alle eine Struktur: Sie geben dem Kandidaten ein Stück echter Arbeit, oder etwas sehr Ähnliches, und schauen, wie er darüber nachdenkt.

”Hier ist ein echter Bug-Report aus unserem System. Debug ihn.”

Das Gold-Standard-Technical-Interview in meiner Erfahrung. Wir geben dem Kandidaten einen echten (anonymisierten) Bug-Report: Symptome, Logs, einen partiellen Stack-Trace, einen Commit, der möglicherweise damit zusammenhängt. Wir beobachten 45 Minuten lang, wie er darüber nachdenkt. Er kann uns alles fragen.

Diese Frage ist high-signal, weil sie testet:

  • Neugier — fragt er nach dem System, bevor er auf einen Fix springt?
  • Pattern Recognition — hat er diese Art von Bug schon mal ungefähr gesehen?
  • Urteilsvermögen — weiß er, wann er aufhören soll zu debuggen und anfangen soll zu hypothetisieren?
  • Kommunikation — kann er sein Reasoning erklären, während er es macht?

Es ist auch fair, auf eine Art, wie Auswendiglern-Fragen es nicht sind: Jeder Kandidat hat denselben Bug, und das Rubrik ist “haben sie uns gezeigt, wie sie denken” — nicht “haben sie die eine richtige Antwort gefunden”.

”Erzähl mir von einer technischen Entscheidung, die du heute bereust.”

Jede Senior-Engineerin hat eine. Kandidaten, die keine haben, sind entweder sehr junior oder sehr unehrlich gegenüber ihrer eigenen Arbeit. Die guten Antworten sind spezifisch (das Projekt, das Jahr, die Konsequenz), reflektiert (was sie anders machen würden) und fair dem früheren Ich gegenüber (die Entscheidung war vernünftig angesichts der damaligen Informationen).

Die besten Antworten beinhalten: “Und das ist, was ich dadurch an meiner Entscheidungsfindung geändert habe.” Das ist das Signal. Nicht die Reue selbst — die Fähigkeit, den Kreis zu schließen.

”Was würdest du deinem künftigen Manager fragen, was du dem Recruiter nicht fragen würdest?”

Das ist die einzige Frage, bei der die Antwort meine Einstellungsentscheidung am meisten beeinflusst hat.

Gute Kandidaten fragen nach konkreten Dingen: Wie handhabt das Team On-Call, wie sieht die Code-Review-Kultur aus, was passiert, wenn ein Feature zu spät geshipt wird, wie viele Engineers sind gerade im Team.

Red-Flag-Kandidaten fragen nach Signaling-Dingen: die Beförderungsleiter, den Impact-Track, die “strategische Ausrichtung”. Nicht weil das schlechte Fragen wären — sie sind berechtigt — sondern weil es die Fragen sind, die ein Kandidat stellt, wenn er mehr Karriere-Blogs gelesen hat als er geshipt hat. Der erste Bucket ist Engineering-Urteil; der zweite ist Karriere-Optik.

Der Work-Sample-Trick

Für Senior-Kandidaten lehne ich mich jetzt stark auf Work Samples: Der Kandidat macht ein kleines Stück echter Arbeit, in seiner eigenen Zeit, in seinem eigenen Editor, an einem Problem, das dem nahe ist, was er am ersten Tag tun würde. Nicht “bau einen Compiler in 90 Minuten”. Eher “Hier ist eine 400-Zeilen-Datei, die X schlecht macht; bitte refactore sie so, wie du es normalerweise würdest, nimm dir so lange wie du brauchst, erkläre deine Entscheidungen in einem Follow-Up.”

Die Einwände, die ich gehört habe:

  • “Es ist nicht fair für Menschen mit weniger Freizeit.” Das ist ein echtes Problem, aber die Lösung ist das Work Sample zu bezahlen (was ich getan habe) oder es klein zu halten (was ich getan habe) — nicht zurück zu Whiteboard-Trivia zu gehen.
  • “Kandidaten werden KI nutzen.” Ich hoffe es! Der Job wird KI beinhalten. Ich will sehen, wie sie sie nutzen. Ein Kandidat, der einen sauberen, KI-unterstützten Refactor mit einer durchdachten Erklärung dessen einreicht, was er behalten und was er geändert hat, demonstriert den echten Skill 2026.
  • “Es nimmt mehr von der Zeit des Kandidaten in Anspruch als eine 1-stündige Technical-Round.” Ja. Es gibt mir auch deutlich bessere Signale. Die richtige Anpassung ist, weniger Interview-Runden zu haben, nicht kürzere.

Der Teil, wo ich zugebe, dass ich noch immer manchmal falsch liege

Ich will nicht behaupten, Interviews geknackt zu haben. Habe ich nicht. Ich habe Kandidaten abgelehnt, die wahrscheinlich gut gewesen wären, und Kandidaten eingestellt, die sich als falsche Fits herausgestellt haben. Jede Senior-Engineerin, die ein Jahrzehnt lang einstellt, hat dieselbe Liste.

Was ich am sichersten weiß: Die Trivia-im-Trenchcoat-Interviewfrage ist immer schlechter als die Alternative. Jedes Mal, wenn ich eine verabschiedet habe, habe ich bessere Signale bekommen. Jedes Mal, wenn ich eine “aus Tradition” behalten habe, habe ich es später bereut.

Wenn du gerade einstellst: Auditiere deine Loop. Frag für jede Frage: “Wie sieht eine großartige Antwort darauf aus, und würde diese Antwort tatsächlich Erfolg im Job voraussagen?” Wenn du die prädiktive Version nicht aufschreiben kannst, verabschiede die Frage. Ersetze sie durch ein Work Sample, einen echten Bug oder ein klärendes Gespräch über die Vergangenheit des Kandidaten.

Deine Loop wird kürzer. Deine Hires werden besser. Und du wirst aufhören, Leute zu bitten, Binary Trees auf Whiteboards zu invertieren — was 2026 ein kleiner zivilisatorischer Fortschritt ist.