This page needs a newer browser to run its tools. You can still read everything here.

Design Patterns (GoF and modern) Module 11

Choosing patterns in design reviews and LLD rounds interview questions

Interview questions on choosing patterns in design reviews and LLD rounds: warm-ups, then what each harder question tests and how a good answer starts.

10 questions: 2 warm-ups and 8 with model answers · Levels: Fresher to staff

Warm-up questions

Short questions with short answers, each answered in full.

Fresher to mid

How do you decide which design pattern to use for a requirement?

Answered in the lesson Choosing a pattern: a problem-first map
Fresher to mid

What is a characterization test, and why write one before refactoring?

A characterization test records what code does today, whatever anyone intended, and fails when that changes. You run the code on a set of inputs, bad ones included, and turn its current outputs and errors into the expected results. Before a refactoring it is the safety net: a refactoring must not change behaviour, and these tests show at once when a step did, while the step is still small enough to undo. They differ from tests written from a specification, which say what the code should do. If today's behaviour looks like a bug, keep the test as it is during the refactoring, and fix the bug afterwards as a separate change with its own test.
From the lesson Refactoring katas with characterization tests

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

Fresher to senior

A parking lot charges by the hour on weekdays, a flat fee at weekends, and an extra fee at spots with an electric-vehicle charger. Which patterns would you use for pricing, and which alternative would you reject?
What it tests

Mapping the variations in a requirement to patterns, combining rules without a class per combination, and naming what was rejected and why.

First step

List what varies and who decides it: the base rule depends on when the car is parked, the extra fee on the spot, and both apply to one ticket. Then compare a Strategy for the base rule plus a list of surcharges with one price function full of conditions.
Follow-ups
- The owner adds a festival surcharge on ten days a year.
- A stay starts on Friday evening and ends on Saturday. Which rule applies?
- How do you test the pricing without waiting for a weekend?
From the lesson Choosing a pattern: a problem-first map
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.
Opening the model answers with your pass…
Model answers open 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 the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
Choose a pass I have a 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).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

In a design review you proposed Observer for order-status notifications. A colleague says a direct call from the order service to the notification service is simpler. How do you decide who is right?
What it tests

Judging a pattern by the variation it protects, and weighing what Observer costs against a direct call.

First step

Count the dependents and how they change: one dependent that never changes favours the direct call; several, or dependents that other teams add, favour Observer. Then list what Observer would add: notification order, a failing subscriber and unsubscribing.
Follow-ups
- The notification call takes 800 ms. Does that change the answer?
- A subscriber raises an exception. What happens to the order?
- How would you move from the direct call to Observer later?
From the lesson Choosing a pattern: a problem-first map
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

A 600-line function switches on the order type in five places, and a new order type ships next week. How do you refactor it safely, and in what order?
What it tests

Planning a refactoring toward Strategy in safe steps, with characterization tests first, and sequencing it against a deadline.

First step

Pin today's behaviour first: run the function on orders of every type, invalid ones included, and record its outputs and errors as characterization tests. Only then add one class per type beside the old code.
Follow-ups
- The function writes to the database. How do you test it?
- You have three days, not a week. What do you skip?
- How do you know you are done?
From the lesson Refactoring katas with characterization tests
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
Senior to staff

You must refactor legacy code that has no tests and reads the current time and a database directly. How do you start?
What it tests

Getting legacy code under test safely: finding seams, writing characterization tests through them, and keeping the first changes small.

First step

Do not touch the logic yet. Find the seams: put the clock and the database behind small parameters or functions whose defaults keep today's behaviour, so tests can replace them. Then write characterization tests through those seams.
Follow-ups
- The first change that adds a seam is itself made without tests. How do you keep it safe?
- How many characterization cases are enough?
- The output contains timestamps and random ids. How do you compare runs?
From the lesson Refactoring katas with characterization tests
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
Mid to senior

How would you check automatically that a refactoring reached its goal, such as "no more switches on the order's status", and what can go wrong with such a check?
What it tests

Turning a design goal into a structural check, keeping it neither too strict nor too loose, and knowing what it cannot prove.

First step

Write the goal as a property a parser can see: no comparison of the status with a status name in the order's code. Then try the check on the legacy code, which must fail it, and on a design you know is right, which must pass.
Follow-ups
- A teammate passes the check by moving the switch into a helper. What now?
- Should such a check run in CI forever?
- How do you do this in a language without a parser module?
From the lesson Refactoring katas with characterization tests
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
Fresher to mid

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?
What it tests

Managing time in a design round, choosing the smallest core worth coding, and keeping the interviewer informed while cutting scope.

First step

Say it out loud first: the design is enough to start, and you will code the core now. Then pick the one flow the prompt and its tests care most about, such as adding a shape and undoing it, and code only the classes it needs.
Follow-ups
- Which parts of the diagram do you drop?
- The interviewer asks why you spent so long on design.
- You finish the core with five minutes left. What then?
From the lesson Timed LLD mock rounds focused on patterns
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
Mid to senior

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?
What it tests

Choosing between Command and Memento for undo with numbers, and keeping undo correct for deletes, redo and groups.

First step

Name the two ways to undo: store each action as a command that can reverse itself, or store a snapshot of the drawing after each action. Then estimate both for 10,000 edits on 2,000 shapes before you choose.
Follow-ups
- Some actions cannot be reversed exactly, such as a filter applied to an image. What then?
- The history must survive a restart. What do you store?
- Undo must work on groups of shapes.
From the lesson Timed LLD mock rounds focused on patterns
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
Senior to staff

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?
What it tests

Absorbing a change request with Composite, keeping undo correct for groups, and giving evidence of extensibility instead of claiming it.

First step

Before touching the code, say what will change: a group that plays the shape role and holds shapes, plus commands to group and ungroup. Then check which existing classes must change, ideally none, and say that too.
Follow-ups
- A group's recolour must be undone. How does the command know the old colours?
- Groups can contain groups. What breaks?
- How would you prove that no existing method changed?
From the lesson Timed LLD mock rounds focused on patterns
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes

All Design Patterns (GoF and modern) interview questions · The Design Patterns (GoF and modern) track

Warm-up questions

How do you decide which design pattern to use for a requirement?

What is a characterization test, and why write one before refactoring?

Questions with model answers

A parking lot charges by the hour on weekdays, a flat fee at weekends, and an extra fee at spots with an electric-vehicle charger. Which patterns would you use for pricing, and which alternative would you reject?

In a design review you proposed Observer for order-status notifications. A colleague says a direct call from the order service to the notification service is simpler. How do you decide who is right?

A 600-line function switches on the order type in five places, and a new order type ships next week. How do you refactor it safely, and in what order?

You must refactor legacy code that has no tests and reads the current time and a database directly. How do you start?

How would you check automatically that a refactoring reached its goal, such as "no more switches on the order's status", and what can go wrong with such a check?

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?