Design Patterns & LLD

Tests whether you can write a correctly synchronized Singleton, not just describe the pattern conceptually.

Tests whether you know the tradeoffs in initialization timing, thread safety, and serialization safety across all four variants.

Tests whether you know one is about multiple constructor signatures and the other is about constructors calling each other via this().

Tests whether you know Singleton isn't actually bulletproof, and how to defend against each specific attack.

Tests whether you know Factory Method delegates creation to subclasses, unlike a single static factory method.

Tests whether you know how to produce families of related objects without specifying their concrete classes.

Tests whether you know when a fluent step-by-step builder is more readable than a constructor with many optional parameters.

The Prototype pattern creates new objects by cloning an existing, fully-configured instance (via a clone() method) rather than building one from scratch through a constructor. It's useful when object creation is expensive (e.g. involves a database call or heavy computation) or when you need many variants of a complex, pre-configured object — cloning a template is far cheaper than reconstructing it field-by-field each time.

Facade provides a single, simplified interface in front of a complex subsystem with many interacting classes, hiding that complexity from the client — e.g. a single `OrderFacade.placeOrder()` method that internally coordinates inventory, payment, and shipping services. Adapter also wraps something, but its purpose is different: Adapter converts one incompatible interface into another the client already expects, while Facade simplifies an interface the client would otherwise have to navigate directly.

Tests whether you articulate the real intent -- decoupling object creation from usage so the client depends on an interface, not concrete classes -- and can show a factory method branching on a type parameter to return different implementations.

Tests whether you can show LSP concretely -- a subtype must be substitutable for its base type without breaking client expectations -- using the classic Square-extends-Rectangle violation where overriding setWidth/setHeight breaks invariants the client relied on.

Tests whether you frame DRY as 'every piece of knowledge should have a single authoritative representation,' not merely 'don't copy-paste code' -- duplicated logic (even if phrased differently) is the real violation, since both copies must now be kept in sync by hand.

Tests whether you know Strategy is chosen externally by the client, while State transitions are driven internally by the object itself.

Tests whether you can connect the abstract pattern to Spring's own ApplicationEvent/ApplicationListener mechanism.

Tests whether you know how to swap an algorithm's implementation at runtime without changing the calling code.

Tests whether you know the publish-subscribe relationship behind one of Java's oldest built-in event models.

Tests whether you know how a base class fixes the algorithm's skeleton while letting subclasses fill in specific steps.

Tests whether you know Chain of Responsibility passes a request along handlers while Command encapsulates a request as an object.

A class should be extendable to support new behavior without changing its existing, already-tested source code. In practice, this usually means depending on an abstraction (an interface) and adding new behavior by writing a NEW class that implements it, rather than adding another if/else branch to an existing class — e.g. adding a new PaymentMethod by creating a new class implementing a PaymentStrategy interface, instead of editing a giant switch statement inside PaymentProcessor.

Subtypes must be substitutable for their base type without altering the correctness of the program — anywhere a Base object is expected, a Derived object should work without surprising behavior. The classic violation is Square extending Rectangle: if setWidth() and setHeight() on Rectangle are independent, but Square must keep both equal, then a Square silently breaks any code that relies on Rectangle's contract (e.g. setting width to 5 and height to 10 and expecting area == 50).

Clients shouldn't be forced to depend on methods they don't use — a class implementing an interface should need every method on it, not just some. A 'fat interface' like Worker with work() and eat() methods forces a Robot implementation to provide a meaningless eat() method; splitting it into separate Workable and Eatable interfaces lets each class implement only what actually applies to it.

Dependency Inversion is a design PRINCIPLE stating that high-level modules shouldn't depend on low-level modules directly — both should depend on abstractions (interfaces). Dependency Injection is a PATTERN/TECHNIQUE for actually supplying those dependencies (typically via constructor) from the outside rather than a class creating them itself; using DI doesn't automatically guarantee DIP — you can inject a concrete class directly instead of an interface, which still violates the principle even though the dependency is technically 'injected.'

