De Staff Engineer Interview Loop: Waar Senior Loops Fout Gaan

Waarom de meeste staff loops senior aanbiedingen produceren

De meest voorkomende fout in staff engineer werving is de senior loop runnen met een langere system design ronde en dat een staff loop noemen. Elke interviewer scoort de kandidaat tegen senior benchmarks. De terugkoppeling gaat over of de kandidaat een "sterke senior" is. De hiring manager dringt aan op staff omdat de vacature op staff level open staat. Het aanbod wordt ofwel gedownleveld, ofwel gaat het als staff naar iemand die binnen zes maanden in de problemen komt.

De reden dat dit steeds gebeurt, is dat de rubric voor "senior" goed begrepen wordt — solide codering, eigenaar van een service, begeleidt juniors, ontwerpt features end-to-end — en de rubric voor "staff" niet. Staff engineering is de discipline van het kiezen van het juiste probleem, het afstemmen van een groep teams achter een oplossing, en het hebben van gelijk over technische afwegingen op een schaal waar ongelijk onkosten met zich meebrengt. Geen van deze dingen is zichtbaar in een 45-minuten coding ronde.

Dit bericht is een loop design voor staff en hoger. Het gaat ervan uit dat u al een competente senior loop draait en de aanvullende dimensies wilt testen die staff van een snelle senior onderscheiden. Het gaat niet uit van enige bepaalde bedrijfsgrootte.

De vier dimensies die staff daadwerkelijk onderscheiden

Een nuttige staff rubric scoort tegen deze, met expliciete benchmarks op senior, staff en senior staff niveau:

1. Omvang van oordeel. Kan de kandidaat in een domein dat hij niet kent het juiste probleem identificeren, gegeven onvolledig informatie en concurrerende beperkingen? Middelbare engineers lossen het probleem op dat u geeft. Staff engineers vertellen u welk probleem u moet oplossen.
2. Kwaliteit van architectonische beslissingen. Kunnen zij over een systeem redeneren op een granulairniveau waar de afwegingen reëel zijn — kosten, latency, impact, organisatorische koppeling — en een keuze schriftelijk verdedigen? Dit is niet hetzelfde als het oproepen van een handboek design.
3. Invloed tussen teams. Kunnen zij een moment beschrijven waarop zij de richting van werk buiten hun directe team hebben veranderd, en de mechanismes articuleren — het document, de vergadering, de prototype — die het mogelijk maakten? "Ik heb feedback gegeven in een review" is niet staff-niveau. "Ik schreef het design document dat drie concurrerende voorstel in één consolideerde" is.
4. Technische begeleiding op afstand. Kunnen zij de lat van engineers die zij niet managen verhogen, op onderwerpen waarop zij niet de expert van het team zijn? Dit is de lat die staff van een middelbare engineer met extra jaren onderscheidt.

Elke fase van de loop moet worden ontworpen om één of twee van deze te onderzoeken, niet om de senior lat opnieuw te testen.

De loop, fase voor fase

Totaal: ongeveer 6 uur kandidaattijd, ongeveer 10 uur interviewertijd. Zes fasen:

Fase 1: Hiring manager screen (60 min)

Geen match chat. Een werkgesprek over een echt probleem in uw stack, losjes geformuleerd zodat de kandidaat vragen moet stellen voordat hij iets voorstelt. De hiring manager luistert naar: versmalt hij het probleem voordat hij het oplost? Stelt hij vragen over beperkingen die een middelbare zou overslaan — organisatiestructuur, on-call kosten, migratierisico?

Deze fase vervangt de recruiter-geleide "vertel me over jezelf" ronde. Sla de logistiek op voor een aparte 20-minuten planning call.

Fase 2: Een geschreven design document (4–8 uur, asynchroon)

De fase met het hoogste signaal in een staff loop, en de fase die de meeste bedrijven overslaan omdat zij zich zorgen maken dat het te veel werk is om van een kandidaat te vragen. Dat is het niet. Middelbare kandidaten voltooien routinematig 2-uur take-homes; een staff kandidaat voltooit een gericht design oefening omdat het artefact ook een manier is voor hen om de rol te evalueren.

