Loading page…
interview prep · machine coding
The round where you turn a vague problem into classes, interfaces and running code in 60 to 90 minutes. Learn the design patterns, then work the 22 classic problems one interview step at a time.
suggested path
Foundations, then the core patterns, then easy and hard case studies.
Composition, injection, SOLID and how to read a class diagram.
Composition, UML Class Diagrams for Interviews, SOLID, Part 1: Single Responsibility, Open/Closed, Liskov, Dependency injection and 1 more
The few patterns most rounds lean on.
Strategy, Observer, State, Command and 2 more
Medium problems: one idea each, run end to end.
Parking Lot, LRU Cache, Vending Machine, Snake and Ladder and 2 more
Concurrency, state and money: the rounds that separate offers.
Rate Limiter, Elevator System, Movie Ticket Booking, Splitwise and 12 more
half one
The vocabulary of the round, in the order to learn it. Each lesson gives the problem, the class diagram, code in four languages, when not to use it, a lab and a lecture.
Behaviour that varies is easier to swap when a class holds a part than when it inherits one.
used in 7 case studies
You cannot discuss a design in an interview if you cannot draw it quickly.
Classes that do five jobs break whenever any one job changes.
A class that builds or looks up its own parts cannot be tested or changed.
used in 4 case studies
The forces behind every pattern, and the case for not adding one.
You need exactly one of something, and need to know why that is usually a trap.
used in 2 case studies
Callers hard-code which class to build, so adding a type means editing every caller.
used in 2 case studies
A constructor with ten optional arguments is unreadable and easy to get wrong.
Building an object from scratch is costly, and a careless copy shares state it should not.
A class you must use speaks a different interface than the one your code expects.
used in 3 case studies
You want to add behaviour to one object without a subclass for every combination.
used in 3 case studies
Callers must know five classes and their order just to do one common thing.
used in 6 case studies
A single item and a group of items should be used the same way, such as a file and a folder.
used in 2 case studies
You need to control access to an object: lazily, remotely, with a cache or a check.
used in 1 case study
Two things vary independently, or thousands of objects repeat the same shared data.
A rule keeps changing (pricing, matching, eviction) and an if-chain grows around it.
used in 17 case studies
Many parts need to hear about a change without the source knowing who they are.
used in 10 case studies
You need to queue, log, retry or undo an action, so the action itself must be an object.
used in 4 case studies
An object acts differently by mode and its methods fill with checks of what mode it is in.
used in 9 case studies
Several flows share the same skeleton and differ in a few steps.
A request may be handled by one of several steps, and the sender should not know which.
used in 1 case study
You want to walk a collection without exposing how it is stored.
used in 2 case studies
Objects tangle when they talk directly, and saving state must not break encapsulation.
used in 1 case study
A new operation over a family of classes should not mean editing every class.
used in 1 case study
Work arrives faster than it is handled, and shared state needs a plan, not locks everywhere.
used in 8 case studies
Patterns used for show add classes and no value; the skill is refactoring in small steps.
From the requirements to the right pattern, and saying the trade-off out loud.
Which pattern shows up in which round, and the order to read the rounds in.
half two
Each one is a full interview walkthrough: requirements, entities, class diagram, patterns, code, concurrency, follow-ups.
All 22 case studies
Floors, spots, tickets and fees, with two gates that can never give one spot to two cars.
A bounded cache with O(1) get and put and an eviction rule you can swap.
Three limiting algorithms behind one interface, built from rules and kept per key.
Several cars, hall calls and car calls, with a schedule per car and a dispatcher.
Seat holds, confirmation and expiry, with two buyers racing for the same seats.
Expenses split three ways, net balances, and the fewest payments to settle up.
A coin-operated machine as four states, each answering every button.
Formatters, sinks and filters wired as a chain, a pub-sub bus and strategies.
A board game with pluggable dice and end-of-board rules, and a turn that survives a double tap.
Pieces that know geometry and a game that decides what is legal, with undo.
A card, a PIN and a cash dispenser as states, with every failure after the debit reversed.
Titles and copies, loans, reservations, fines and reminders over a month.
Room inventory over date ranges, holds, stacked pricing and cancellation.
Riders, drivers on a grid, matching and fares, and a trip with a life cycle.
Carts, orders with a state machine, payments, partners and refunds.
Room calendars with conflict detection, recurring meetings and invites.
Files and directories as one tree, path resolution, and a thread-safe log.
A document, a cursor and an undo history, compared with snapshots.
Timed auctions with validated bids, a soft close and bidders who hear about it.
A limit order book and its matching engine, fed from eight threads.
A dependency-aware scheduler with a worker pool, retries and cycle checks.
An in-memory store with expiry, nested transactions and pluggable eviction.
pattern map
Pick a pattern to see every problem that uses it.
Choose a pattern above. The number is how many case studies use it.