Solving an LLD problem in an interview can be done easily if we divide the solution into multiple stages and focus on solving these stages one by one. LLD problems can be broadly categorized into 2 types: Standalone applications, and web applications.

Solving an LLD problem can be divided into mainly 3 stages:

1. Clarify & Gather Requirements: The low-level design interview questions are intentionally open-ended/ unstructured similar to real-life conditions. Ask the relevant questions regarding the problem (good questions are the ones that HELP to understand more about the system behaviour, features, and what features are expected to be added to the system in the future) and gather the complete requirements of the system. Don't assume anything beforehand and always clarify with the interview the assumptions you want to take. Write down the requirements & assumptions and discuss them with the interviewer.

2. Class Diagram & Use Case Diagram & Schema Diagram (If required): Once the requirements are gathered, DEFINE the core classes and objects, how the different classes interact with each other, and actors who interact with the system, the use cases for each actor, etc. Draw the class diagram and use a case diagram (can be optional, ask the interviewer) for the system. Define the relations between classes by observing the interactions between them. If Class Diagram & Use Case Diagram helps in representing the requirements of systems and the relationship between different classes, a Schema Diagram (also called an ER Diagram) helps in how the data models look and how to store the data in the database. Interviewers may not ask to write the code to store the data in the actual database but they may be interested in how the model looks like and the relationship between them. It is EASY to create the Schema Diagram from the Class Diagram. Each class in the class diagram becomes a table in Schema Diagram and the relationship between classes becomes the multiplicity between tables.

3. Code: FINALLY once the thoughts are structured using Class Diagram, Use Case Diagram, and Schema Diagram (if required), the Candidate can start writing the code. Apply the Design Patterns, Object-Oriented Principles & SOLID Principles wherever is possible to MAKE the system reusable, extensible, and maintainable. Make sure the code is well structured and follow the clean coding practices to make the classes and method clean. Don't try to fit design patterns to code but check if a given problem can be solved using any available design pattern. Take care of the readability of code while taking care of all of the above. Yes, software engineering is hard.