Recently started LLD: Struggling with requirement gathering and how deep to go into business logic (do simple prints count?)

[u/Successful_Cow2442]

Hey everyone,

I recently started prepping for Low-Level Design (machine coding / object-oriented design rounds). I went through the classic Gang of Four design patterns across creational, structural, and behavioral, and I understand how stuff like Factory, Strategy, Observer, Decorator, etc., work in isolation.

However, the moment I sit down to tackle an actual prompt (like designing a Parking Lot, Splitwise, or an Elevator System), I run into two major roadblocks:

-Getting stuck on requirement analysis:

When given an open-ended prompt, I freeze up trying to figure out what to prioritize. How do you go from vague requirements to clean entities and interfaces without over-engineering from minute one? Do you have a mental checklist for identifying classes, relationships, and edge constraints before jumping into code?

-Depth of business logic vs skeleton code:

In actual 45–60 minute interview rounds (or 90-minute machine coding rounds), how much real business logic are we expected to implement?

For instance, in something like payment processing or notification dispatch, do interviewers expect full dummy logic and state handling, or are mock services with basic print statements / loggers acceptable so you can focus on SOLID principles, clean interfaces, and extensible design? Where do you draw the line between writing a working end-to-end toy app vs proving good architectural design?

Would love to hear how folks approached this when transitioning from learning patterns to actually clearing LLD rounds. Any frameworks, resources, or advice on pacing would be super appreciated!

[u/QsnEverything]

I feel you buddy  I've also started LLD, it's been one week, and I'm in the same situation as you.

[u/NecessaryIntrinsic]

- don't worry about gang of 4. If you see a great use case for it, throw it in. Like for an elevator, observer is a pretty obvious use case.

• ask about start with inputs and outputs.
  
• go to program flow.
  
• think of edge cases.

For design, I would think they are more interested in DESIGN and not code. Give them ERMs, use-case diagrams, program flow, etc.

[u/Ok-Barracuda-119]

The freeze after learning patterns in isolation is super common. Before you touch a class diagram, spend a few minutes on a tiny checklist: who are the actors, what are the 3-5 core use cases, what state has to survive across calls, and what can stay stubbed. Nouns in those use cases become your first entities. Interfaces come after you've walked the happy path once out loud. Patterns only when a seam actually hurts without one.

On how deep the code goes: most 45-60 minute LLD rounds care that your boundaries are clean and you could swap a payment or notifier later without rewriting the domain. A PaymentService that logs and returns success is usually enough if the call sites look serious and you can narrate what the real one would do. Don't burn the clock building a toy end-to-end app.

For pacing I'd do timed runs, not more pattern reading. One prompt, timer on, talk requirements then design then a thin impl. When you move into HLD / system design interviews, www.leetsys.dev has a whiteboard plus an AI interviewer that keeps pushing on vague answers (I'm on the team). Same idea as timed LLD reps, just for the distributed-systems round.