Sample Scorecard

Dimension Scores

• 30STAR StructureResponses are missing clear Situation, Task, Action, and Result components. Exchange 1 and 2 provide vague descriptions without defined scope, personal actions, or measurable results. Exchange 3 outlines a decision but omits the situation context, specific task, and quantified result.
• 45OwnershipCandidate uses 'we' language throughout and does not articulate personal leadership, specific decisions made, or accountability for outcomes. In Exchange 1, they 'looked at configs with the team' but do not state what they personally drove. In Exchange 3, the decision appears collaborative but individual ownership is unclear.
• 20Quantified ImpactNo concrete metrics provided: lag numbers, recovery time, throughput, error rates, latency impact, or cost implications are absent. Candidate admits uncertainty on exact lag numbers in Exchange 2. Exchange 3 mentions 'slower' replication but gives no latency figures, throughput data, or business impact.
• 50DeliveryCommunication is concise but lacks depth, specificity, and confidence. Answers are high-level and uncertain (e.g., 'I think', 'maybe', 'not sure'). The trade-off in Exchange 3 is articulated clearly but without supporting data or reflection on long-term implications.

Top Fixes

1. 01

   Open with a brief, structured self-introduction

   The interview starts before the first question: a 30-second present-past-bridge intro gives the interviewer your frame instead of making them dig for it.

   Present: I'm a backend engineer on the payments team, focused on reliability. Past: I led the ledger rewrite that cut reconciliation time by a third. Bridge: that's why this reliability-heavy role caught my eye.

2. 02

   Quantify the recovery measurement and validation steps

   Demonstrates rigorous operational discipline and ability to define done.

   We tracked recovery via three metrics in Grafana: consumer lag (target <10k), end-to-end payment latency p99 (target <2s), and error rate (target <0.1%). I declared recovery only after all three held for 10 consecutive minutes. Post-incident, we ran a chaos test simulating the same payload surge to verify the fix held under 2x load.

3. 03

   Deepen the ledgerd trade-off with alternatives, criteria, and measurable consequences

   Shows architectural maturity and ability to make data-driven decisions with known trade-offs.

   Situation: Building ledgerd, our new financial ledger service, we needed ACID guarantees at 5k TPS with <5ms p99 write latency. Task: Choose storage backend. Action: We evaluated three options: (1) Postgres with sync replication - team expertise high, latency ~3ms, but write throughput capped ~8k TPS; (2) CockroachDB - horizontal scale, but team had zero experience, added 2-week ramp, latency ~4ms; (3) Custom on RocksDB - max performance, but 6-week build and high ops burden. Decision criteria: time-to-prod (weight 40%), latency SLA (30%), team velocity (20%), operational risk (10%). We chose Postgres, accepting a 20% throughput headroom limit. Result: Shipped in 3 weeks, met latency SLA (p99 2.8ms), handled peak 4.2k TPS. We documented the 8k TPS ceiling and built a migration path to CockroachDB for Q3.

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 flat, unstructured intro: a name, a vague role, no proof points, and an abrupt trailing close.

  ✗ Situation, missing✗ Task, missing✗ Action, missing✗ Result, missing

  The opener is the interviewer's first evidence: no present scope, no past proof point, no bridge to the role. 'I guess that's about it' hands the frame back.

• Thanks for joining, Priya. Tell me about a time you owned a difficult production incident.

  Candidate describes a Kafka lag spike on payments; team looked at consumer configs and restarted pods; issue resolved after a while.

  ✗ Situation, missing✗ Task, missing✗ Action, missing✗ Result, missing

  No clear situation scope, personal task, specific actions, or measurable result. Uses collective 'we' without individual ownership.

• What specifically did you change, and how did you measure recovery?

  Candidate thinks partition count was increased; unsure of exact lag numbers; monitored Grafana until it looked normal.

  ✗ Situation, missing✗ Task, missing✗ Action, missing✗ Result, missing

  Lacks specificity on what was changed, by whom, and how recovery was measured. No metrics or validation criteria provided.

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

  Team chose Postgres over purpose-built ledger DB due to familiarity; accepted slower sync replication for safety.

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

  Outlines a trade-off but missing situation context (scale, latency requirements), explicit decision criteria, alternatives evaluated, and quantified outcomes (latency numbers, throughput, timeline).