It shows up in two places:

• AI-assisted interview rounds. You get a codebase and an assistant. Accepting its first suggestion without checking is one of the most common ways to fail, because the round is designed to see whether you review its output.
• Everyday work. Design reviews and code reviews increasingly start from an AI draft. The engineer who can say "this won't hold under load, here's why" is the one whose judgement gets trusted.

This guide gives you a checklist for both, the words to use when you push back, and two worked examples.

Why AI output needs a reviewer

Assistants are good at producing something that looks right. They are weaker at the parts that need context they don't have:

• Your real constraints. Traffic, budget, team size and existing systems are rarely in the prompt, so the answer is generic.
• Edge cases. Empty inputs, boundaries, concurrent calls and failures are where generated code most often breaks.
• Trade-offs. An assistant will happily recommend a queue, a cache and five microservices without saying what each one costs.
• Confidence. Wrong answers come in the same confident tone as right ones, including calls to library functions that don't exist.

None of this means "don't use AI". It means the human in the loop is doing the senior part of the job.

Checklist: reviewing AI-generated code

Run through these before you accept a suggestion:

1. Does it solve the stated problem? Re-read the task, then the code. Assistants often solve a nearby, easier problem.
2. Boundaries. What happens at 0, 1, the maximum, an empty list, a null, a duplicate? Off-by-one errors are the classic miss.
3. Concurrency. Is shared state read and written without a lock or atomic operation? Two requests at once is the test case it didn't consider.
4. Failure paths. What if the network call times out, the file is missing or the database rejects the write? Is the error swallowed?
5. Does every API exist? Check unfamiliar methods and parameters against the docs. Invented functions compile in the AI's head, not in yours.
6. Security. String-built SQL, unescaped user input, secrets in code, missing permission checks.
7. Tests. Run them. If the AI wrote the tests too, check they assert the right thing and would actually fail on the bug you're worried about.
8. Can you explain it? If you can't walk an interviewer or a teammate through it line by line, you haven't reviewed it.

Checklist: reviewing an AI-suggested system design

When an assistant proposes an architecture, ask:

1. Which requirement does each component serve? Any box you can't tie to a requirement is a cost with no benefit.
2. Where are the numbers? A design without rough traffic and storage estimates can't justify sharding, caching or a queue. Do a 2-minute estimate and see what survives.
3. What's the consistency story? Is it fine for this data to be stale for a few seconds (likes, feeds) or not (payments, inventory)? Generic designs rarely say.
4. What's the single point of failure? Load balancer, primary database, a single queue broker, one region.
5. What happens under the hot case? A celebrity post, a flash sale, a viral link. Averages hide hot keys.
6. What does it cost to run and operate? Five services and a streaming platform for a few hundred writes a second is a maintenance bill, not a scalability win.
7. What's the simplest version that works? Start there, then add complexity only where a number or a requirement forces it.

How to push back without sounding difficult

The goal is to be specific, not contrarian. Name the risk, give the reason, offer an alternative:

• "This works for the happy path. What happens if two requests update the same counter at once? I'd use an atomic increment here."
• "Before we add Kafka, let's check the numbers: about 50 writes a second fits in one database with room to spare. I'd start with a simple table and a background job."
• "This cache makes reads fast, but the price can be stale for up to an hour. For checkout I'd read from the database and cache only the product page."
• "I don't think retryWithBackoff exists in this client. Let me check the docs before we rely on it."

In an interview, saying this out loud is exactly the signal: you used the assistant, and you stayed in charge.

Worked example 1: a rate limiter the AI got almost right

You ask for a token bucket rate limiter. The assistant returns clean code that refills tokens on every request based on elapsed time. Review it with the checklist:

• Boundaries: it refills before checking the cap, so after a long idle period the bucket briefly holds more tokens than its capacity and allows a burst. Clamp after refilling.
• Concurrency: the read-modify-write of the token count isn't atomic, so two simultaneous requests can both take the last token. Use a lock, or an atomic operation in the shared store.
• Units: elapsed time is in milliseconds, the refill rate is per second. A factor of 1,000 hides in one line.

Three real bugs in code that looked finished. That's the review an interviewer wants to watch.

Worked example 2: an over-built design

