Zoox·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Apr 2026

Summary

Zoox system design round for a software engineer role. The question was a full OOP design problem with a real design decision baked in, not just 'draw some boxes.' Came away feeling okay about it but I definitely could have structured the trade-off discussion better.

Questions Asked (1)

Design an object-oriented Roller Coaster system that supports multiple coaster types (Wooden, Steel, Inverted, Hyper, etc.) and multiple scoring strategies based on attributes like speed, height, length, and thrill rating. Walk through your class structure and key methods, and discuss the trade-offs between putting scoring logic directly in the class hierarchy versus decoupling it with a Strategy pattern.

System DesignTechnical Trade-offsData Modeling

Author's notes

I went straight for inheritance because it felt natural, had a base RollerCoaster class and overrode a score() method in each subclass.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and assumptions, then design a class hierarchy for coasters with a separate scoring strategy interface. Walk through key classes and methods, and compare embedding scoring logic in the hierarchy versus using the Strategy pattern, highlighting trade-offs in flexibility, maintainability, and complexity.

Pro tip: Emphasize that the Strategy pattern aligns with the Open/Closed Principle, allowing new scoring algorithms without modifying coaster classes—a key consideration for scalable systems like those at Zoox.

1. Clarify Requirements and Assumptions

Ask questions to understand scope: What coaster attributes are available? Are scoring strategies fixed or dynamic? Should scoring be extensible? State assumptions to guide the design.

2. Design Coaster Class Hierarchy

Create an abstract Coaster class with common attributes (speed, height, length, thrill rating) and methods. Subclasses like WoodenCoaster, SteelCoaster, etc., can add type-specific behavior.

3. Introduce Scoring Strategy Interface

Define a ScoringStrategy interface with a method like calculateScore(Coaster). Implement concrete strategies (e.g., SpeedBasedScoring, ThrillBasedScoring). Coaster holds a reference to a strategy.

4. Walk Through Key Methods and Interactions

Show how a Coaster object delegates scoring to its strategy. Discuss how strategies can be swapped at runtime and how new strategies can be added without modifying coaster classes.

5. Discuss Trade-offs

Compare embedding scoring in the hierarchy (simpler but rigid, violates Open/Closed) versus Strategy pattern (flexible, follows composition over inheritance, but adds indirection). Mention when each is appropriate.

Key Points to Mention

Encapsulation of coaster attributes and behaviors in a class hierarchy.
Strategy pattern enables dynamic selection of scoring algorithms.
Open/Closed Principle: new strategies can be added without modifying existing code.
Composition over inheritance reduces coupling and increases flexibility.
Trade-offs: increased number of classes and indirection vs. maintainability and extensibility.
Potential use of Factory or Dependency Injection to manage strategy creation.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.