Practice both kinds of interview design: system design asks how to build a reliable, scalable service, while object-oriented design (OOD), often called low-level design, asks how to organize its code, objects, and behavior. The 21 exercises below cover both, with the central design decisions to explore in each. Use them to practise explaining your reasoning—not to memorize a single “correct” architecture, because interview prompts and constraints vary.
System design and object-oriented design are different interviews
A system-design interview is an open-ended discussion about architecting a software system from scratch. Aced/Exponent describes its typical format as a 45- to 60-minute conversation. The prompt is often deliberately vague: the interviewer wants to see how you clarify the problem, choose what matters, and explain trade-offs. As the System Design Interview Handbook puts it, “There is no single correct answer.”
OOD interviews work at a different level. You translate a product request into classes, interfaces, relationships, and behavior that can be changed without turning the code into a brittle tangle. You may be asked to model a parking lot or vending machine, then walk through how objects collaborate when a user takes an action.
| Interview type | Main question | What to make visible |
|---|---|---|
| System design | How should the service work across machines and components? | Requirements, scale assumptions, APIs, data flow, storage, failure handling, and operational trade-offs. |
| Object-oriented design | How should the software model its concepts and behavior? | Responsibilities, interfaces, relationships, state transitions, extensibility, and testability. |
The two can overlap. A food-delivery product, for example, can be discussed as a distributed platform or as an object model for orders and their state changes. Clarify which level the interviewer expects before choosing your approach.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
13 system-design problems to practise
For each prompt, first establish the users and essential use cases. Then identify the constraints that would change the design. The questions below are useful starting points—not a claim that every employer asks the same set. Tech Interview Handbook and curated system-design lists include recurring examples such as URL shorteners, social products, video, chat, file sharing, logging, and stock trading; SystemDesignInterview.com presents 16 classic walkthrough problems. Together, these are a representative practice set, not a universal ranking.
1. URL-shortening service
Design a service that creates short aliases and redirects visitors to the original URLs. Clarify whether aliases expire, whether users can choose them, and what abuse controls are needed. Explore how to ensure aliases are unique, make redirects fast for a read-heavy workload, and handle hot links without letting a popular key overwhelm one part of the system.
2. Social-news feed
Design a feed for stories from followed accounts or communities. Decide how posts are ranked, how pagination behaves as new items arrive, and how fresh the feed must be. Compare generating feeds when a post is written with assembling them when a reader opens the app; consider the consequences when an account has an unusually large audience.
3. Video-on-demand platform
Cover the path from upload to playback: media ingestion, transcoding, object storage, metadata, and delivery through a content delivery network. Ask which playback qualities and devices matter. Include processing failures, access controls, and playback metrics, and explain which parts of the path need low latency.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems4. Chat service
Model conversations, message ordering, delivery states, offline synchronization, presence, and push notifications. Clarify whether order must be guaranteed per conversation and what users should see when a recipient is offline. Discuss reconnect behavior and how clients catch up without duplicating or silently losing messages.
5. File-sharing drive
Separate file metadata from file contents: the former describes names, ownership, permissions, and versions; the latter is the stored blob. Explore sharing and revocation rules, version history, and what happens when multiple people edit or upload changes concurrently. Include recovery and the lifecycle of deleted files.
6. Ride-hailing platform
Design rider requests, driver location updates, matching, trip state, pricing or surge behavior, and payment boundaries. Geospatial matching and frequent location updates create different workload concerns from storing trip history. Walk through a trip from request to completion, including what happens if a driver or rider cancels midway.
7. Notification service
Support multiple delivery channels while respecting user preferences. Decide how retries, deduplication, rate limits, and provider failures should work. Consider whether a retry could deliver the same notification twice, how to isolate a failing provider, and what should be recorded for delivery status and troubleshooting.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute8. Distributed rate limiter
Choose how requests are counted and limited, and where the decision is enforced. Compare candidate algorithms in terms of burst handling and accuracy. Then consider atomic counter updates across machines, tenant isolation, clock behavior, and what the service should do if the limiter itself is unavailable.
9. Search and autocomplete
Design indexing and query paths for both full search and prefix suggestions. Clarify how quickly new or changed content must appear, what ranking signals matter, and how typo tolerance affects the experience. Explore caching and latency for popular prefixes while accounting for stale suggestions and updates to the index.
10. News-feed or timeline service
This overlaps with social-news feeds but is a useful separate exercise when the emphasis is on the data and ranking pipeline. Examine write amplification versus read amplification, cache invalidation, ranking stages, and how older content is backfilled. Decide what the system does when ranking or cache services lag behind new posts.
11. Distributed logging system
Design ingestion, partitioning, retention, indexing, and query handling for logs produced by many services. Clarify acceptable loss and delay, since those requirements change the ingestion path. Consider how to keep expensive queries from disrupting ingestion or other users, and how retention affects storage and retrieval.
Recommended Free Tools
Rank #3
12. Stock-trading platform
Focus on correct order handling, risk checks, market-data fan-out, and auditability. Clarify which actions require strict ordering and which data can be distributed more broadly. Walk through an order’s lifecycle and consider what must be recorded to reconstruct decisions after a failure or dispute.
13. Calendar and meeting scheduler
Model time zones, recurring events, conflict detection, reminders, and concurrent edits. Ask how recurrence is represented and what “conflict” means for the users involved. Consider daylight-saving transitions, invitations that change over time, and how two edits to the same meeting should be reconciled.
8 object-oriented and low-level design problems to practise
Start with the use cases and rules, not a list of nouns to turn mechanically into classes. Give each object a cohesive responsibility, expose behavior through clear interfaces, and explain how state changes. Prefer composition over inheritance when a deep subtype hierarchy would make changes brittle. Patterns are useful when they solve a real design problem, not merely because they have a name.
14. Parking lot
Model vehicles, spot types, allocation policy, tickets, pricing, and payment. Clarify how availability is determined and whether allocation depends on vehicle size, accessibility, or other rules. Keep the allocation policy separate enough that a new rule can be introduced without rewriting ticket or payment behavior.
15. Elevator controller
Represent requests, elevator cars, scheduling strategy, and state transitions, while respecting safety constraints. Distinguish a request to pick up a passenger from a destination request. Explain how a scheduling strategy can change without weakening the invariants that prevent unsafe movement.
16. Library system
Separate catalog records from lendable copies, and model members, holds, lending rules, fines, and notifications. A title can have several physical copies with different availability, so avoid treating the catalog entry itself as the loan. Walk through borrowing and returning, including what happens when another member has a hold.
Rank #4
17. Chess game
Model board state, pieces, legal moves, turns, promotion, and undo. Keep move validation distinct from rendering the board. Explain how the design can test special rules and reject illegal moves without scattering rule checks throughout unrelated classes.
18. Deck of cards
Design card and deck abstractions for shuffling and dealing, while leaving game-specific rules to the game that uses the deck. Consider how randomness is introduced so shuffling can be tested reliably. Avoid baking one game’s assumptions into a general-purpose deck model.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →19. Vending machine
Model inventory, coin validation, machine state, change, refunds, and out-of-stock behavior. A state machine can make the allowed transitions explicit: for example, accepting payment, dispensing an item, or returning money. Walk through insufficient payment and a dispensing failure as well as the successful purchase.
20. Food-delivery order flow
Model restaurants and menus, orders, courier assignment, payment, cancellation, and events. Define the order’s valid state transitions and identify which component owns each decision. Discuss what should happen if cancellation arrives while a courier is being assigned or payment is being processed.
21. Tic-tac-toe and meeting-room booking
Use these as two short exercises. Tic-tac-toe tests how you represent board state, turns, and win conditions; meeting-room booking tests availability, conflicts, and policy choices. In both, separate the rules from the interface so alternate policies can be added and tested without duplicating the core model.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A repeatable way to answer a design prompt
Use this sequence as a guide, adapting the depth to the prompt and interview time. The interviewer should be able to follow why each decision follows from the requirements.
Best Value
- Restate the problem and clarify scope. Identify users, core use cases, exclusions, and ambiguous terms. Ask questions that could change the design rather than trying to enumerate every possible feature.
- Separate functional requirements from quality goals. Functional requirements describe what the system does. Quality goals include latency, availability, consistency, cost, and security. Ask which goals take priority when they conflict.
- Estimate only where it helps. If scale is relevant, estimate users, requests per second, storage, and bandwidth. Look for hot keys or partitions as well as averages. The Sandbox’s interview guidance specifically recommends calculating QPS for estimation questions; show assumptions so the interviewer can correct them.
- Sketch the minimum viable design. For system design, show the main components and how data flows. For OOD, identify responsibilities, interfaces, and relationships. Avoid adding components before you can connect them to a requirement.
- Choose APIs, data models, and mechanisms. Explain why a storage model, queue, cache, partitioning scheme, algorithm, interface, or pattern fits the constraints. State meaningful alternatives and the cost of choosing one.
- Walk through a critical flow. Trace one or two important actions from the client through the relevant components or objects. This often exposes missing state, unclear ownership, and failure cases faster than adding more boxes or classes.
- Probe failure and change. Consider retries, idempotency, overload, observability, privacy, and recovery for systems; consider invalid states, testing, and new rules for object models. Explain what happens rather than listing failure modes without a response.
- State the trade-off and next step. Say what your design prioritizes, what it gives up, and what you would change if scale or requirements changed. A useful next improvement follows from a specific constraint, not from adding technology for its own sake.
How to explain trade-offs clearly
Compare options against the requirement they affect. “Use a cache” is not a complete trade-off; explain which reads benefit, how stale data is acceptable, and what invalidation or failure means. “Use a queue” needs a reason, such as separating a slow task from a request path, along with the consequence of delay or retries.
For system design, compare candidate solutions on:
- Requirement coverage and the scale assumptions behind the design.
- Latency, consistency, and availability, including where one goal is prioritized over another.
- Failure isolation and behavior during overload or dependency outages.
- Data lifecycle, privacy, security, and recovery.
- Operability and cost, including the extra complexity introduced by a component.
For OOD, compare designs on responsibility boundaries, coupling, cohesion, substitutability, testability, and extensibility. If a pattern adds indirection, identify the change it makes easier; if no likely change benefits, the simpler design may be better.
In a 45- to 60-minute conversation, make the important reasoning audible: state assumptions, explain the decision they lead to, and invite correction. Do not spend the whole discussion drawing a polished architecture or producing a large class diagram before confirming what the system must do.
How to get value from the practice set
Work each problem from a blank page before reading or rehearsing a model solution. Use the same prompt more than once only when you change an assumption—for example, a stricter freshness goal or a new cancellation rule—and explain how that change affects your design. SystemDesignInterview.com’s provider page describes 16 classic walkthrough problems and an eight-week plan; the point of a broad set like this is to build adaptable reasoning, not to infer that one provider’s list predicts every employer’s questions.
After each practice run, check whether you:
- Clarified scope before choosing an architecture or object model.
- Made assumptions explicit and used them consistently.
- Explained one important end-to-end flow.
- Handled at least one failure, edge case, or concurrent action.
- Named a real trade-off and connected it to a requirement.
- Kept responsibilities and ownership clear rather than adding abstractions by default.
There is no established industry-wide statistic showing a universal interview pass rate or a single set of questions used by all employers. Treat lists of “common” questions as practice material; your interviewer’s actual prompt, constraints, and evaluation criteria can differ.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