Tests whether you can rattle off SRP, OCP, LSP, ISP, and DIP cleanly under interview pressure.

Tests whether you can actually spot an SRP violation in code and refactor it, not just define the principle.

Tests whether you know Proxy controls access to the same interface while Decorator adds new behavior on top of it.

Tests whether you know how to make two incompatible interfaces work together without modifying either one.

Tests whether you can connect the pattern to something you've already used, like wrapping InputStream with BufferedInputStream.

Tests whether you know the different reasons to interpose a proxy — lazy loading, network calls, or access control.

Tests whether you know how sharing common object state across many instances reduces memory footprint.

Tests whether you know 'favor composition over inheritance' isn't a blanket rule but depends on whether an IS-A relationship genuinely holds.

Tests whether you know composition implies ownership and lifecycle dependency, while aggregation is a looser has-a relationship.

Tests whether you know why chaining calls through multiple objects (a.getB().getC().doSomething()) is a design smell.

Tests whether you know all the rules — final fields, no setters, defensive copying of mutable fields — not just marking a class final.

Tests whether you know when inheritance is appropriate versus when composition is the better design choice.

Tests whether you understand the two core forces that determine how maintainable an object-oriented design actually is.

Tests whether you know the three standard strategies (single table, joined, table-per-class) and their tradeoffs.

Tests whether you know the mapping rules for associations, multiplicities, and inheritance from object model to relational tables.

Tests whether you can visually communicate the order of interactions between objects during a login flow.

Tests whether you can model a rich rule system with polymorphic piece behavior cleanly in objects.

Tests whether you can model a nested hierarchy with ordering that needs to stay consistent as items move around.

Tests whether you know how to design a pluggable appender architecture that's easy to extend without modifying existing code.

Tests whether you know the Command pattern is the natural fit for reversible, replayable operations.

Tests whether you can implement the actual state transitions and thresholds, not just describe the pattern.

Tests whether you can handle overlapping-interval conflict checks and thread-safe booking cleanly.

Tests whether you can model game state and collision logic cleanly with simple data structures.

Tests whether you can reason about fine-grained locking design, not just use java.util.concurrent.ConcurrentHashMap as a black box.

One of the most common machine-coding rounds — tests whether you can model entities, allocate spots, and calculate fees cleanly.

Tests whether you can model a state machine (idle, selecting, paying, dispensing) cleanly in object-oriented code.

Tests whether you can design a request-scheduling algorithm and represent elevator state correctly.

Tests whether you can model seats, shows, and concurrent booking without double-allocating the same seat.

Tests whether you can model balances between multiple users and simplify debts efficiently.

Tests whether you can implement at least one real rate-limiting algorithm correctly, not just name it.

Tests whether you can design around provider abstraction, safe retries, and idempotent payment processing.

Tests whether you know how to draw microservice boundaries around what the business does, not around technical layers.

Tests whether you know why a mobile client and a web client often need different API shapes from the same backend.

Tests whether you recognize a shared single Connection is not thread-safe for concurrent use, and that a connection pool (not a Singleton Connection) is the correct pattern for reuse.

Tests whether you identify that a Singleton's state is shared across all threads/requests, so request-scoped data stored there leaks between unrelated requests under concurrency instead of staying isolated.

Tests whether you know how to atomically update a database and publish an event without a fragile dual-write.

Tests whether you know how to make a retried request safe to process more than once without double-charging or double-booking.

Tests whether you know how a helper container extends a service's capabilities without changing the service's own code.

Tests whether you know how routing a small percentage of real traffic to a new version limits the blast radius of a bad release.

Tests whether you know it centralizes common request-handling logic (auth, logging, routing) in one entry point instead of duplicating that logic across every individual page/action handler.

Tests whether you can apply the Open/Closed Principle to a realistic scenario, not just quote its definition.

Tests whether you know the textbook example of a subtype that technically extends a class but breaks its behavioral contract.

Tests whether you can connect the abstract concept of a race condition to a concrete double-booking bug.

Tests whether you know how to add correct synchronization to an LRU cache without serializing every single access.