Ground it in reality: "I used Strategy for payment processing — each provider implements a PaymentGateway interface, and the service picks the right one at runtime. I would not use it if we only ever had one provider — that is a premature abstraction."
Common patterns in PHP: Repository (data access abstraction), Strategy (swappable algorithms), Factory (complex object creation), Observer/Event Dispatcher (decoupled notifications), Decorator (adding behaviour to existing objects), and Builder (step-by-step construction). Good examples of solving real problems: Strategy for payment providers (switch between Stripe and PayPal without changing business logic), Repository for testability (mock the repository, not the database). Over-engineering examples: Abstract Factory for an application with only one concrete implementation, or Observer pattern when a simple method call would suffice. Strong candidates show they apply patterns to solve problems, not to demonstrate knowledge.
Tests design maturity. Candidates who cannot name patterns they use in practice lack experience. Those who apply patterns everywhere without considering trade-offs create unnecessarily complex code. The best answer includes a pattern they chose NOT to use.