Die Staff Engineer Interview-Loop: Was Senior Loops falsch machen

Warum die meisten Staff Loops Senior-Angebote produzieren

Der häufigste Fehler beim Hiring von Staff Engineers besteht darin, die Senior Loop zu verwenden und einfach die System Design Phase zu verlängern und das Ganze dann eine Staff Loop zu nennen. Jeder Interviewer bewertet die Kandidaten nach Senior-Maßstäben. Das Feedback-Gespräch dreht sich darum, ob es ein „starker Senior" ist. Der Hiring Manager drängt auf Staff, weil die Position auf Staff-Level ausgeschrieben ist. Das Angebot wird dann entweder heruntergestuft oder geht raus auf Staff-Level für jemanden, der in weniger als sechs Monaten scheitern wird.

Der Grund, warum das ständig passiert, ist, dass die Bewertungskriterien für „Senior" gut verstanden sind — solide Programmierung, verwaltet einen Service, mentoriert Juniors, designt Features end-to-end — und die Kriterien für „Staff" sind viel weniger klar. Staff Engineering ist die Disziplin, das richtige Problem auszuwählen, eine Gruppe von Teams hinter einer Lösung zu vereinigen und technische Trade-offs auf einer Ebene richtig einzuschätzen, wo Fehler teuer sind. Keine dieser Dinge ist in einer 45-Minuten-Coding-Session sichtbar.

Dieser Post ist ein Loop-Design für Staff und höhere Level. Er geht davon aus, dass Sie bereits eine kompetente Senior Loop durchführen und die zusätzlichen Dimensionen testen möchten, die Staff von einem schnellen Senior unterscheiden. Es wird keine bestimmte Unternehmensgröße angenommen.

Die vier Dimensionen, die Staff tatsächlich auszeichnen

Eine sinnvolle Staff-Bewertungsrubrik sollte gegen diese Dimensionen bewertet werden, mit expliziten Ankerpunkten auf Senior-, Staff- und Senior Staff-Ebene:

1. Urteilsfähigkeit im großen Maßstab. Kann die Kandidatin in einer ihr unbekannten Domäne das richtige Problem identifizieren, gegeben unvollständige Informationen und konkurrierende Anforderungen? Senior Engineers lösen das Problem, das man ihnen gibt. Staff Engineers sagen dir, welches Problem du lösen solltest.
2. Qualität von Architekturentscheidungen. Kann sie ein System auf einer Granularitätsebene durchdenken, auf der Trade-offs real sind — Kosten, Latenz, Blast Radius, organisatorische Koppelung — und eine Entscheidung schriftlich verteidigen? Das ist nicht dasselbe wie das Abrufen eines Lehrbuch-Designs.
3. Einfluss über Teams hinweg. Kann sie von einem Moment beschreiben, in dem sie die Richtung von Arbeiten außerhalb ihres direkten Teams verändert hat, und die Mechanismen artikulieren — das Dokument, das Meeting, den Prototyp — die das ermöglicht haben? „Ich habe Feedback in einem Review gegeben" ist nicht Staff-Level. „Ich habe das Design-Dokument geschrieben, das drei konkurrierende Vorschläge in einen konsolidiert hat" ist es.
4. Technische Mentorschaft in der Ferne. Kann sie den Standard von Engineers erhöhen, die sie nicht führt, zu Themen, wo sie nicht die Expertin des Teams ist? Das ist die Grenze, die Staff von einem Senior Engineer mit zusätzlichen Jahren unterscheidet.

Jede Phase der Loop sollte entworfen sein, um ein oder zwei dieser Dimensionen zu prüfen, nicht um die Senior Bar neu zu testen.

Die Loop, Phase für Phase

Gesamt: ~6 Stunden für Kandidaten, ~10 Stunden für Interviewer. Sechs Phasen:

Phase 1: Hiring Manager Screen (60 min)

Kein Fit-Gespräch. Ein sachliches Gespräch über ein echtes Problem in deinem Stack, locker genug formuliert, dass die Kandidatin Fragen stellen muss, bevor sie etwas vorschlägt. Der Hiring Manager sucht nach: Grenzt sie das Problem ein, bevor sie es löst? Fragt sie nach Constraints, die ein Senior überspringen würde — Organisationsstruktur, On-Call-Kosten, Migrationrisiken?

Diese Phase ersetzt das von Recruiting geleitete „Erzähl mir von dir"-Gespräch. Verschiebe die Logistik auf ein separates 20-Minuten-Scheduling-Gespräch.

Phase 2: Ein schriftliches Design-Dokument (4–8 Stunden, asynchron)

Die einzeln hochwertigste Phase in einer Staff Loop, und diejenige, die die meisten Unternehmen überspringen, weil sie sich sorgen, dass es zu viel Arbeit für eine Kandidatin ist. Das ist es nicht. Senior-Kandidaten absolvieren routinemäßig 2-Stunden-Take-Home-Aufgaben; eine Staff-Kandidatin absolviert eine fokussierte Design-Aufgabe, weil das Artefakt auch eine Möglichkeit für sie ist, die Rolle zu evaluieren.

