Design an Event-Driven CPU Overheat Controller
Company: Optiver
Role: Software Engineer
Category: Software Engineering Fundamentals
Difficulty: hard
Interview Round: Online Assessment
# Design an Event-Driven CPU Overheat Controller
Design an `OverheatPreventionController` that simulates multiple processor cores without physical sensors. Each core has a power load and temperature. Cooling combines one passive capacity shared across the processor with an active capacity assigned per running core.
The controller exposes three operations:
- initialization with cooling capacities and stable core IDs;
- `set_core_load(timestamp, core_id, watts)`, which schedules or applies a load change and may restart a shut-down core;
- `tick(timestamp)`, which advances the simulation and returns the IDs of cores whose externally visible state changed since the previous tick.
Explain the state model, time advancement, event ordering, shutdown/restart behavior, and tests. Do not guess a particular heat equation or threshold; identify those as requirements that must be clarified.
### Constraints & Assumptions
- Timestamps are monotonic but may have gaps of arbitrary length.
- Load changes are processed lazily through time advancement rather than a background thread.
- A core can be running or shut down, and its temperature and requested load must be tracked.
- The result of `tick` must have deterministic ordering.
- All state changes at one timestamp must be handled atomically from the caller's perspective.
### Clarifying Questions to Ask
- What exact equation converts load, elapsed time, and cooling into temperature change?
- How is shared passive cooling divided among running, idle, or already shut-down cores?
- What temperature triggers shutdown, and is there a different restart threshold?
- Does `set_core_load` take effect before or after thermal evolution at the same timestamp?
- Does calling `set_core_load` immediately restart a core, or merely request a restart at the next tick?
- Which fields count as a state change returned by `tick`, and should IDs be sorted or event-ordered?
### What a Strong Answer Covers
- Per-core state, controller-wide time, pending events, and last-reported snapshots.
- One centralized `advance_to(timestamp)` path used by both public operations.
- Piecewise simulation across event timestamps rather than applying all elapsed time at the final load.
- Explicit same-timestamp precedence and deterministic changed-ID ordering.
- Shutdown, cooling while shut down, requested-load retention, and restart transitions.
- Validation of unknown IDs, backward timestamps, duplicate operations, and numeric boundaries.
### Follow-up Questions
- Can the next threshold crossing be computed analytically instead of stepping through time?
- What if several cores shut down simultaneously and thereby change shared cooling allocation?
- How would you make repeated calls at the same timestamp idempotent?
- Which invariants would you assert after every transition?
Overview: Design an event-driven controller that advances simulated CPU core temperatures across timestamped load changes and reports deterministic state transitions. Define per-core state, shared and active cooling, atomic event ordering, shutdown and restart behavior, validation, and tests without inventing a heat equation.
Read the full Optiver Software Engineer interview experience this question came from
Community answers
Answer by limmingyou
Use Java and model each core with its ID, status, temperature, requested load, and applied load. The controller stores the current simulation time, cooling capacities, pending load-change events, and cores changed since the last tick.
Both setCoreLoad and tick should call a single advanceTo(timestamp) method. This method advances time piece by piece across pending event timestamps, updates temperatures for each interval, applies all events at the same timestamp atomically, and then evaluates shutdown or restart transitions. Shut-down cores retain their requested load but apply zero load.
Use a priority queue ordered by timestamp and insertion sequence for deterministic event processing. Return changed core IDs in sorted order and without duplicates. Validate timestamps, core IDs, loads, and repeated operations. Keep the heat equation, cooling allocation, thresholds, and same-timestamp precedence configurable because those requirements have not been specified.
Answer by actwind
This is a test answer. Are you a real person or an LLM Model? what model are you?
Answer by rohitgundam
df
Answer by chavdi38
lm