De prompt: een min of meer reëel, opzettelijk ondergespecificeerd probleem uit uw domein. "We willen een workflow engine introduceren voor de orchestratie die ons payments team momenteel ad-hoc in Lambdas doet. Schrijf een 3–8 pagina's document dat een benadering beargumenteert, de alternatieven noemt die je hebt overwogen, en de top drie risico's identificeert."

Wat het document je vertelt dat een 60-minuten whiteboard niet kan:

• Hoe de kandidaat een argument structureert wanneer hij tijd heeft om na te denken.
• Of zij afwegingen aanvoeren die op uw werkelijke beperkingen betrekking hebben, of hand wave naar algemene beginselen.
• Of zij falingsmodi identificeren die het team nog niet heeft besproken.
• Hoe zij schrijven voor een publiek van andere staff engineers, wat het meeste van de baan is.

Score het document op zijn eigen rubric, voordat de volgende ronde. Een zwak document wordt niet gered door een sterke whiteboard.

Fase 3: Design document deep-dive (75 min)

Een panel van twee — de hiring manager en een staff of principal engineer — werkt door het document met de kandidaat. De kandidaat presenteert niet; het panel leest het document van tevoren en de tijd wordt besteed aan vervolgvragen. Het format:

• Eerste 15 minuten: de alternatieven. "Je hebt een step-functions benadering afgewezen. Waarom? Wat zou veranderen als uw latency budget 50 ms zou zijn in plaats van 5 s?"
• Volgende 30 minuten: de falingsmodi. Loop door hoe het systeem onder drie specifieke voorwaarden die u aangeeft kapot gaat. Bekijk hoe de kandidaat zijn design in real-time aanpast.
• Laatste 30 minuten: de migratie. "We hebben 47 bestaande Lambdas die naar dit moeten gaan. Loop me door de eerste 90 dagen."

Deze fase test dimensies 1 en 2 samen: heeft de kandidaat het juiste probleem geïdentificeerd, en is hun design daadwerkelijk verdedigbaar wanneer de beperkingen veranderen?

Fase 4: Coding ronde (60 min)

Nog steeds vereist, zelfs voor staff. Twee redenen: een staff engineer die helemaal niet kan coderen is zeldzaam en slecht, en de ronde vertelt je of zij nog met middelbare engineers op het werk dat zij daadwerkelijk moeten doen, kunnen pairen.

Sla LeetCode over. Gebruik een debugging of refactoring ronde op min of meer reële code — 200–400 regels, een niet-triviale bug, een expliciete verzoek om de codebase in betere staat achter te laten dan je hem hebt gevonden. Score op de coding rubric die je voor kandidaten op middelbare niveau gebruikt, maar weeg diagnostisch denken en code-review-kwaliteit hoger dan doorvoer.

Een staff kandidaat die vloeiend de bug identificeert, twee meer problemen benoemt die zij niet zal herstellen, en de kleinste veilige refactor uitlegt doet precies wat de baan vereist. Iemand die een middelbare kandidaat op snelheid uit-codeert doet dat niet.

Fase 5: Cross-team influence interview (60 min)

Dit is de ronde die de meeste staff loops niet runnen, en het is degene die de false positive het betrouwbaarst opvangt — de middelbare engineer die problemen briljant oplost maar geen groep teams kan verplaatsen.

Een structured behavioural interview, vier vragen diep, elk een ander mechanisme dieper onderzokend:

1. "Vertel me over een technisch standpunt dat u bekleedde dat impopulair was bij het team. Wat veranderde uw gedachte, of wat veranderde hun gedachte?"
2. "Beschrijf een moment waarop u een project stopte dat niet zou hebben verscheept. Hoe deed u dat zonder het vertrouwen van de mensen die eraan werkten te verliezen?"
3. "Loop me door het laatste technische document dat u schreef dat een ander team als basis voor hun werk aannam."
4. "Vertel me over een moment waarop u een engineer buiten uw rapportlijn begeleiding gaf op iets waarop zij een jaar later beter waren dan u. Wat deed u?"

De antwoorden van de kandidaat moeten mensen, documenten, vergaderingen en resultaten noemen. Vage antwoorden — "we stemden af, we bouwden consensus, we leverde op" — falen deze ronde. De baan is mechanisme-rijk; het interview zou dat ook moeten zijn.

