Traffic Light System — OOD Interview Walkthrough

Phase 1: Requirements & Use Cases

Interviewer: "Design a traffic light system."

Candidate: "Let me restate to make sure we're aligned. I'm modeling the software for a single traffic light controller — the object that manages transitions between red, yellow, and green signals, and coordinates with pedestrian signals if needed. I'm not designing a city-wide traffic management network. Is that the scope?"

Interviewer: "Yes. What actors and use cases do you see?"

Candidate: "Actors: Vehicles that observe and respond to signals (external), Pedestrians who may interact with a walk button, and an Admin or controller system that can override the light cycle (e.g., emergency vehicle preemption).

Core use cases:

1. Traffic light cycles through Green → Yellow → Red → Green automatically on a timer
2. Pedestrian presses walk button and gets a walk signal at the appropriate time
3. Admin or emergency system forces a specific state (e.g., all-red for emergency vehicle)
4. System reports current signal state
5. Intersection coordinator synchronizes multiple lights"

Interviewer: "What about adaptive traffic light timing based on sensor data?"

Candidate: "That's an interesting extension. I'd scope it out of V1 — adaptive timing requires sensor input, ML models, or external traffic management APIs. I'll design with a configurable timer duration per state so it's easy to plug in adaptive logic later, but the core model won't depend on it."

WHY: Adaptive timing is a separate concern (input processing, optimization) from the core state machine. Keeping it out of scope lets the design focus on the behavioral model.