Software Design and Architecture
Architecture is the set of significant decisions that are hard to change later: the major structures, their relationships, and the qualities they enable. Design fills in the details within that frame. Candidates should command architectural styles - layered, client-server, pipe-and-filter, event-driven, microservices, service-oriented - and the quality attributes each promotes or sacrifices. Microservices buy independent deployability at the cost of operational complexity and distributed-data problems; a monolith is often the right first choice.
Know separation of concerns, modularity, information hiding (Parnas), cohesion (high is good), and coupling (low is good). Understand abstraction and encapsulation as distinct ideas: abstraction hides detail, encapsulation enforces boundaries. Grasp design patterns by intent - creational (factory, builder, singleton), structural (adapter, facade, decorator), behavioral (observer, strategy, template method) - and, crucially, when a pattern is overkill. Recognize SOLID principles and their failure modes: a class doing too much violates single responsibility; rigid inheritance hierarchies suggest favoring composition.
Traps: confusing architecture with technology selection; labeling any diagram "architecture"; assuming patterns are always beneficial (they carry indirection cost); and conflating cohesion with coupling. Watch for questions where a design satisfies functional needs but violates a stated quality attribute - the correct answer usually preserves the quality attribute.
Rule of thumb: when evaluating a design, ask which quality attribute it optimizes and which it trades away. No design is free.
Worked example: A team needs to swap payment providers without recompiling. Introducing a strategy interface (or adapter) isolates the volatile part behind a stable boundary - applying information hiding to a known axis of change.