Everything, and where you are in it
What is solid, what needs review and, more usefully, what you have not touched yet.
Track A — Fundamentals
Three tiers. Tier 1 is used by everything; Tier 2 is what senior interviews probe; Tier 3 is the specific answers that keep coming up.
Tier 1 — the basics
0/15 solidTier 2 — distributed
0/12 solidTier 3 — common patterns
0/17 solidTrack B — Problem shapes
Covering a new shape teaches you more than a second problem inside one you already know.
Read-heavy / caching
untouchedFew people write. Many read, and they read the same few things.
Write-heavy / fan-out
untouchedOne action by one person creates work for thousands of other people.
Matching under time pressure
untouchedTwo sides need to find each other, and one of them is a human who is waiting.
Contested inventory
untouchedA fixed number of things and more people who want them than there are things.
Big files
untouchedThe payload is far bigger than the metadata, and it should not go through your servers at all.
Live push
untouchedThe server has to speak first, to a lot of people, at the same time.
Search and ranking
untouchedThe user gives you a fragment and expects the right answer ranked first.
Limits and abuse
untouchedDeciding whether to say no, cheaply, on every request.
Location
untouchedTwo dimensions pretending to be one, plus a very high write rate from things that move.
Data pipelines
untouchedEnormous volume in, aggregates out, and nobody is waiting for any single event.
Crawling and ingestion
untouchedThe work is unbounded, the sources are hostile or fragile, and you are a guest on someone else's machine.
Sync and offline
untouchedThe same data lives on several devices, all of which can be edited while disconnected.
Building the storage itself
untouchedYou are not using a database. You are being asked to design one.
Money and correctness
untouchedBeing fast is worthless if the number is wrong, and every mistake is somebody's actual money.
Track C — Interviewers
Six styles of interviewer. Each weights the same rubric differently, so the same design can be judged differently.
What the bar actually is
The same answer scores differently depending on the level. It is easy to practise to one bar and be measured against another, so know which column applies to you.
- Follows a clear structure instead of freezing or drawing immediately.
- Asks a couple of questions that change the design.
- Does the arithmetic and reaches a sensible high-level design.
- Knows what a cache, a queue and a load balancer are for.
- Draws boxes before establishing any requirement.
- Cannot estimate, or estimates and then ignores the answer.
- Silent for long stretches.
The bar is a coherent, justified design. Depth on any one component is a bonus, not a requirement.
- Names the cost of every decision without being asked.
- Goes deep on the two components the numbers said were hard.
- Handles failure branches, not just the happy path.
- Holds up under follow-ups: defends, or concedes and adapts, without bluffing.
- Knows where their own design breaks and says so first.
- A correct design with no tradeoffs named out loud.
- Only ever the happy path, with no answer for a dead dependency or a hot key.
- Folds instantly when challenged, or refuses to move when clearly wrong.
This is where many interviews are decided, usually in the follow-ups rather than the diagram.
- Questions the requirement itself, and proposes a simpler product where one exists.
- Talks about cost, operations, migration and team boundaries, not just architecture.
- Has a real position on build versus buy, with reasoning.
- Explains how the system evolves: what you build now, and what you defer until a number changes.
- Drives the conversation rather than answering it.
- Technically excellent and never mentions what it costs to run or to staff.
- Designs the end state with no path from where the company is today.
- Waits to be asked.
The design is assumed. What is being assessed is judgement, and whether you would make good decisions when nobody is watching.