Optiver Intern Software Engineer Interview Experience — A 90-Minute OOD/State-Machine OA on CPU Core Cooling

I recently finished this company's Summer SDE Intern OA, so I'm writing this post to give back to the community.

There were two parts in total. One part was a HackerRank OA (90 minutes), an OOD / state machine simulation problem — a puzzle game kind of like Tower of Hanoi.

Problem overview

Implement an OverheatPreventionController class to simulate and manage the temperature and cooling state of a multi-core microprocessor. There's no physical sensor in the system — temperature changes have to be computed purely in code, based on the power load (Watts) and the cooling configuration.

Core methods to implement

• __init__: initializes the passive cooling capacity, the per-core active cooling capacity, and all the Core IDs.
• set_core_load: lazily updates a specific core's load, or restarts a core that has been shut down.
• tick: advances the timestamp, processes pending load changes, and returns the list of cores whose state changed since the last tick.

Approach

At its core, this problem is a "state machine + event-driven simulation," which can be broken down into three key steps:

1. State management: In __init__, use a hash map to record each core's current state (current temperature, current load, whether it's shut down, etc.). Since tick needs to return the cores whose state changed, you have to compare the state at the end of the current tick against the state at the end of the previous tick.
2. Timestamps and heat simulation: Both set_core_load and tick trigger time to advance. The core formula is Δt = current_timestamp − last_timestamp, and you use Δt to simulate the heat accumulated or dissipated during that interval.
3. Edge cases: pay attention to what temperature triggers overheat protection and shuts a core down, and how a shut-down core gets reactivated through set_core_load.

Key gotchas and extra details

On the temperature model: heat generation is proportional to the current load (Watts); heat dissipation has two parts — passive cooling shared across all cores, and active cooling that's independent per core.

⚠️ Blind spot: read carefully how the problem defines the allocation of shared (passive) cooling. How that shared resource gets split or deducted when some cores are shut down and others are under high load is the key to passing all the test cases.

On the ordering of the list tick returns: when multiple cores change state in the same tick (e.g. overheating or restarting at the same time), the returned list[str] must never be in random order. The problem usually requires one of the following: sorted by Core ID in lexicographical order, or strictly in the order the events occurred.

Suggestion: sort by Core ID with .sort() before returning the result, so you don't fail test cases because of the randomness of hash map iteration order.

Summary

Overall it doesn't test complicated LeetCode algorithms like DP or graph theory — it mainly tests whether you have the patience to read through the long, tedious problem statement and whether you can write clean, modular code.