# Stop Treating OOD and HLD as Separate Interview Skills # Stop Treating OOD and HLD as Separate Interview Skills System design diagram In design interviews you aren't graded on HLD (high-level design) or OOD (object-oriented design) in isolation — you're graded on how well the two fit together. Recruiters want to see that you can go from requirements to architecture, and from architecture down to class structure, while keeping performance, scalability, and maintainability in mind. Here's a simple, repeatable approach to unify HLD and OOD in interviews: 1. Clarify requirements - Ask intent-driven questions: functional requirements, non-functional constraints (latency, throughput), scale, consistency and fault-tolerance needs, data retention, and expected future changes. - Prioritize: which requirements are must-haves vs nice-to-haves. 2. Sketch the HLD - Draw components and their responsibilities (API layer, services, storage, caches, message buses). - Show data flow and common paths (reads, writes, failure handling). - Highlight scaling points and bottlenecks (where to shard, where to cache, how to replicate). 3. Drill into OOD - Identify core domain objects and services that map to your architecture (e.g., User, Session, AuthService, StorageManager). - Define responsibilities: what each class/service owns and what it delegates. - Use OOP tools intentionally: encapsulation to hide state, interfaces to decouple modules, inheritance only when it models a real "is-a" relationship, and polymorphism to swap implementations. - Design clean interfaces to keep coupling low and cohesion high. 4. Connect OOD choices to HLD goals - For maintainability: prefer small, single-responsibility classes and clear interfaces so components can be replaced or tested independently. - For performance: move hot paths into efficient data structures or specialized components (e.g., in-memory caches, batch processors), and design interfaces that minimize synchronization or blocking. - For scalability: design stateless services or partitioned state; make sure objects and services are shardable/replicable. 5. Iterate and explain trade-offs - When the interviewer challenges a decision, iterate. Show alternate designs and explain cost/benefit: complexity vs latency, eventual consistency vs strong consistency, monolith vs microservices, etc. - Always tie back each OOD decision to an HLD objective: "I made X class stateless so instances can be horizontally scaled to meet the throughput requirement." or "I introduced an interface here to allow a faster in-memory implementation later without changing callers." Quick example (conceptual): designing a file-storage service - HLD: Client -> API gateway -> Upload service -> Chunking service -> Metadata DB + Chunk store (S3-like). Cache for frequent lookups. - OOD mapping: classes/services like UploadHandler, Chunker, ChunkStoreClient, MetadataRepository. UploadHandler is thin and stateless (easy to scale). Chunker encapsulates chunking logic; ChunkStoreClient interface lets you swap implementations (local vs S3) without changing UploadHandler. Interview checklist - Start with clarifying questions. - Draw HLD and label scaling points. - Map components to classes and interfaces. - Explain how OOD supports HLD goals (maintainability, performance, scalability). - Discuss trade-offs and fallback options. Treat HLD and OOD as one continuous design exercise. Show that you can translate high-level constraints into concrete, testable, and extensible code structure — and you’ll communicate the kind of engineering judgement interviewers are evaluating. #SystemDesign #ObjectOrientedProgramming #SoftwareEngineering