Der Prompt: ein echtes, absichtlich unterbestimmtes Problem aus deiner Domäne. „Wir möchten ein Workflow-Engine für die Orchestrierung einführen, die unser Payments-Team derzeit mit Ad-Hoc-Lambdas macht. Schreib ein 3–8-Seiten-Dokument, das einen Ansatz begründet, die Alternativen nennt, die du überlegt hast, und die Top-3-Risiken identifiziert."

Das sagt dir das Dokument, das ein 60-Minuten-Whiteboard nicht kann:

• Wie strukturiert die Kandidatin ein Argument, wenn sie Zeit zum Nachdenken hat.
• Ob sie Trade-offs nennt, die deinen echten Constraints entsprechen, oder ob sie allgemeine Prinzipien herumfuchtelt.
• Ob sie Fehlermöglichkeiten identifiziert, die das Team noch nicht diskutiert hat.
• Wie sie für ein Publikum von anderen Staff Engineers schreibt, was der Großteil des Jobs ist.

Bewerte das Dokument nach einer eigenen Rubrik, bevor die nächste Phase. Ein schwaches Dokument wird nicht durch ein starkes Whiteboard gerettet.

Phase 3: Design-Dokument Tiefenanalyse (75 min)

Ein Panel von zwei — der Hiring Manager und ein Staff oder Principal Engineer — arbeitet das Dokument mit der Kandidatin durch. Die Kandidatin präsentiert nicht; das Panel liest das Dokument vorher und die Zeit wird für Nachfragen genutzt. Das Format:

• Erste 15 Minuten: die Alternativen. „Du hast einen Step-Functions-Ansatz ausgeschlossen. Warum? Was würde sich ändern, wenn dein Latenz-Budget 50 ms statt 5 s wäre?"
• Nächste 30 Minuten: die Fehlermöglichkeiten. Geh durch, wie das System unter drei spezifischen Bedingungen, die du bereitstellst, zusammenbricht. Beobachte, wie die Kandidatin ihr Design in Echtzeit anpasst.
• Letzte 30 Minuten: die Migration. „Wir haben 47 existierende Lambdas, die zu diesem System wechseln müssen. Geh mir durch die ersten 90 Tage."

Diese Phase testet Dimensionen 1 und 2 zusammen: Hat die Kandidatin das richtige Problem identifiziert, und ist ihr Design tatsächlich verteidigbar, wenn sich die Constraints ändern?

Phase 4: Coding Round (60 min)

Immer noch erforderlich, auch für Staff. Zwei Gründe: Ein Staff Engineer, der überhaupt nicht programmieren kann, ist selten und schlecht, und die Phase sagt dir, ob er/sie immer noch mit Senior Engineers auf der Arbeit, die sie tatsächlich tun müssen, paaren kann.

Überspring LeetCode. Verwende eine Debugging- oder Refactoring-Phase auf echtem Code — 200–400 Zeilen, ein nicht-triviales Bug, eine explizite Anfrage, die Codebase in besserer Form zu hinterlassen, als sie gefunden wurde. Bewerte nach der Coding-Rubrik, die du für Senior-Kandidaten verwendest, aber gewichte diagnostisches Denken und Code-Review-Qualität höher als Durchsatz.

Eine Staff-Kandidatin, die flüssig das Bug identifiziert, zwei weitere Probleme nennt, die sie nicht beheben wird, und die kleinste sichere Umstrukturierung erklärt, macht genau das, was der Job erfordert. Einer, der einen Senior-Kandidaten bei der Geschwindigkeit übertrifft, tut es nicht.

Phase 5: Cross-Team Influence Interview (60 min)

Das ist die Phase, die die meisten Staff Loops nicht durchführen, und es ist diejenige, die zuverlässigst die falsch-positive abfängt — den Senior Engineer, der Probleme brilliant löst, aber eine Gruppe von Teams nicht bewegen kann.

Ein strukturiertes Behavioral-Interview, vier Prompts tief, jeder bohrt in einen anderen Mechanismus:

1. „Erzähl mir von einer technischen Position, die du hattest und die beim Team unbeliebt war. Was hat deine Meinung geändert, oder was hat die des Teams geändert?"
2. „Beschreib einen Moment, in dem du ein Projekt gestoppt hast, das nicht hätte shipped werden sollen. Wie hast du es getan, ohne das Vertrauen der Leute zu verlieren, die daran gearbeitet haben?"
3. „Geh mir durch das letzte technische Dokument, das du geschrieben hast und das ein anderes Team als Grundlage für ihre Arbeit adoptiert hat."
4. „Erzähl mir von einem Moment, in dem du einen Engineer außerhalb deiner Berichtsstruktur zu etwas mentoriert hast, in dem er/sie ein Jahr später besser war als du. Was hast du getan?"

Die Antworten der Kandidatin sollten Personen, Dokumente, Meetings und Ergebnisse nennen. Vage Antworten — „wir haben uns abgestimmt, wir haben Konsens aufgebaut, wir haben shipped" — fallen durch diese Phase. Der Job ist mechanismusreich; das Interview sollte es auch sein.

