Object-Oriented Design Interviews
Lead an OOD discussion from requirements to invariants, then to a small model and a demonstrable interaction. Make design choices traceable to the problem rather than to a memorized pattern.
What you’ll understand
- Lead an OOD discussion from requirements to invariants, then to a small model and a demonstrable interaction. Make design choices traceable to the problem rather than to a memorized pattern.
- Practice explaining a design decision with an example and a boundary case.
Clarify the observable behavior
For a parking lot, ask which vehicle types exist, how compatibility works, whether reservations are needed, and what leaving a vehicle returns. Then distinguish the required first version from possible extensions. A clear assumption is better than an invisible guess.
- List two successful use cases and two rejection cases.
- State whether operations are single-threaded for now.
- Define identity and ownership before naming repositories.
Walk one operation through the model
Follow park(vehicle) from the caller to allocation policy and occupancy mutation. Explain the validation order and returned ticket or failure. Use the walk to expose missing responsibilities, then refine the diagram. Keep the model small enough that another person can simulate it mentally.
- Show the point where state changes.
- Show which checks happen before mutation.
- Explain the result of a repeated request.
Handle an extension without rewriting the story
When the interviewer adds pricing or reservations, identify the changed responsibility and preserve the existing contract where possible. Do not claim that every extension is free: explain what the original design deliberately did not solve.
- Which object owns the new invariant?
- Which existing tests should remain unchanged?
- Which alternative did you reject, and why?