Scenario: Core Count vs SMT

Scenario

A team must choose between more physical cores or deeper SMT for next stepping. Simulations disagree because synchronization overhead and port pressure vary by workload class.

OBSERVED METRIC
throughput target misses despite adding SMT threads

45-MINUTE INTERVIEW FLOW
0-5: define workload and KPI
5-15: map first stage loss and mechanism
15-25: identify proving artifacts
25-35: propose bounded fix with owner
35-45: state validation matrix and rollback

Common pitfalls

• Use one benchmark suite as universal proof

• Ignore lock contention and coherence bounce at higher thread counts

• Compare peak throughput without perf-per-watt and tail latency

Scenario debrief

Score responses on workload framing, first-failing-stage identification, fix boundedness, and regression discipline.

workload intent -> pipeline behavior -> measured bottleneck -> owner fix

IPC/CPI trend

Debrief prompts

1. Which stage or protocol shows first sustained failure evidence?

2. Which owner can apply the smallest safe fix?

3. Which benchmark + counter pair proves closure in production conditions?

Key takeaways

• Always connect microarchitectural counter changes to product workload outcomes.

• Lock binary, compiler, firmware, and thermal metadata before comparing CPU traces.

Common pitfalls

• Treating average IPC as sufficient proof while ignoring latency tails and outliers.

• Applying predictor or prefetch tweaks without first-failing-stage attribution.

• Declaring closure without reproducible perf, correctness, and power gates.