{"title":"Types of LLD Interviews","description":null,"content":"Companies evaluate LLD skills in very different ways. What works for a whiteboard OOD round at Amazon won't help you in a machine coding round at Flipkart or a concurrency round at Uber.\n\nHere are the **five common formats of LLD interviews** you should be aware of:\n\n\n```mermaid\nflowchart TB\n LLD[LLD Interview Types]:::primary\n\n OOD[Object-Oriented Design]:::cyan\n MC[Machine Coding]:::orange\n CONC[Concurrency Design]:::green\n API[API Design]:::purple\n SCHEMA[Schema Design]:::teal\n\n LLD --> OOD\n LLD --> MC\n LLD --> CONC\n LLD --> API\n LLD --> SCHEMA\n\n OOD --> OOD1[\"Class diagrams
Design discussion
Whiteboard/verbal\"]:::cyan\n MC --> MC1[\"Working code
Time pressure
IDE/editor\"]:::orange\n CONC --> CONC1[\"Thread safety
Synchronization
Race conditions\"]:::green\n API --> API1[\"Interface design
REST principles
Contracts\"]:::purple\n SCHEMA --> SCHEMA1[\"Database tables
Relationships
Indexing\"]:::teal\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef cyan fill:#3bc9db,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nEach format tests different skills and requires different preparation.\n\nIn this course, we will primarily focus on the **Object Oriented Design**, and **Machine Coding**. I have a separate course dedicated to [Concurrency Interview](/learn/concurrency-interview)**. **\n\n**API Design** and **Schema Design** are typically covered as part of [High-Level System Design Interview](/learn/system-design-interviews/introduction).\n\nLet's explore each type in detail.\n\n---\n\n# 1. Object-Oriented Design (OOD)\n\nThis is the most common type of LLD interview at major tech companies like Google, Amazon, Meta, and Microsoft.\n\nIn an OOD interview, you design a system by identifying classes, their attributes, methods, and relationships. The focus is on your design thinking rather than working code.\n\n### Format\n\n- **Duration:** 45-60 minutes\n- **Tools:** Whiteboard, Google Docs, or virtual whiteboard\n- **Code:** Usually pseudocode or skeleton classes (not runnable)\n- **Deliverable:** Class diagrams, interface definitions, key method signatures\n- **Interaction:** High, lots of back-and-forth with interviewer\n\n### What Interviewers Evaluate\n\n\n| Skill | Weight | What They Look For |\n| **OOP Fundamentals** | High | Proper use of inheritance, encapsulation, polymorphism |\n| **Design Patterns** | High | Recognizing when patterns fit naturally |\n| **SOLID Principles** | High | Single responsibility, open/closed, etc. |\n| **Communication** | High | Explaining decisions, responding to feedback |\n| **Trade-off Discussion** | Medium | Justifying choices, considering alternatives |\n\n\n---\n\n# 2. Machine Coding\n\nMachine coding interviews require you to write working, runnable code within a strict time limit. This format is especially popular at Indian tech companies and startups.\n\nYou're given a problem and must implement a working solution from scratch. The code must compile, run, and produce correct output. No pseudocode, no hand-waving.\n\n### Format\n\n- **Duration:** 60-90 minutes (sometimes 2 hours)\n- **Tools:** Your own IDE or online coding platform\n- **Deliverable:** Working code that compiles and runs\n- **Evaluation:** Code is reviewed after submission\n- **Interaction:** Low, usually you work independently\n\n### What Interviewers Evaluate\n\n\n| Skill | Weight | What They Look For |\n| **Coding Speed** | High | Can you implement under time pressure? |\n| **Code Quality** | High | Can you write clean, readable, maintainable code? |\n| **Correctness** | High | Does your code work for given test cases? |\n| **Testing** | High | Writing test cases or driver code |\n| **Project Structure** | Medium | Using proper packages, separation of concerns |\n| **Edge Cases** | Medium | Handling invalid inputs gracefully |\n\n\n### Tips to Succeed\n\n1. **Practice typing speed.** Seriously. You need to write fast.\n2. **Know your IDE shortcuts.** Every second counts.\n3. **Start with core functionality.** Get basics working first, add features later.\n4. **Handle input/output early.** Parse input format in the first 10 minutes.\n5. **Test as you go.** Don't wait until the end to test.\n\n---\n\n# 3. Concurrency Design\n\nConcurrency interviews test your ability to design and implement thread-safe systems. These are common at companies building high-performance or distributed systems.\n\nYou're asked to design a system that handles concurrent access correctly. This might involve implementing thread-safe data structures, handling race conditions, or designing synchronization strategies.\n\n### Format\n\n- **Duration:** 60-90 minutes\n- **Tools:** Whiteboard + code (often Java or C++)\n- **Deliverable:** Thread-safe design with synchronization strategy\n- **Focus:** Race conditions, deadlocks, performance\n\n### What Interviewers Evaluate\n\n\n| Skill | Weight | What They Look For |\n|---------------------------|--------|-------------------------------------------------------|\n| **Race Condition Identification** | High | Can you spot where race conditions occur? |\n| **Synchronization Primitives** | High | Correct use of locks, semaphores, etc. |\n| **Deadlock Prevention** | High | Understanding and preventing deadlocks |\n| **Performance Awareness** | Medium| Lock granularity, contention |\n| **Correctness Reasoning** | High | Can you prove your solution is correct? |\n\n\n### Tips to Succeed\n\n1. **Know the primitives.** Understand when to use each synchronization tool.\n2. **Identify shared state first.** What data is accessed by multiple threads?\n3. **Think about access patterns.** Read-heavy vs write-heavy affects your choice.\n4. **Prevent deadlocks.** Know the deadlock conditions and how to avoid them.\n5. **Consider performance.** Fine-grained locks vs coarse-grained locks.\n\n---\n\n# 4. API Design\n\nAPI design interviews focus on designing clean, usable interfaces. This tests your ability to create abstractions that other developers will use.\n\nYou design the public interface of a library, service, or module. The focus is on method signatures, contracts, and usability, not internal implementation.\n\n### Format\n\n- **Duration:** 30-45 minutes\n- **Tools:** Whiteboard or document\n- **Deliverable:** API signatures, request/response formats, error handling\n- **Interaction:** High, discussion about design choices\n\n### What Interviewers Evaluate\n\n\n| Skill | Weight | What They Look For |\n| **Usability** | High | Is the API easy to use correctly? |\n| **Consistency** | High | Naming conventions, parameter patterns |\n| **Extensibility** | Medium | Can it evolve without breaking changes? |\n| **Error Handling** | Medium | Meaningful error codes and messages |\n| **REST Principles** | Medium | Proper resource modeling for web APIs |\n\n\n### Tips to Succeed\n\n1. **Study good APIs.** Learn from Stripe, Twilio, GitHub APIs.\n2. **Follow REST conventions.** Proper resource naming, HTTP methods.\n3. **Think about pagination.** How will users handle large result sets?\n4. **Plan for errors.** Clear error codes and messages.\n5. **Consider versioning.** How will you evolve the API?\n6. **Think about authentication.** API keys, OAuth, JWT.\n\n---\n\n# 5. Schema Design\n\nSchema design interviews test your ability to model data in a database. This is often combined with OOD or asked as part of high-level design (HLD) round.\n\nYou design database tables, define relationships, and consider indexing and query patterns. The focus is on data modeling, not application logic.\n\n### Format\n\n- **Duration:** 30-45 minutes (often part of a larger round)\n- **Tools:** Whiteboard or ER diagram tool\n- **Deliverable:** Tables, columns, relationships, indexes, maybe some SQL\n- **Focus:** Normalization, query efficiency, data integrity\n\n### What Interviewers Evaluate\n\n\n| Skill | Weight | What They Look For |\n| **Data Modeling** | High | Identifying entities and relationships |\n| **Normalization** | High | Proper level of normalization (1NF, 2NF, 3NF) |\n| **Constraints ** | High | Primary keys, foreign keys, unique constraints |\n| **Indexing** | Medium | Appropriate indexes for queries |\n| **Query Patterns** | Medium | Design supports expected queries |\n\n\n\n### Tips to Succeed\n\n1. **Know normalization.** Understand 1NF, 2NF, 3NF and when to apply.\n2. **Think about queries.** Design should support the queries you'll run.\n3. **Choose indexes wisely.** Too many is as bad as too few. Design indexes based on query patterns.\n4. **Consider scale.** How will the schema perform at 10x data? Consider sharding / partitioning.\n5. **Handle edge cases.** Soft deletes, audit trails, versioning.\n\n---\n\n# How to Identify Your Interview Type\n\n### Ask Your Recruiter\n\nThis is the easiest and most reliable approach: just ask. Most recruiters can tell you the exact format.\n\nGood questions to ask:\n\n- “What type of LLD round should I expect?”\n- “Will this be whiteboard-style discussion, or will I code in an IDE?”\n- “How long is the LLD round?”\n- “Should I expect concurrency topics like race conditions or deadlocks?”\n- “Will there be any database or schema design in this round?”\n\n### Company Research\n\nIf you can’t get a clear answer, use company signals to make an educated guess. Different company types tend to prefer different LLD formats:\n\n\n```mermaid\nflowchart TB\n Q1{Company Type?}\n Q1 -->|Big Tech US| OOD[Likely OOD]\n Q1 -->|Indian Tech| MC[Likely Machine Coding]\n Q1 -->|Fintech/Trading| CONC[Likely Concurrency]\n Q1 -->|B2B SaaS| API[Likely API Design]\n Q1 -->|Database/Analytics| SCHEMA[Likely Schema Design]\n\n style Q1 fill:#00ceff,stroke:#000,color:#000\n style OOD fill:#69db7c,stroke:#000,color:#000\n style MC fill:#ffa94d,stroke:#000,color:#000\n style CONC fill:#9775fa,stroke:#000,color:#000\n style API fill:#38d9a9,stroke:#000,color:#000\n style SCHEMA fill:#f783ac,stroke:#000,color:#000\n```\n\n\n- **Big Tech (US):** More likely **OOD (whiteboard design + discussion)**\n- **Indian consumer tech / startups:** More likely **Machine Coding**\n- **Fintech / trading:** More likely **Concurrency + performance**\n- **B2B SaaS:** More likely **API Design**\n- **Database / analytics companies:** More likely **Schema Design**","pageType":"lld-interviews"}

Get Premium