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

Low-Level Design (Object-Oriented Design) Module 8

Code quality under time pressure interview questions

Interview questions on code quality under time pressure: warm-ups, then what each harder question tests and how a good answer starts.

8 questions: 3 warm-ups and 5 with model answers · Levels: Fresher to senior

Warm-up questions

Short questions with short answers, each answered in full.

Fresher

What is primitive obsession? Give an example from a low-level design answer.

Answered in the lesson Code smells interviewers flag in LLD answers
Fresher

Why do interviewers dislike class names such as ParkingManager or BookingHelper?

Answered in the lesson Code smells interviewers flag in LLD answers
Fresher to mid

What is the difference between over-engineering and under-modelling in a low-level design answer?

Answered in the lesson Weak LLD answers: how to spot and fix them

Questions with model answers

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

Mid to senior

Fifteen minutes are left in a 60-minute machine-coding round. Your ParkingLotService is about 300 lines long, keeps statuses as strings and repeats an if-chain on the vehicle type in three methods. What do you change now, what do you leave, and what do you tell the interviewer?
What it tests

Ranking refactorings by risk and by the follow-up most likely to come, keeping the program working after every change, and stating the remaining trade-offs plainly.

First step

Before touching anything, make sure one check runs in seconds: the tests, or a golden scenario if there are none. Then rank the smells by what a likely follow-up would hit. A new vehicle type hits the three if-chains and a new status hits the strings, so those two go first, in small steps, and the rest is said rather than done.
Follow-ups
- The interviewer adds an electric-vehicle type five minutes later.
- You have no tests at all.
- Is a 300-line class always a problem?
From the lesson Code smells interviewers flag in LLD answers
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

An interviewer points at your FeeCalculator: each of its methods reads four or five fields of a Ticket, and Ticket has no methods of its own. Is that feature envy, or a sound strategy? Say what you would move into Ticket and what you would keep separate.
What it tests

Telling feature envy from a deliberate strategy, putting behaviour next to the data it uses, and keeping rules that change for different reasons apart.

First step

List what each method reads and why it would change. Working out how long a car stayed, or whether a ticket is paid, uses only the ticket's own data, so it moves into Ticket. Pricing a stay changes when the operator changes tariffs, a different reason, so a fee policy that receives the duration and the vehicle kind can stay separate.
Follow-ups
- The operator wants a weekend tariff next month.
- After the move, Ticket has twelve methods. Is it a god class now?
- How do you test the fee rules after the move?
From the lesson Code smells interviewers flag in LLD answers
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

Your elevator answer has an interface for every class, three factories, a command class for each input word and a Singleton for the system. The interviewer says it feels heavy. What do you remove first, what do you keep, and how do you justify each choice?
What it tests

Telling structure that serves a stated need from structure added for its own sake, removing it in safe steps, and defending what stays.

First step

Ask what problem each piece solves in this prompt. The Singleton solves none and makes tests share state, so it goes first: build the system in one place and pass it on. Interfaces with one implementation and factories that only call a constructor decide nothing either. Keep the dispatch rule in one place, the one spot where a second policy is plausible.
Follow-ups
- The interviewer then asks for a second dispatch policy for the morning rush.
- How do you keep the program working while you remove layers?
- Is a Singleton ever the right choice in an LLD answer?
From the lesson Weak LLD answers: how to spot and fix them
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

Each test of your elevator answer passes when it runs alone, but two fail when the whole suite runs, and which two depends on the order. What do you look for, and how do you change the design so that it cannot happen again?
What it tests

Diagnosing order-dependent tests, finding state that outlives a test, and removing it from the design instead of patching the tests.

First step

Run the failing pair in both orders: a test that passes alone and fails after another inherits state from it. List what outlives one test: singletons, class attributes, module-level collections, caches and clocks. Then move the creation of that state to one place, such as main(), and pass it to the objects that need it, so each test builds its own.
Follow-ups
- Why not reset the singleton in the test set-up?
- The shared object is a clock or a random number generator.
- Production needs exactly one instance. How do you get that without a Singleton?
From the lesson Weak LLD answers: how to spot and fix them
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Fresher to senior

Halfway through a 60-minute round, the interviewer asks what your parking-lot answer does when a ticket is lost, a card payment is declined at the exit, or the same ticket is scanned twice. It handles none of them. Which do you design now, which do you only describe, and how?
What it tests

Ranking failure paths by harm and likelihood, turning the important ones into states, refusals or idempotent operations, and stating the rest as explicit assumptions.

First step

Sort the failure paths by what goes wrong if they are ignored: money lost, a car stuck at the barrier, a count that drifts. A duplicate scan is common and cheap to make harmless, so make the exit idempotent now. A lost ticket needs a rule from the business, so ask for it and record the answer as an assumption.
Follow-ups
- The interviewer says a lost ticket costs the maximum daily fee.
- How do you test a card payment that is declined at the exit?
- Where in the code should these rules live?
From the lesson Weak LLD answers: how to spot and fix them
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes

All Low-Level Design (Object-Oriented Design) interview questions · The Low-Level Design (Object-Oriented Design) track

Warm-up questions

What is primitive obsession? Give an example from a low-level design answer.

Why do interviewers dislike class names such as ParkingManager or BookingHelper?

What is the difference between over-engineering and under-modelling in a low-level design answer?

Questions with model answers

Fifteen minutes are left in a 60-minute machine-coding round. Your ParkingLotService is about 300 lines long, keeps statuses as strings and repeats an if-chain on the vehicle type in three methods. What do you change now, what do you leave, and what do you tell the interviewer?

An interviewer points at your FeeCalculator: each of its methods reads four or five fields of a Ticket, and Ticket has no methods of its own. Is that feature envy, or a sound strategy? Say what you would move into Ticket and what you would keep separate.

Your elevator answer has an interface for every class, three factories, a command class for each input word and a Singleton for the system. The interviewer says it feels heavy. What do you remove first, what do you keep, and how do you justify each choice?

Each test of your elevator answer passes when it runs alone, but two fail when the whole suite runs, and which two depends on the order. What do you look for, and how do you change the design so that it cannot happen again?

Halfway through a 60-minute round, the interviewer asks what your parking-lot answer does when a ticket is lost, a card payment is declined at the exit, or the same ticket is scanned twice. It handles none of them. Which do you design now, which do you only describe, and how?