How to Pass System Design Interviews Without Scale Experience

A system design anxiety I hear constantly: "The job posting wants distributed systems experience, my current company runs on one Postgres box, am I doomed?"

Realistically, no, with one honest caveat. For most loops (up through a lot of senior ones), the interview is testing whether you can reason about scale: tradeoffs, bottlenecks, structured thinking under time pressure. Speaking as someone who has run these rounds: we know most candidates haven't personally sharded a database serving a billion users, and what we're actually probing is whether you'd make sane decisions when the time comes. The caveat is staff+ loops, which really do dig into operational scar tissue, and I won't pretend a blog post substitutes for that. But if you're the "one Postgres box" person, don't be too hard on yourself, almost nobody walks in with firsthand experience at the scale these questions describe (the questions are written past everyone's lived experience on purpose).

Where I'm speaking from, since I think it matters here: I've run a lot of interview loops from the interviewer side, system design rounds included, and I've sat in plenty of debriefs where these decisions got made. Practices do vary a lot company to company, though.

The structure that carries you (worth memorizing)

1. Requirements (3-5 min): what it actually does (functional), and the constraints (how many users, mostly reads or mostly writes, latency needs, consistency needs). In the loops I've run, the clarifying questions you ask here count as real signal in their own right, and diving straight into boxes and arrows without asking anything is one of the more common downlevel signals I saw.
2. Estimates (2-3 min): back of the envelope QPS and storage. Being off by 2x is fine, the point is showing you can think in orders of magnitude at all.
3. High level design (10 min): boxes and arrows. Client, load balancer, services, storage. Keep it boring here, because a design you fully understand will hold up under probing far better than something clever you half remember from a blog post. Clever architectures in interviews have real Jurassic Park energy: so preoccupied with whether you could, you didn't stop to think if you should.
4. Deep dive (15 min): the interviewer will steer you ("how does feed generation work?"). Follow the steer, that's them telling you what they want to evaluate, and fighting it to get back to a rehearsed script usually reads badly.
5. Tradeoffs and failure modes (5 min): what breaks first as load grows, and what you'd change. In the debriefs I've sat in, this last part carried a lot of weight in senior hire decisions.

How to compensate for missing scale experience

• Reason from first principles, out loud. Something like "I haven't run this at scale, but reads are usually the easy part to scale with replicas and caching, while the write path on a single primary is the bottleneck that's genuinely hard to fix, so that's where I'd focus" is a strong answer. And please don't bluff war stories you don't have. Bluffed depth is a "pay no attention to the man behind the curtain" move, and in the loops I've run the curtain got pulled back by the second follow-up question, every single time (design rounds are where that happens fastest, since depth is the entire point of the round).
• Steal real architectures and cite your sources. Engineering blogs (the classics on how big companies built their feeds, queues, and storage layers) give you legitimate secondhand knowledge. "I read how [company] approached this, and they chose X because Y" is completely fair game.
• Go deep on roughly 8 building blocks instead of shallow on 30: load balancing, caching (and invalidation), SQL vs NoSQL tradeoffs, sharding and partitioning, replication, message queues, CDNs, and rate limiting. I do a fair bit of woodworking, and this is the same lesson as joinery: you get genuinely good at a handful of joints and it turns out most furniture is those same few joints arranged differently. Design prompts work the same way, the majority are remixes of the core blocks, and the rest usually add one specialty piece on top (geospatial indexing for ride sharing, inverted indexes for search, websocket fanout for chat) while the core blocks still do most of the work.
• Anchor to what you HAVE done. You've made tradeoff decisions at your scale, and "at my company we chose X over Y because Z" exercises the exact reasoning muscle at smaller numbers, so say it explicitly instead of apologizing for your company's size.

The failure mode that actually sinks people

From the debriefs I've sat in, it's rarely missing knowledge. It's structure collapse: rambling, jumping between layers, designing for 15 minutes without asking a single question about requirements, or long unexplained silences. To be clear on that last one, a stated "give me 30 seconds to think" is completely fine; narrating the pause is what matters, and needing a beat to process is not a flaw. This is why reading Designing Data-Intensive Applications cover to cover doesn't fix system design interviews on its own, while a handful of full timed reps, done out loud, moves the needle a lot more. Whiteboard with a friend or coworker (free, and honestly covers most of the need), do peer mocks on Pramp (now hosted on Exponent; the free tier gives you 5 credits a month), book a human mock on interviewing.io (roughly $180-340 a session), or run an AI mock. In my experience the medium matters a lot less than actually doing the reps.

If you want structured, on-demand reps for system design without scheduling around anyone, that's part of what we build at Preppable. But a whiteboard, a timer, and a willing coworker cover most of the need for free, so the real point stands: do the full reps out loud, however you get them.