Community

How do you actually practice system design when you've never built anything at scale? — CareerVerse

backendinterview-prepsystem-design

How do you actually practice system design when you've never built anything at scale?

Anonymous09 Jul 2026

Backend dev, ~2 YOE at a small company. Our whole product runs on one Postgres box and a couple of app servers, so I've literally never touched sharding, real caching layers, or message queues in prod. Now I'm prepping for senior-ish interviews and every HLD question assumes an intuition I just don't have.

How did you build the mental model? Reading blogs helps for a day then I forget it. Did drawing out designs over and over help more, or mocks, or actually building a side project with the "fancy" infra?

5 replies

TopNew

Anonymous14 Jul 2026
You don't need real scale — read a few write-ups (the classic 'design Twitter / a URL shortener' ones), then force yourself to defend your choices out loud. The interview is about tradeoff reasoning, not whether you've personally run something at a million QPS. That said, building even one small end-to-end thing helps you talk concretely about caches, queues and DBs instead of reciting buzzwords.
0
Anonymous12 Jul 2026
What helped me: take an app you use every day and redesign it out loud — 'how would I build Twitter's feed?' You don't need real scale, you need reps at the reasoning (tradeoffs, bottlenecks, what breaks at 10x). Reading real companies' engineering blogs filled a lot of the gaps.
0
Anonymous11 Jul 2026
You don't need to have built it at scale, you need to reason about the tradeoffs out loud. Reading engineering blogs and then trying to redraw their architecture from memory helped me more than any course. And it's fine to say 'I haven't operated this at scale, but here's how I'd approach it' — interviewers respect that over fake confidence.
0
Anonymous10 Jul 2026
What helped me without real scale experience: take an app you use every day and try to redraw it from the outside in — what breaks first at 10x traffic, where's the read/write split, what would you cache and why. You don't need to have built it, you need to reason about where it fails. Reading a couple of real engineering blogs (not just courses) made the tradeoffs concrete instead of abstract buzzwords.
0
Anonymous09 Jul 2026
Same boat until recently. What helped more than blogs: pick one system a week, draw it end to end out loud, then deliberately break your own design — "okay this DB is now the bottleneck, what do I add?" That forces you to actually reason about caching/queues instead of just memorizing that they exist. Side projects help, but honestly the repeated whiteboarding did more per hour for me.
0

Join to reply