Low-level design
Everyone can recite what Strategy is. Almost nobody can say what it costs, or notice they've actually described State. These 10 patterns are written the way the round is marked — the problem first, then the price, then the pattern it gets mistaken for and the question that separates them.
Design patterns
Swapping an algorithm at runtime, without a conditional that grows forever.
Deciding which class to instantiate, somewhere the caller doesn't have to know.
Telling interested parties something happened, without knowing who they are.
One instance, globally reachable — and why that's more controversial than it looks.
Assembling an object in steps, when the constructor has too many arguments.
Adding behaviour by wrapping, when subclassing every combination would explode.
Making an existing class fit an interface it was never written for.
Letting an object change its behaviour when its internal state changes.
Turning a request into an object, so it can be queued, logged or undone.
Fixing the order of steps in a base class, letting subclasses fill in some of them.
Machine-coding rounds
Each one states what's in scope and what isn't, because saying “I'm not handling payments — tell me if you want them” is part of what's being marked.
The canonical warm-up. Easy to start, and almost everyone fumbles the same two questions.
The cleanest State machine you'll be asked to build — and the refund path is the trap.
Four algorithms, one interface — and the interviewer wants to know which you'd pick.
Splitwise, essentially. The interesting part is settling debts, not recording them.
A scheduling problem wearing an OOP costume. Direction is what everyone forgets.
Email, SMS, push. Easy to sketch, and the retry question is where it gets real.