Design Patterns (GoF and modern) Module 11 – Choosing patterns in design reviews and LLD rounds
Timed LLD mock rounds focused on patterns
Run a 45-minute low-level design (LLD) self-mock: clarify, list what varies, code the core, absorb two change requests, and score it with a rubric.
What you will learn
- Run a timed self-mock that clarifies requirements, designs classes, codes the core and answers change requests
- Assess your own answer with a rubric that values justified pattern choices and rejections
- Compare your design with a sample answer whose tests and change requests are recorded
Before you start
What you’ll learn · Before you start
What you will learn
- Run a timed self-mock that clarifies requirements, designs classes, codes the core and answers change requests
- Assess your own answer with a rubric that values justified pattern choices and rejections
- Compare your design with a sample answer whose tests and change requests are recorded
Before you start
On this page
A timed mock round focused on patterns is a 45-minute rehearsal of a low-level design interview, run on your own: you clarify a prompt, list what varies in it, sketch the classes, code the core against tests, and then answer two change requests that put your pattern choices under strain. Afterwards you score the answer with a rubric that rewards patterns justified by a variation, and alternatives rejected for a reason, more than patterns named. The format matters because the change requests, not the class diagram, show whether a design was right: a good choice makes the change small.
The 45-minute format
The 45 minutes of a self-mock, and what each phase leaves behind
Text description of the diagram
Five boxes, one after the other.
Minutes 0 to 5, clarify: questions, assumptions and what is out of scope. Minutes 5 to 10, what varies: a list in which each item has its pattern, or none. Minutes 10 to 15, sketch: the classes and their public methods. Minutes 15 to 35, code the core, running the tests as you go. Minutes 35 to 45, change requests: say what changes, then change it.
Each phase leaves something behind for the next one:
- Minutes 0 to 5, clarify: the questions asked, the assumptions written down, and what is out of scope.
- Minutes 5 to 10, what varies: a short list, each item with its pattern, or with none.
- Minutes 10 to 15, sketch: the classes and their public methods, no more.
- Minutes 15 to 35, code the core: the smallest working core, with the tests run as you go.
- Minutes 35 to 45, change requests: for each one, what changes, said first and then changed.
The rubric is MySmartCoPilot’s own and has five criteria, each scored from 0 to 4:
- Requirements and scope (weight 1): the questions you asked, and what you wrote down as assumed or out of scope.
- Pattern fit and rejections (weight 2): each pattern tied to a variation, with the alternative you rejected.
- Extensibility under changes (weight 2): how little of the code each change request had to touch.
- Correctness against tests (weight 2): how many of the provided tests pass.
- Communication of trade-offs (weight 1): decisions said aloud, with their costs, while you made them.
The weights favour justified choices over both pattern-collecting and plain code that passes. Here they are applied to three made-up answers to one prompt:
"""The self-mock rubric: five criteria scored 0 to 4, weighted, applied to three made-up answers to the same prompt."""
CRITERIA = [ # (criterion, weight)
("requirements and scope", 1),
("pattern fit and rejections", 2),
("extensibility under changes", 2),
("correctness against tests", 2),
("communication of trade-offs", 1),
]
ANSWERS = { # three illustrative answers, scored 0-4 on each criterion, in the order above
"collector": [2, 1, 2, 2, 2], # six patterns named, three of them without a reason; 4 of 6 tests pass
"plain": [3, 2, 1, 4, 2], # no pattern, every test passes, the change request edits one large class
"justified": [3, 4, 4, 4, 3], # two patterns, each with its rejected alternative; both change requests absorbed
}
best = sum(4 * weight for _, weight in CRITERIA)
print(f"{'criterion (weight)':<34}" + "".join(f"{name:>11}" for name in ANSWERS))
for i, (criterion, weight) in enumerate(CRITERIA):
print(f"{criterion + f' ({weight})':<34}" + "".join(f"{scores[i]:>11}" for scores in ANSWERS.values()))
totals = [sum(s * w for s, (_, w) in zip(scores, CRITERIA)) for scores in ANSWERS.values()]
print(f"{f'weighted total, out of {best}':<34}" + "".join(f"{t:>11}" for t in totals)) Output
criterion (weight) collector plain justified requirements and scope (1) 2 3 3 pattern fit and rejections (2) 1 2 4 extensibility under changes (2) 2 1 4 correctness against tests (2) 2 4 4 communication of trade-offs (1) 2 2 3 weighted total, out of 32 14 19 30
Recorded with Python 3.14.8 on macOS 26 arm64. To run it yourself: mise exec python@3.14.8 -- python3 score.py
Runs on this device, in your browser. The first run downloads Python (about 13.5 MB), which is kept for the next runs.
Your run, in this browser
The collector named six patterns and scored 14 of 32; the plain answer passed every test and scored 19, but lost points when its change request edited one large class; the justified answer scored 30. This lesson’s sample prompt is the core of a drawing editor: shapes on a canvas that can be added, moved, recoloured and deleted, with undo and redo for every action and no user interface.
The sample mock, minute by minute Pro: opens with a Pro, Premium or Ultimate pass
In this part:
- Minutes 0 to 5: the questions, and the answers assumed
- Minutes 5 to 10: what varies, and what each item gets
- Minutes 10 to 15: the class sketch
- Minutes 15 to 35: the core, tested
- Minutes 35 to 45: two change requests, measured
- Scoring the sample answer
- Mock 2: the core of a reminder scheduler
- Code the scheduler and pass both change requests
- Scoring mock 2
- Where self-mocks lose points
- Check yourself
- Interview questions
- Twenty-five minutes into a 45-minute low-level design round, you have a class diagram and no code. What do you cut, and what do you tell the interviewer?
- Design the core of a drawing editor with undo and redo. Which patterns do you use, and how much memory does the undo history need after 10,000 edits on a drawing of 2,000 shapes?
- Your drawing editor's core is done when the interviewer adds that shapes can be grouped and ungrouped, and undo must work on groups. How does your design change, and how do you show that it absorbed the change?
- Key takeaways
1 diagram · 2 runnable examples (Python, editor_v1.py, editor_v2.py, editor_v3.py) · 1 exercise with sample tests · 3 interview answers · about 21 minutes
Opening this part with your pass…
This part opens with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so this part can’t be opened at the moment. The free part above stands on its own. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
References
- Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley (Pearson))
- Unified Modeling Language (UML) specification (Object Management Group)
- Python 3.14 documentation: collections.deque (Python Software Foundation)
- Python 3.14 documentation: ast.get_source_segment (Python Software Foundation)
- Python 3.14 documentation: sorting is stable (Sorting Techniques) (Python Software Foundation)
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress