Case Studies: How to Use This Module
Case Studies
The earlier modules built the method: the delivery framework, the SOLID principles, the design patterns, and the concurrency primitives. This module is where you use it. Each of the fifteen problems is the kind an interviewer states in one line — "design a parking lot," "design a rate limiter" — and expects you to turn into a class design in about forty minutes.
Reading a finished design is not the same as producing one under time pressure. What an interview measures is the path from an ambiguous prompt to a set of classes with clear responsibilities: which objects exist, what state each owns, how a request flows between them, and how the design bends when a requirement changes. That path is what these walkthroughs train, one problem at a time.
How to work through each problem
Each case study is built to be attempted, not just read. The design is presented deductively: at every real fork — which class owns a rule, what data structure fits, whether a decision is worth a pattern — a Decision checkpoint states the choice and asks you to commit before the prose reveals an answer. Stop at each one and decide. The distance between your answer and the one that follows is the feedback an interview would give you, available here without the clock running.
A productive pass looks like this. Read the prompt and run See It in Action to fix the behavior in your head. Spend a minute scoping the problem yourself before reading Clarifying Requirements. Answer each checkpoint before reading on, and sketch the classes before opening Designing the Classes. Only then use the rest — Try It Yourself puts a runnable version in the editor, and Full Solution, Run and Test, Concurrency, and Extensions check your design against a complete multi-language implementation, the races that appear once threads share state, and the follow-ups an interviewer adds at the end. Where a Mock Interview is offered, an AI interviewer runs the problem with you and grades it on a rubric.
How the problems progress
The problems are grouped by difficulty, and the tiers add distinct skills rather than just more code. The Easy problems are about a clean decomposition: name the objects, give each one a single responsibility, and keep them from reaching into each other's state. The Medium problems introduce a design pattern where the problem calls for one — a state machine, a strategy, a composite — and most add a real concurrency concern once two callers touch shared state. The Hard problems combine several interacting subsystems and turn on a subtle invariant or accounting rule: token-bucket refill, integer-cent splitting, half-open interval overlap.
Working top to bottom builds the toolkit in order, but each walkthrough stands alone, so you can also jump to a problem by its pattern or question type using the list below. The chip row under each title names the patterns, techniques, and question type it exercises and links to the concept article that teaches each.