System design is the round people most often fail, and it is also the round that is close to impossible to practice alone. With DSA you at least get a green checkmark telling you that you were right. System design has no checkmark. You draw some boxes, you feel reasonably good about them, and you have no idea whether an interviewer would have shredded you in minute nine.
I have been on both sides of this round, and the gap between people who practice alone and people who practice out loud is bigger here than anywhere else in the loop. Here is what actually works when you do not have a partner, and what to do about the part that genuinely needs one.
Why solo system design practice quietly fails
Reading system design content feels productive. You finish an article about how Instagram handles the feed fanout, you understand it, and you file it away as knowledge. Then in the interview someone says "design a notification service" and you freeze, because understanding an explanation and generating one under time pressure are different skills that share almost nothing.
The specific things that break in a real round:
You do not state assumptions, because alone in your head the assumptions were obvious. The interviewer now thinks you did not consider them.
You go straight to the fun part. Most people jump to the database schema or the sharding strategy, because that is the part they read about. The interviewer wanted requirements first, and quietly marked you down before you drew a single box.
You cannot defend a choice. It is easy to write "use Kafka" on a diagram. It is very different to answer "why not just poll the database every five seconds" without saying "because Kafka is better."
You have no sense of pacing. Forty five minutes disappears far faster than people expect. Alone, you never practice the triage of what to skip.
What you can genuinely do alone
Narrate out loud, to an empty room. This feels ridiculous and it is the single highest leverage thing on this list. Set a timer for forty five minutes, pick a prompt, and talk through the whole thing as if someone is listening. If you cannot fill forty five minutes talking, you have found the gap.
Record yourself and watch it back. Painful, effective. You will catch the rambling, the long silences, and the moments you asserted something with no justification. You will catch things a friend would be too polite to mention.
Write the requirements section before touching the design. Functional requirements, non functional requirements, scale estimates. Force yourself to spend the first ten minutes there. Most people's instinct is to rush this, and in an interview it is where a lot of the signal lives.
Interrogate your own diagram. After you finish, go back through every component and ask why it exists, what happens when it dies, and what it costs. If you cannot answer, that is exactly where the interviewer will push.
Pick prompts with real constraints. "Design Twitter" is too vague to be useful practice. "Design Twitter's timeline for 300 million daily users where a celebrity has 100 million followers" forces the actual tradeoff, which is the fanout problem.
The part that genuinely needs another person
Everything above makes you better at producing a design. None of it prepares you for the thing that actually decides the round, which is someone pushing back on you in real time.
A real interviewer interrupts. They ask why you picked that datastore. They say "your service just got ten times the traffic, what breaks first." They follow the thread you were hoping they would not notice. You cannot simulate that alone, because you cannot surprise yourself, and you will never ask yourself the question you do not want to answer.
Options, honestly assessed:
A friend who is also interviewing. Free and underrated, with one real problem: friends are bad at being blunt. Fix it by asking for a hire or no hire verdict and three specific failures, rather than "how did I do."
Paid platforms. interviewing.io and similar will put you in front of experienced engineers. Genuinely good, genuinely expensive if you want volume.
Peer platforms. You take turns, so you interview someone else and then get interviewed. The underrated part is that interviewing other people is itself excellent practice, because watching someone else flail teaches you what flailing looks like from the other chair.
I ended up building one of these, Practick, because the free peer option kept shrinking and I wanted it to still exist. It matches you with another engineer automatically and includes an interviewer guide on each question, since the usual failure mode of peer practice is that the person interviewing does not know what to push on. That one is mine, so discount it accordingly, but the general category matters more than which one you pick.
A practice loop that works
If I had to compress this into a weekly routine:
Two solo sessions, timed and narrated out loud, recorded. Focus on requirements and pacing.
One session where you are the interviewer for someone else. You will learn more than you expect.
One session where you are the candidate and someone pushes back.
Then, importantly, write down the specific question that broke you each time. After a month you will have a list, and that list is your actual study plan, not whatever generic topic list you started with.
The uncomfortable summary
Most people preparing for system design are optimizing the part that feels like studying, because it is comfortable and measurable. The round is decided by the part that feels uncomfortable, which is talking through a design while someone questions it.
You can do a surprising amount alone if you are willing to talk to an empty room and watch the recording. But at some point you need someone on the other side who is willing to ask the question you have been avoiding.
Top comments (0)