Day 70: System Design Mock Practice
Run a full, timed, unaided system design mock end to end, applying Days 66-69's framework under realistic time pressure.
Study
Concepts
Why a full timed rehearsal matters more than more reading
Knowing the framework (Day 66) and the individual trade-off analyses (Days 67-69) is necessary but not sufficient — the skill that actually gets tested in an interview is EXECUTING that framework fluently under a ticking clock while someone is watching and probing your reasoning in real time, which is a different skill from understanding the material calmly while reading. A full 45-minute timed mock, done solo (narrating out loud to yourself or into a recording) or with a partner, is the only way to build that fluency before it counts.
Pick ONE of these prompts and treat it exactly like a real interview: "Design a URL shortener's frontend admin dashboard", "Design the frontend for a ride-sharing app's live map view", or "Design a notification center supporting web push, in-app, and email preferences" — deliberately choose something NOT already covered verbatim in Week 10, so you are applying the framework fresh rather than reciting a memorized answer.
Self-review checklist after the mock
Immediately after, grade yourself honestly against a checklist: Did you clarify requirements before architecting? Did you state functional vs non-functional requirements explicitly? Did you narrate reasoning throughout, not just produce a diagram silently? Did you name at least one rejected alternative and why? Did you address scale/performance/offline/security where relevant, even briefly? Did you leave time for a wrap-up mentioning what you'd monitor post-launch?
Write down the ONE weakest phase from this run (most people's first mock reveals a specific recurring gap — often skipping clarification or running out of time before the trade-offs phase) and design your NEXT mock specifically to drill that phase, rather than repeating the same generic practice.
See It
Visualizations
Visualization
The mock practice loop
narrate out loud the whole time
Build It
Code Examples
Self-review scorecard — fill this in immediately after the mock
Prompt used: ________________________________
Total time taken: _____ / 45 min
[ ] Clarified requirements BEFORE architecting (target: within first 5 min)
[ ] Explicitly separated functional vs non-functional requirements
[ ] Sketched a clear high-level architecture before going deep anywhere
[ ] Narrated reasoning continuously, not just silent diagramming
[ ] Went deep on at least one area with real technical specifics (not hand-waving)
[ ] Named at least one rejected alternative and stated why
[ ] Addressed scale/performance/offline/security if relevant to the prompt
[ ] Left time for a wrap-up + "what I'd monitor post-launch"
Weakest phase this run: ________________________________
Specific fix for next mock: ________________________________Remember
Key Takeaways
- Understanding the framework and executing it fluently under time pressure are different skills — only repeated timed mocks build the second.
- Practice on prompts NOT already covered verbatim in your study material, so you are applying judgment, not reciting memorized answers.
- Self-review immediately after each mock against a concrete checklist, not a vague "that went okay" feeling.
- Identify the ONE weakest phase per mock and design the next mock to specifically drill it — targeted practice beats repeating generic practice.
- Narrating reasoning out loud during solo practice is not optional — it is the specific skill (not just knowledge) the real interview tests.
Do It
Practice
- 1Run one full 45-minute timed mock today on an unfamiliar prompt, recording yourself narrating out loud.
- 2Fill out the self-review scorecard immediately after and identify your single weakest phase honestly.
- 3Schedule a second mock later this week on a different unfamiliar prompt, deliberately drilling the weak phase identified above.