How to Practice System Design Interviews Alone (a Full Solo Routine)

Most system design prep advice, mine included, eventually lands on some version of "do full mocks before the loop that counts." It's correct advice, and it quietly assumes you have access to a practice partner who knows the format: a senior engineer friend with free evenings, a coworker you trust enough to be bad in front of, or a budget for professional mocks. Plenty of people preparing right now have none of those, and system design is exactly the discipline where that stings, because unlike coding (which scales down to one person and an autograder just fine), a design round is a 45 minute structured conversation. Having coached candidates through these rounds and run a lot of them from the interviewer side, I think solo practice gets you much further than its reputation suggests, provided you're honest about which parts of the conversation you can simulate and which you can't.

What the interviewer is actually doing in the room

The person across the table has roughly three jobs. They keep the structure honest (the clock, the skeleton of the round). They steer the deep dive toward whatever they want to evaluate. And they probe when you handwave. A timer and a checklist replace the first job completely. A recording and some disciplined self-review replace a surprising amount of the third, because your handwaves are audible on playback in a way they never are in the moment. The second job, real-time steering, is the hard one to fake alone, and I'll cover the options for it near the end. What I can tell you from the loops I've run is that candidates with full, timed, out-loud reps behind them were recognizable within the first few minutes, and it never mattered much which medium those reps came from.

The foundation: a recorded, timed prompt, out loud

Choose a standard prompt (rate limiter, URL shortener, news feed, chat), start a 35-45 minute timer, open any whiteboard (paper is fine, a free Excalidraw tab is fine), hit record on your phone, and run the entire round as if an interviewer were present. Readers of the 4-week prep plan will recognize this as the week 1 diagnostic; here it graduates into the recurring rep the rest of the routine builds on.

Asking clarifying questions to an empty room feels ridiculous, and you should do it anyway, immediately answering yourself with a stated assumption: "I'd want the read/write ratio. I'll assume heavily read-skewed, around 100:1, and design for that." The requirements phase exercises one specific muscle (surfacing a constraint and letting it drive the design), and that muscle works fine against an imaginary interviewer as long as the assumption is spoken rather than silently carried. Work the full skeleton from the no-scale-experience article: requirements, estimates, high level design, deep dive, then tradeoffs and failure modes. Stop when the timer stops, even mid-sentence, since time pressure is half of what you're rehearsing.

I do a fair bit of woodworking, and nobody cuts their first dovetails into the walnut board they saved up for. You cut practice joints into scrap, a dozen of them, and every gap in a scrap joint teaches you something about your saw angle while the mistake is still free. Recorded solo prompts are the scrap wood of design prep. No individual rep is precious, which is exactly the appeal: volume, with feedback, while the mistakes cost nothing.

Self-grade the recording against a rubric

Leave a gap of at least a few hours before playback, ideally a night, because grading immediately means grading what you intended to say rather than what the tape holds. Then work through four questions:

• Did the structure hold? Requirements before boxes, estimates before the high level, a genuine deep dive, tradeoffs at the end. Or did the round jump between layers, burn 25 minutes on the high-level drawing, and run out of clock before failure modes? In the debriefs I sat in, structure collapse ended more candidacies than missing knowledge did, and a recording exposes it completely.
• Did you ask requirements questions, and did the answers shape the design? Announcing an assumption and then designing as though it was never made is a common pattern, and far cheaper to catch on tape than in a real round.
• Did you state tradeoffs? Count the "because" sentences. "I'll use Postgres" is a decision, while "I'll use Postgres over a document store because the data is relational and the write volume doesn't justify the operational cost" is a graded answer, and in my experience the second shape is what survives into the written feedback.
• Was silence narrated? Locate the dead air and classify it: announced ("give me 30 seconds to sketch the write path") or unannounced vanishing. The mechanics from talking while coding apply fully here, and are arguably harder to execute, since design rounds contain more legitimate thinking pauses to manage.

The first playback is uncomfortable for nearly everyone (the filler-word count alone is humbling), so don't be too hard on yourself about rep one. The improvement between the first and fourth recorded rep tends to be some of the fastest in all of interview prep, partly because almost nobody has ever actually heard themselves do this before.

Whiteboard against engineering blogs, then diff your design

This is my favorite solo rep, because it manufactures what solo practice lacks most: an external answer key. Find a system with a strong public writeup (the classic engineering blog posts on feeds, chat fanout, rate limiters, queues, and URL shorteners; most large companies have published at least one). Before reading it, run your own full timed prompt on that same system. Afterward, read the writeup and diff the two designs the way you'd review a pull request.

Useful diff questions: which component did they include that you skipped entirely, and what constraint forced its existence? Where did they pick the opposite of your choice, and does their reasoning hold at interview scale or only at their production scale? And what did you get essentially right (worth logging for calibration and morale)? The gaps tend to match the exact places a strong interviewer would have steered you, so every diff doubles as a personalized study list. Citing these writeups during a real round is entirely fair game, as I argued in the no-scale article: attributed secondhand knowledge, delivered with the reasoning intact, reads as strength.

Rubber-duck the deep dive

The deep dive degrades most without an interviewer, because in a live round they aim it for you ("walk me through exactly what happens when a write comes in"). Practicing alone, you aim it yourself, and the rubber duck technique from debugging transfers surprisingly well. Pick one component from a design you've already drawn and explain it, to the duck or the empty chair or the dog, at the depth a skeptical senior engineer would demand: the complete request path, where the data persists, what happens when that node dies mid-write.

The payoff comes at the moments you catch yourself saying "and then it just gets handled." Each of those is precisely where a real interviewer would have pressed, and finding them solo costs you nothing. Keep a running list of your handwaves (everyone's first list is long, mine included), because a gap list fitted to your actual blind spots beats any generic syllabus.

The part solo reps genuinely can't cover

All of the above simulates structure and probing, and none of it responds to you in real time, pushes back on a decision, or drags you somewhere you didn't plan to go. That responsiveness is worth experiencing at least a few times before a real loop. The realistic menu: an engineer friend running a proper mock (free, and the mock interview with a friend kit exists precisely to make that session behave like a real round), peer mocks on Pramp (now hosted on Exponent, with 5 free credits a month), interviewing.io for professional human interviewers (roughly $180-340 a session), or AI mocks for on-demand practice against something that responds and probes. Which fits depends on access and budget far more than any inherent ranking, and the conclusion from the no-scale article applies unchanged: the medium matters a lot less than doing full, timed, out-loud reps at all.

A design round is a conversation, and the only way I know to get better at a conversation is to have it out loud, even when the other chair is empty. So protect the timer and the recording above everything else in this routine. If you reach the point where you want the responsive version (something that steers your deep dive and probes your handwaves on demand), that's exactly what we built Preppable's system design mocks to do. And if a phone recording, a rubric, and a stack of engineering blog posts is what you have, that combination honestly covers most of the distance, so start there tonight rather than waiting for a better setup.