Use this for every problem•5 steps•35 min

LLD Interview Framework

Use the same five steps in every low-level design interview. The problem changes; the way you solve it does not.

The order matters. Requirements tell you what must happen. Those requirements reveal the objects. The objects reveal the fields and methods. Only then should you write code.

1. Requirements (~5 minutes)

The interviewer usually gives you one sentence, such as “Design Tic-Tac-Toe.” Do not start naming classes yet. First turn the sentence into a small, agreed specification.

Use these four question groups every time

1
Actions

What must a user be able to do?

2
Rules

When does an action succeed, fail, or change state?

3
Errors

Which invalid actions must we reject?

4
Boundaries

What should we deliberately not build?

Ask only questions whose answers change your design. After every answer, write one short requirement. At the end, read the list back to the interviewer.

Confirmed specification

Requirements

  1. 1.State the main actions the system must support.
  2. 2.State the rules that decide success, failure, and completion.
  3. 3.State how invalid actions are handled.
  4. 4.Choose fixed limits when scale is not the point of the problem.
  5. 5.Confirm what will not be implemented.

Not building

  • — Do not guess hidden requirements
  • — Do not discuss classes yet
  • — Do not solve future extensions now

2. Entities and relationships (~3 minutes)

Read the confirmed requirements and underline meaningful nouns. Treat them as candidates, not automatic classes.

For each candidate, speak your reasoning aloud:

  1. “This candidate came from the requirement that says…”
  2. “It would need to remember…”
  3. “It would be responsible for the rule…”
  4. “Therefore it should be a class / field / enum / left out.”

A noun becomes a class only if it owns meaningful data or performs a rule. For example, floor sounds like an important real-world object in an elevator system. But if our requirements use a floor only as a numbered position, a Floor class has nothing useful to do. Keep it as an integer.

Ask these questions:

  1. Which object receives the main request and controls the workflow?
  2. Which objects own data that changes?
  3. Which object is responsible for each rule?
  4. Does any proposed object have no useful behavior? If so, remove it.

Draw plain boxes and arrows. Say “Game owns Board” or “Controller selects Elevator.” Formal UML symbols are not required unless the interviewer asks for them.

3. Class design (10–15 minutes)

Start with the object that controls the main workflow. For each object, derive its design instead of guessing it.

What must this object remember to enforce its rule?

Class stateprivate fields

What action does another object need from it?

Public behaviorpublic method(...)

What must never happen to this state?

Validationguard clause

What decision may have several valid implementations?

Change pointinterface only if needed

Keep data private. Put a rule next to the data that rule needs. Do not expose every field and let another class make the decision.

Do not force: design patterns

A pattern is not a checklist item. Use one only when you can name the change it makes easier. “Dispatch rules may change, so I will use a Strategy” is useful. “I always use Factory in LLD” is not.

4. Implementation (~10 minutes)

Ask whether the interviewer wants full code or only the important methods. Then implement from the top-level method downward.

For every important method:

  1. Write the normal successful flow.
  2. Add checks for invalid input and invalid current state.
  3. Keep each rule in the class that owns the required data.
  4. Return a clear result instead of silently failing.

After writing code, walk through one real example.

  1. 0State the initial object state.
  2. 1Call one public method with concrete values.
  3. 2Say which object validates the request.
  4. 3Show every state change in order.
  5. 4Try one invalid action and confirm that state does not change.
  6. 5Reach a completion or direction-change case.

5. Extensions (~5 minutes)

The interviewer will change one requirement. Do not rewrite the design immediately. First identify:

  1. Which existing rule changed?
  2. Which class currently owns that rule?
  3. Can that class change alone?
  4. If several versions of the rule are now required, would an interface help?

Explain the smallest change that supports the new requirement. Implement it only if asked.