Sample Scorecard · Follow-up

Dimension Scores

• 78STAR StructureAll three exchanges now open with scoped situations, name the personal task, list concrete actions, and close with measurable results. Exchange 1 states lag volume, user impact, and recovery targets explicitly.
• 72OwnershipThe candidate consistently uses first-person actions: 'I raised the alarm threshold', 'I paired with the SRE', 'I declared recovery only after the metrics held'. Collective 'we' is replaced by accountable ownership.
• 68Quantified ImpactRecovery is defined with three concrete metrics (consumer lag <10k, p99 <2s, error rate <0.1%) and a chaos test at 2x load. The ledgerd trade-off cites latency and auditability numbers.
• 65DeliveryAnswers are tighter and more confident than the earlier attempt, though the third exchange still trails into hedged phrasing at the end.

Top Fixes

1. 01

   Cut the trailing hedge at the end of answers

   Strong answers end on the result; trailing qualifiers ('I think that worked out okay') undercut an otherwise crisp delivery.

   End on the metric: 'Lag recovered to under 10k in 9 minutes and stayed there through the chaos test, so we closed the incident.'

2. 02

   Name the alternative you rejected on the ledgerd choice

   Trade-off answers land harder when the interviewer hears what was ruled out and on which criteria.

   We considered a purpose-built ledger DB, but Postgres won on two criteria: the team's existing operational fluency and our 40ms p99 write budget, which sync replication met at 38ms.

3. 03

   Tie the chaos test back to user-facing risk

   Verification numbers matter most when linked to the failure they prevent.

   We replayed a 2x payload surge in staging to prove the same 12% checkout timeout couldn't recur, and it held under 1%.

Session debrief

What was said and noted during the round — re-read after practice, when you have time to analyze.

Answers (STAR)

Each answer is checked for Situation, Task, Action and Result - filled tag covered, dashed tag missed.

• Before we start - tell me about yourself.

  Candidate gives a 30-second present-past-bridge intro: payments reliability focus, ledger rewrite proof point, why this role.

  ✓ Situation, covered✓ Task, covered✓ Action, covered✓ Result, covered

  Applies the opening fix from the earlier session: brief, structured, and hands the interviewer a clear frame.

• Tell me about a time you owned a difficult production incident.

  Candidate scopes the Kafka lag incident precisely (2.3M messages, ~12% checkout timeouts), names personal actions, and closes with the recovery metric.

  ✓ Situation, covered✓ Task, covered✓ Action, covered✓ Result, covered

  Full STAR coverage with numbers. Slight trailing hedge at the end softens an otherwise strong close.

• How did you know the fix actually held?

  Candidate defines recovery on three Grafana metrics held for 10 minutes and describes a chaos test at 2x load validating the fix.

  ✓ Situation, covered✓ Task, covered✓ Action, covered✓ Result, covered

  Quantified 'definition of done' plus a verification step is exactly the rigor interviewers probe for.

• Walk me through a trade-off you made on ledgerd.

  Candidate contrasts Postgres with a purpose-built ledger DB on team fluency and a 40ms p99 write budget, then states the outcome.

  ✓ Situation, covered✓ Task, covered✓ Action, covered✗ Result, missing

  Alternatives and criteria are explicit, but the close stops at 'slower but safer' without tying the outcome to a measurable result - one gap left to fix.