Interview Prep Zoneby CuriouserLabs

Question 1 of 5 · architect level

Explain SOLID with examples at the service/architecture level — not just class level.

🎤 Say this first

SOLID scales up: Single Responsibility = one reason to change → service boundaries aligned to business capabilities; Open/Closed = extend via new strategies/handlers, not edits to a god-switch; Liskov = any implementation honors the interface's contract (timeouts, idempotency), not just its signature; Interface Segregation = thin, client-shaped APIs instead of fat 'entity services'; Dependency Inversion = domain logic depends on ports (interfaces), infrastructure implements adapters — the core of hexagonal architecture.

The full picture

PrincipleClass levelArchitecture level
SRPOne class, one jobA service owned by one team, changing for one business reason; avoids the shared 'common' service everyone edits
OCPStrategy/template method over switchNew payment provider = new adapter deployed, zero edits to checkout core
LSPSubtype honors contractAny PaymentGateway impl honors idempotency + timeout semantics; a 'fast fake' that skips them breaks callers
ISPSmall interfaces per clientBFFs / consumer-driven contracts instead of one giant API for all clients
DIPDepend on abstractionsPorts & adapters: domain doesn't import Kafka/JPA; infrastructure depends on domain, never the reverse

The senior move is admitting the tensions: SRP taken too far yields anemic classes and a thousand paper-cut services; OCP's abstractions have a carrying cost before the second implementation exists (YAGNI); DIP without discipline becomes interface-for-everything ceremony. Principles are forces to balance, and the balancing test is always the same — what changes together should live together; what changes for different reasons should be separable.

🔄 Likely follow-up questions

  • Where have you deliberately violated a SOLID principle and why?
  • How does LSP relate to consumer-driven contract testing?
  • How do SOLID and DDD bounded contexts relate?