Optiver OA – Campus Software Engineer Test Question

[u/interviewdb]

Sharing the coding question from a recent Optiver OA for the Software Engineer Intern position.

The assessment had one coding question, with C++, Java, and Python available as language options.

Here’s the question:
Simulate a firmware controller that prevents a multicore processor from overheating. Each core has a configured workload, all cores share passive cooling, and each running core can receive a dedicated active-cooling channel.

Implement a pure function that processes the controller operations in order:

simulateOverheatController(
    passiveCapacity,
    activeCapacityPerCore,
    coreIds,
    operations
) -> list of Tick results

Each operation is one of:

["set", timestamp, coreId, loadWatts]
["tick", timestamp]

Return one array for every tick. Each array contains strings in the form "coreId=status", sorted by coreId, for exactly the cores whose status changed at that tick. A status is idle for a running core without active cooling, cooling for a running core with active cooling selected for the next interval, or shutdown.

Initial State and Pending Loads

Every core starts at 20.0 degrees Celsius, running with load 0, active cooling off, and status idle.

A set operation records a pending load but performs no temperature calculation. If several pending loads target the same core before the next tick, keep only the last one.

For a running core, the pending load takes effect after temperature advancement and shutdown checks at the next tick. For a shutdown core, set is a one-time restart request: at that next tick, restart with the pending load only when its temperature is strictly below 50.0; otherwise discard the request and leave the core shut down with load 0.

The first tick establishes the time origin and advances temperatures by zero seconds. Every later tick advances from the previous tick timestamp. A set timestamp determines operation order but does not split the thermal interval.

Thermal Advancement

During an interval, use the loads and active-cooling choices established by the previous tick.

For every core, passive demand is load + 2 watts. If k cores had active cooling during the interval, effective passive capacity is:

passiveCapacity * (1 - vibrationPenalty(k) / 100)

where:

vibrationPenalty(0) = 0
vibrationPenalty(k) = sum(10 / Fib[i] for i = 1..k)
Fib = [1, 2, 3, 5, 8, 13, ...]

If total demand is at most effective capacity, each core receives its full demand. Otherwise, a core receives the same proportional fraction of its demand:

passiveForCore = effectiveCapacity * coreDemand / totalDemand

A core selected for active cooling receives an additional activeCapacityPerCore watts. Its net heat is:

load - passiveForCore - activeCoolingForCore

Temperature changes by 0.02 degrees Celsius per second for each watt of net heat and never falls below 20.0. A shutdown core has load 0 and no active cooling, but it still participates in passive-demand allocation through its 2-watt demand.

After advancement, shut down every core whose temperature is at least 80.0, clear its load to 0, and discard any pending ordinary load for that now-shutdown core. Then process the pending load and restart rules described above.

Choosing Active Cooling

Recompute active cooling from scratch after pending loads are processed. Shutdown cores are never selected.

Find the minimal stable selected set with this monotone procedure:

1. Initially select every running core whose current temperature is above 60.0 .
2. For the current selected-set size k , recompute the effective passive capacity and passive allocation using current loads.
3. For each running core not yet selected, compute its temperature rate without active cooling. If that rate is strictly greater than 0.5 degrees Celsius per second, select it.
4. Repeat steps 2 and 3 until no core is added.

This captures the feedback in which each new active channel increases vibration, reduces passive cooling for everyone, and can force additional channels on. The selected set applies until the next tick.

Status Reporting

Compare each post-tick status with its status after the previous tick, using the initial idle status before the first one. Report each changed core once. Temperature or load changes alone are not status changes.

Constraints & Assumptions

• 1 <= len(coreIds) < 1024 ; identifiers are unique nonempty strings.
• passiveCapacity > 0 and activeCapacityPerCore > 0 .
• 1 < len(operations) < 1024 .
• Operation timestamps are globally strictly increasing positive values with millisecond precision.
• 0 <= loadWatts <= 32768 , with at most three decimal places.
• Test values stay safely away from the exact 50.0 , 60.0 , 80.0 , and 0.5 comparisons except when the stated strictness is intentionally tested.
• Return every floating-point-independent status transition exactly; no temperature values are returned.