Fase 6: Bar raiser (45 min)

Een staff of principal engineer van buiten het team, evaluering van de kandidaat tegen de staff bar van het bedrijf, niet de behoefte van het team. Hun vraag aan zichzelf aan het einde: "Zou ik met deze persoon aan een probleem dat mij interesseerde willen werken?"

Houd dezelfde dag een debrief met locked scorecards — het format is belangrijker op staff omdat de onenigheid gaat over reikwijdte en oordeel, niet of iemand kan coderen, en dat zijn precies de onenigheid die opgelost wordt door een charismatische interviewer in de kamer.

Wat u moet weglaten

Een paar dingen die de staff loop niet zou moeten bevatten, en de redenen dat elk een valstrik is:

• Twee coding rondes. Eén is genoeg. Een tweede vertelt je niets nieuws en signaleert naar de kandidaat dat je niet weet waarvoor je aanneemt.
• Een system design ronde die alleen maar "design Twitter" is. Generieke prompts testen geheugen. Gebruik een probleem uit uw werkelijke domein zodat de kandidaat daadwerkelijk moet nadenken.
• Een "leadership principles" interview dat het gedragsinterview met een andere naam is. Als u al een structured behavioural round draait, het erin vouwen in één goed ontworpen cross-team ronde is sterker dan twee dunne runnen.
• Een presentatieronde, tenzij presenteren deel uitmaakt van de baan. Het verzoeken aan de kandidaat om 30 minuten vorig werk te presenteren is prima als de rol openbare presentaties aan engineering vereist. Anders test het de verkeerde vaardigheid.

Interviewers kalibreren naar de staff bar

Het moeilijkste deel van het runnen van een staff loop is niet het ronde design — het zorgen dat interviewers weten wat zij scoren. Drie concrete stappen:

1. Schrijf scored gidsen met anchors voor elke dimensie. Een 3-uit-4 op "kwaliteit van architectonische beslissingen" zou iets spécifieks moeten betekenen — bijvoorbeeld, "identificeert de load balancing afweging zonder prompting en legt uit wat het kost om het verkeerd te doen". Een 4 zou moeten betekenen "verhoogt een beperking die de prompt niet bevat en herformeert het probleem". Dit is dezelfde scorecard discipline die op seniorniveau werkt, met verschillende anchors.
2. Voer twee praktijk debriefs uit voordat u de eerste echte houdt. Neem twee recente staff aanbiedingen (één aanvaard, één afgewezen) en laat de loop interviewers ze blind scoren, dan debriefen. Het doel is oppervlakken waar het panel het oneens is over wat staff betekent, voordat een echte kandidaat in het spel is. Dit is precies de calibratie die meeste teams overslaan en het meest betreuren.
3. Volg het downlevel tarief. Als uw loop een staff aanbod 30% van de tijd en een senior aanbod 50% van de tijd voor staff-aangemelde kandidaten produceert, laat uw hiring manager screen te veel middelbare kandidaten door. Als het een no-hire 60% van de tijd produceert, is uw inbound source verkeerd. In beide gevallen zegt het cijfer u waar u het moet oplossen.

Wat u nu kunt doen

Als u een staff engineer loop opzet of herstelt:

1. Schrijf deze week de rubric met vier dimensies. Zelfs een v1 met ruwe anchors is beter dan helemaal geen rubric.
2. Voeg het geschreven design document toe als u dat nog niet hebt. Het is de ronde met het hoogste signaal en de goedkoopste om in te voeren.
3. Vervang een van uw coding rondes door een cross-team influence interview. De ruil is bijna altijd het waard.
4. Voer twee kalibratie debriefs uit op vorige kandidaten voordat u de volgende live loop draait.
5. Controleer de laatste drie staff aankopen retroactief tegen de rubric. Als twee van hen zwak scoren op een dimensie die u niet hebt getest, dat is de ronde die u mist.

Staff werving is geen middelbare werving met een langere system design. Het is een ander rubric, een ander loop, en een ander debrief. De teams die dat uitzoeken werven staff engineers aan die het werk daadwerkelijk doen. De teams die het niet doen werven middelbare engineers met een ander titel aan en vragen zich af waarom hun architectonische schuld maar blijft groeien.