I've been reading a lot of interview writeups lately, and there's a mismatch in them that almost nobody names directly.

Here's a real Amazon SDE-2 loop from Hyderabad, posted last week:

  • Round 1 — DSA + Leadership Principles
  • Round 2 — Low-level design: design eKart
  • Round 3 — High-level design: design an event management system
  • Round 4 — Bar raiser: DSA + Leadership Principles

Two of the four technical rounds were design.

Now think about how most people actually allocate preparation time. Something like 70% DSA, 20% behavioural, 10% design — and that 10% is usually reading, not practising.

The loop is 50/50. The prep is 90/10. That gap is where a lot of otherwise strong engineers lose offers.

The pattern shows up in rejection data

Another engineer posted his full interview history — nine outcomes, publicly, including the failures. Rare and genuinely useful.

  • Google — rejected at screening
  • Adobe — rejected at screening
  • Uber — rejected at onsite
  • Kotak — rejected at final round
  • Syfe — rejected at final round
  • SingleInterface — rejected at final round

The two screening rejections are a DSA signal. Fine — that's legible, you grind more problems.

But the other four happened at stages he had already cleared DSA to reach. Four consecutive late-round losses at SDE-2 and senior level is a pattern, and it is almost never an algorithms pattern. At that level the late rounds are design and depth of experience.

He concluded he needed more LeetCode. I think the data says something else.

Why reading doesn't transfer

System design is not a body of knowledge. It's a performance.

Almost everyone reading this can explain what a load balancer does, when to reach for a cache, roughly why you'd pick Kafka over a plain queue. That knowledge is widely available and most candidates have it.

Far fewer can take a deliberately ambiguous one-line prompt and produce a defensible architecture, out loud, in forty minutes, while someone interrupts to ask why.

Those two things feel similar while you're preparing. They are not the same skill, and only the second one gets tested.

There's also no feedback loop. With a coding problem you submit and you know. You finish a design answer and you have genuinely no idea whether it was any good — which means you can practise badly for months without noticing.

The phases, and what each one is actually probing

Most strong interviewers walk roughly the same path. Knowing the path matters less than knowing what each step is testing.

1. Requirements

Looks like: clarifying functional and non-functional scope.

Testing: whether you narrow an ambiguous problem before building. Candidates who start drawing immediately fail here silently.

Get a number out of the interviewer. "Is this read-heavy or write-heavy?" changes the entire design, and they usually won't volunteer it.

2. Estimation

Looks like: QPS, storage per day, bandwidth.

Testing: whether your architecture is proportionate to the problem.

This is the most commonly skipped phase, and skipping it is expensive. If you don't establish that you're at 100 QPS, you can't justify why you didn't shard. Estimation is what earns you the right to make simple choices.

You don't need precision. You need an order of magnitude and the confidence to say it out loud.

3. API design

Looks like: endpoints, request and response shapes.

Testing: whether you've thought concretely rather than in boxes.

Some companies weight this heavily. From an Atlassian candidate's writeup last week: "do not stay at the whiteboard diagram level — go deep into the API contract, the data model, and the specific components." The interviewer had to nudge them there, and that nudge cost minutes they needed later.

4. Architecture

Looks like: the diagram everyone thinks is the whole interview.

Testing: component responsibilities and data flow — not how many technologies you can name.

Adding Kafka to a design that doesn't need it is worse than leaving it out. Unjustified components read as pattern-matching.

5. Deep dive

Looks like: the interviewer picks one thing and pushes until you reach the edge of what you know.

Testing: depth, and honesty about where that edge is.

They will find your limit. That's the point of the round. "I don't know, here's how I'd find out" scores better than confident hand-waving, every time.

A worked example of the failure mode

A real one, from an Amazon event-booking design posted this week.

The candidate put seat holds in Redis with a TTL, and inventory in Postgres. Reasonable instinct — Redis is fast, TTLs are convenient.

But those two stores aren't transactional with each other. So what happens when Redis evicts or loses a hold while Postgres still shows the seat as unavailable?

You get a seat nobody can buy. Not sold, not available, just gone.

The robust version makes Postgres the source of truth, with hold_expires_at as a column and a sweeper reclaiming expired holds. Redis becomes a read cache. Slower, but it can't drift.

That's the shape of a deep-dive follow-up. You don't get there by reading about Redis. You get there by designing something, having someone ask "what happens if that fails?", and finding the gap yourself.

What to do tonight, free

Pick a design question. Set a 40 minute timer. Talk through it out loud. Record yourself.

Then watch it back.

It's genuinely unpleasant and it will teach you more than another month of reading. You'll hear yourself skip estimation. You'll notice you spent nineteen minutes on requirements. You'll catch the exact moment you said "we'll use Kafka here" without saying why.

Do that five times and you will be measurably better. The mechanism isn't mysterious — you're finally getting the feedback loop that design prep normally lacks.

Disclosure

I build Prepd, which drills exactly this: phased design practice across HLD, LLD and AI/ML systems, scored so the specific gaps get named. So I clearly have a stake in people taking design seriously, and you should weigh this post accordingly.

The free drills run without an account if you want to see the format.

But the timer-and-recording exercise above costs nothing and is most of the benefit. If you take one thing from this, take that one.

If you've interviewed at SDE-2 or above recently — what was the actual split of your loop? The gap between what people prepare for and what gets asked seems much wider than the standard advice suggests, and I'd like more data points.