What the report looks like
This is the report format you receive after a 45-minute practice interview. Every claim carries a timestamp chip — tap one to see the exact moment in the transcript it came from. That is the whole point: not “communication: 7/10”, but what you said, when, and what to do about it.
Illustrative sample
A fictional candidate interviewing for a backend role, written to show the format and depth. It is not a real person's interview — we never publish those.
Interview report
Backend Engineer (2–4 yrs)
Sample Product Company
6 questions · 44 minutes
Scorecard
- Service ownership & system context
Describes a real system with concrete scale, stack, and boundaries without prompting.
- Database performance & indexing
Diagnosed and fixed a real slow query, but explains the fix by outcome rather than mechanism.
- Idempotency & data correctness
Knows a unique constraint protects against duplicates; unsure how file-level deduplication actually works.
- Scaling & redesign
Reaches for set-based processing over row-by-row loops when pushed on 10× volume.
- Distributed systems / queues
Not reached in this interview.
Strengths — with the moments that prove them
You open with system context most candidates omit — stack, data volume, and upstream dependencies — which lets an interviewer ask sharper follow-ups immediately.
You located the bottleneck yourself rather than describing the system as uniformly slow, and named the exact step that degrades under load.
Under a 10× volume premise you moved from row-by-row processing to a set-based approach — the right instinct, and you reached it without being led there.
When the inconsistency in your timings was raised, you corrected yourself immediately and precisely instead of defending the earlier number. Interviewers read that as trustworthy.
Gaps & misses — with the moments that show them
You justified the index by its result (four hours to one) but not its mechanism — why a B-tree on that column changes the plan, or what the planner was doing before. Expect a follow-up you currently can't answer.
On idempotency you hedged — "I think we also check the file hash… I'd have to look." For a payments system this is a core correctness property, and uncertainty here is disproportionately costly.
Your scaling answer stayed at the level of intent ("batch it", "maybe a join") without naming the trade-off — memory footprint, transaction size, or lock duration on the ledger table.
Contradiction log
The nightly job was described as "just over one" hour at 13:40, then as roughly two and a half hours at 37:52. Your clarification was correct — the first figure covered only the matching step — but the original answer would have left an interviewer with the wrong number.
Your 2-week prep plan for this job
Week 1 — Read the EXPLAIN ANALYZE output for your own reconciliation query. Be able to say, out loud, what the planner did before and after the index, and why a B-tree suits an equality lookup on a high-cardinality column.
Week 1 — Open the ingest code and confirm exactly how file-level deduplication works. Write the two-sentence version: what makes a re-run safe, and what would happen if the same file arrived twice.
Week 2 — Rehearse the 5M-per-night redesign with numbers attached: rows per batch, memory per batch, and the lock/transaction implications of a set-based update on the ledger.
Week 2 — This JD lists queue-based processing, which never came up. Prepare one story about retries, ordering, or at-least-once delivery from your Celery work before the real interview.
Get this for the job you're actually interviewing for.
Paste the posting, upload your CV, take the interview.
Start practicing