Phase 6: Bar Raiser (45 min)

Ein Staff oder Principal Engineer von außerhalb des Teams, der die Kandidatin gegen die Staff Bar des Unternehmens bewertet, nicht gegen das Bedürfnis des Teams. Ihre Frage an sich selbst am Ende: „Möchte ich mit dieser Person an einem Problem arbeiten, das mir wichtig ist?"

Halte ein Feedback-Gespräch am selben Tag mit gesperrten Bewertungskarten — das Format ist wichtiger auf Staff-Level, weil die Uneinigkeiten über Umfang und Urteil sind, nicht ob jemand programmieren kann, und genau diese Uneinigkeiten werden von einem charismatischen Interviewer im Raum aufgelöst.

Was man weglässt

Ein paar Dinge, die die Staff Loop nicht enthalten sollte, und warum jeder ein Fallstrick ist:

• Zwei Coding Rounds. Eine ist genug. Eine zweite sagt dir nichts Neues und signalisiert der Kandidatin, dass du nicht weißt, wofür du einstellst.
• Eine System Design Round, die nur „design Twitter" ist. Generische Prompts testen Auswendiglernen. Verwende ein Problem aus deiner echten Domäne, damit die Kandidatin tatsächlich denken muss.
• Ein „Leadership Principles" Interview, das das Behavioral Interview mit anderem Namen ist. Wenn du bereits eine strukturierte Behavioral Round durchführst, ist das Zusammenfassen in ein gut gestaltetes Cross-Team Interview stärker, als zwei dünne durchzuführen.
• Eine Präsentations-Round, außer Präsentieren ist Teil des Jobs. Die Kandidatin zu bitten, 30 Minuten bisherige Arbeit zu präsentieren, ist in Ordnung, wenn die Rolle öffentliche Präsentationen vor Engineering erfordert. Ansonsten testet es die falsche Fähigkeit.

Interviewer auf die Staff Bar kalibrieren

Der schwierigste Teil einer Staff Loop ist nicht das Round-Design — es ist sicherzustellen, dass Interviewer wissen, was sie bewerten. Drei konkrete Schritte:

1. Schreib Bewertungshandbücher mit Ankern für jede Dimension. Ein 3-von-4 bei „Architekturentscheidungs-Qualität" sollte etwas Spezifisches bedeuten — zum Beispiel „identifiziert den Load-Balancing Trade-off ohne Prompting und erklärt die Kosten, das falsch zu machen". Ein 4 sollte bedeuten „nennt eine Constraint, die der Prompt nicht enthielt, und rahmt das Problem neu". Das ist dieselbe Scorecard-Disziplin, die auf Senior-Level funktioniert, mit anderen Ankern.
2. Führe zwei Übungs-Debriefs durch, bevor das erste echte läuft. Nimm zwei kürzliche Staff-Angebote (eines angenommen, eines abgelehnt) und lass die Loop-Interviewer sie blind bewerten, dann debrief. Der Punkt ist, zu zeigen, wo sich das Panel uneinig ist über das, was Staff bedeutet, bevor eine echte Kandidatin auf der Linie ist. Das ist genau die Kalibrierung, die die meisten Teams überspringen und bereuen.
3. Verfolge die Downlevel-Rate. Wenn deine Loop ein Staff-Angebot 30% der Zeit und ein Senior-Angebot 50% der Zeit für Staff-bewerbende Kandidaten produziert, lässt dein Hiring Manager Screen zu viele Senior-Kandidaten durch. Wenn es 60% der Zeit „no hire" produziert, ist deine Inbound-Quelle falsch. Auf jeden Fall sagt dir die Metrik, wo du es beheben musst.

Was man als Nächstes tut

Wenn du eine Staff Engineer Loop aufbaust oder reparierst:

1. Schreib die Vier-Dimensionen-Rubrik diese Woche. Auch ein v1 mit rauen Ankern schlägt gar keine Rubrik.
2. Füge das schriftliche Design-Dokument hinzu, wenn du nicht bereits eines hast. Es ist die wertvollste Round und die billigste einzuführen.
3. Ersetze eine deiner Coding Rounds mit einem Cross-Team Influence Interview. Der Austausch lohnt sich fast immer.
4. Führe zwei Kalibrierungs-Debriefs auf bisherigen Kandidaten durch, bevor die nächste Live-Loop läuft.
5. Audit die letzten drei Staff-Angestellten gegen die Rubrik rückwirkend. Wenn zwei von ihnen schwach auf einer Dimension bewerten, die du nicht getestet hast, ist das die Round, die du vermisst.

Staff Hiring ist nicht Senior Hiring mit einer längeren System Design Phase. Es ist eine andere Rubrik, eine andere Loop und ein anderes Debrief. Die Teams, die das herausfinden, stellen Staff Engineers ein, die tatsächlich den Job machen. Die, die es nicht tun, stellen Senior Engineers mit einem anderen Titel ein und fragen sich, warum ihre Architecture Debt weiter wächst.