Prompt: "Design the backend for a small team's internal polling app." The assistant proposes microservices for users, polls and votes, Kafka between them, Redis, and a NoSQL store.

Push back with numbers: a few hundred users, a few thousand votes a day, which is well under one write a second. One service and one relational database handle that easily, and a unique constraint on (poll, user) prevents double voting more reliably than any of the proposed parts. Keep the design simple and say what would make you add each component later (for example, a cache only if read latency becomes a problem).

How to practise

1. Build the scaling intuition. Know what each common step fixes and what it breaks: load balancer, read replicas, cache. That's what lets you spot an over-built or under-built design quickly.
2. Practise reviewing, not just writing. Take generated code and hunt for the bugs on purpose: boundaries, concurrency, units, failure paths.
3. Say your reasoning out loud. Pushing back is a communication skill as much as a technical one.

Practise it

• What each scaling step fixes and breaks: a free, animated learning path, so you can spot over-built and under-built designs.
• AI-Assisted Coding drills: AI-written code with planted bugs to find and fix, with written feedback.
• Free system design drill: Design a Like Button, with feedback on your trade-offs.

Originally published at prepd.tech. Disclosure: I'm building Prepd.

1. One server

Web server, application code and database on one machine. DNS points your domain at its IP. It's the right design for a launch: simple to deploy and simple to reason about.

What breaks: everything is a single point of failure, and the only way to grow is a bigger machine. When the database and the web server compete for the same CPU and memory, both get slower.

2. Add a load balancer and more app servers

Users now connect to a load balancer, which forwards each request to one of several identical app servers and skips any that fail health checks. You can grow by adding servers instead of buying a bigger one.

What it fixes: app-server failures and app-server capacity.

What it breaks: the load balancer is now a single point of failure, so in a real design you run more than one. Servers must be stateless, so sessions move out of memory. And the choice of algorithm matters: round robin ignores how busy each server is, so long requests can pile up on one box.

3. Split the database: one primary, read replicas

All writes go to the primary database. Copies of it, the replicas, serve reads. Most products read far more than they write, so this multiplies the read capacity.

What it fixes: read throughput.

What it breaks: replication is usually asynchronous, so a replica can be slightly behind. A user who updates their profile and immediately reloads it may see the old value. The common fix is to read your own recent writes from the primary. Replicas also do nothing for a write-heavy workload; that needs partitioning.

4. Add a cache

Expensive results, such as a product page or a feed, are stored in memory and served from there instead of hitting the database every time.

What it fixes: latency and database load for repeated reads.

What it breaks: you now have a second copy of the data that can be stale, empty after a restart, or overwhelmed when a popular key expires and every request misses at once. You need an invalidation plan, sensible expiry times and protection against stampedes.

How to use this in an interview

Don't draw step 4 first. Say what the current design can't handle, make one change, and name the new problem it introduces before moving on. That sequence, problem then change then trade-off, is what separates a senior answer from a list of components.

See it step by step

I put this path into an animated learning section on Prepd: each concept is a diagram you step through, showing where requests go as you add the load balancer, the replicas and the cache, with key points and interview questions for each. This first topic is free to read, no sign-up needed.

Disclosure: I'm building Prepd.

I spent three months preparing. Read Alex Xu's book cover to cover. Watched every Gaurav Sen video. Studied consistent hashing, CAP theorem, database sharding, cache invalidation strategies, load balancing — all of it.

I walked into my first FAANG system design round feeling ready.

I failed it.

Then I failed the second one.

Not because I didn't know the material. I knew it well. The problem was something nobody had warned me about — and something almost no prep resource is actually built to fix.

The gap nobody talks about

There's a massive difference between knowing system design concepts and performing them in a real interview.

In an actual system design interview, you don't just recite what you know. You have to:

• Explain your reasoning out loud while someone watches you think

• Make architectural decisions under time pressure

• Defend your choices when the interviewer pushes back

• Respond to follow-up questions you didn't prepare for — in real time

That last one is what kills most candidates.

You can explain what eventual consistency is. But can you answer this on the spot:

"You chose eventual consistency for your social feed. A user just posted a photo and refreshed their feed — they can't see it. Your PM is escalating. How do you handle this without sacrificing availability?"

Or this:

