Practise low-level design
A practical guide to requirements, object design, working code, and review.
Low-level design (LLD) asks you to turn requirements into a clear, working design for a small system. Interview formats vary by company, so use this practice alongside the requirements for roles you are targeting. The week template shares four weekly hours between fundamentals and LLD.
What to practise
- One design a week, 45 minutes each, alternating sketch-only and code-the-core. The eight designs live on the designs page.
- Four timed machine-coding runs in the later project and practice weeks. Those live on the machine coding page.
- The rest of the block is retry time for designs that scored badly.
The two pages above are the work. This page is the standard you measure the work against.
The self-scoring rubric
Score every run against these five practical checks. They are a preparation rubric, not a universal company scorecard.
- Did you capture requirements and name edge cases before writing code?
- Are responsibilities separated, so that a change stays local?
- Does the core behavior run end to end?
- Are there tests, or a deterministic driver?
- Did you pick the highest-value behaviour first and skip speculative abstraction?
A design that fails self-score twice goes on the retry list for mock season.
A running program beats a perfect diagram
Nothing running means nothing to score. Get a skeleton that executes early, then improve it in place. The rubric rewards behaviour you can demonstrate, not structure you can describe.
LLD dos and don'ts
- Build a small working path before polishing optional details.
- Use names that make each type's responsibility clear.
- Bring the deterministic driver. A 20-line script that plays a scripted scenario beats "trust me", and the rubric rewards it.
- Score the run the same day, while you still remember what you skipped.