"Your Redis cache is handling 800k writes per second. You're seeing hot key contention on trending content. What's your mitigation strategy and what are the tradeoffs?"

These aren't trick questions. They're the normal follow-ups that every senior interviewer asks. And if you've only ever studied concepts passively — reading, watching, highlighting — your brain freezes when they come.

I know because mine did. Twice.

Why passive prep doesn't work for system design

Think about how you actually prepared.

You read a book. You watched a video. Maybe you drew some architecture diagrams on paper. You felt like you understood the material — because you did understand it, in a passive sense.

But understanding something while reading about it is completely different from explaining it under pressure while someone probes every decision you make.

This is why athletes don't just watch game footage. Musicians don't just listen to recordings. You have to perform the skill repeatedly, under conditions that mimic the real thing, to build the muscle memory that holds up when the pressure is on.

System design interviews are no different. And yet almost every prep resource treats it like a knowledge problem instead of a performance problem.

What actually works: reps under simulated pressure

After my second failed loop, I stopped studying and started practicing differently.

The only thing that moved the needle was doing actual interview simulations — getting a real scenario, articulating my approach out loud, and then having someone push back with follow-up questions until I could defend every decision.

The problem: real mock interviews with experienced engineers cost ₹5,000–₹12,000 per session on platforms like Interviewing.io. And your friends can only do so many mock interviews before they run out of patience.

So I built something to fill this gap.

What I built: Prepd

Prepd is an AI-powered interview simulator built specifically for system design practice.

Here's how it works:

1. You pick a scenario — URL shortener, rate limiter, distributed cache, real-time chat, LLM chatbot at scale, and more

2. You write out your approach — components, databases, scaling strategy, tradeoffs

3. The AI interviewer follows up — with real probing questions based on what you said

4. You respond and defend your decisions

5. You get a score (0–100) and detailed feedback on your strengths and gaps

The follow-up questions are the entire point. Anyone can give you a scenario. Prepd gives you the conversation — the back-and-forth that actually trains your brain to perform under pressure, not just recall information.

Three tracks:

→ System Design (HLD) — distributed systems, caching strategies, database sharding, load balancing, CAP theorem, scalability patterns

→ Low Level Design (LLD) — object-oriented design, SOLID principles, design patterns (Singleton, Strategy, Observer), concurrency, entity modeling

→ AI Systems Design — RAG architectures, LLM deployment, vector databases, real-time ML inference, model serving — this is now a real interview category at senior roles and almost nothing else covers it

Two modes:

→ Learning mode (15–30 min) — low pressure, daily practice, ideal for building fundamentals

→ Interview simulation (45–60 min) — timed, full pressure, mimics the real thing

There's also a BYOQ feature (Bring Your Own Question) — paste any question from your actual interviews or Glassdoor and practice it with a full AI interviewer.

What a session actually looks like

Here's a real example from a session on the platform:

Scenario: Your API is receiving 2 million read requests per second. Database latency is 50ms. Design an architecture to handle this load.

You explain: Multi-tier caching with Redis, CDN for static assets, read replicas for database scaling, connection pooling...

AI follow-up: "Good. Now your Redis cluster is showing uneven load distribution — some nodes are getting 10x the traffic of others. What's causing this and how do you fix it?"

You respond: Hot key problem — certain keys (trending content, popular users) are getting disproportionate traffic. Solutions: local in-memory caching at the application layer, key sharding by adding a random suffix, consistent hashing...

AI follow-up: "If you add a random suffix to hot keys, how do you handle cache invalidation when that content is updated?"

This is the conversation that teaches you. Not the initial answer — the follow-ups.

Who this is built for

• Software engineers with 2–6 years experience preparing for senior roles

• Anyone interviewing at FAANG or FAANG-adjacent companies

• Engineers who've failed system design rounds despite "knowing" the material

• ML engineers preparing for AI systems design rounds

• Anyone who wants to go from passive knowledge to active performance

Try it

prepd.tech — free to explore, $18/mo for full access.

If you're preparing for a system design interview in the next 30–90 days, one session will show you exactly where your thinking breaks down. That's more valuable than another week of reading.

If this resonated — or if you've been through the same experience — drop a comment below. What's the hardest system design follow-up question you've ever faced in a real interview?