1 min lesson

A defensible cost model leads with named, challengeable assumptions

Use the lesson to respond to this: "You finish the take-home cost model but you're unsure of two inputs. What's the strongest way to handle that uncertainty in the artifact?" Keep the answer plain.

# Assumptions (challenge these, not my arithmetic)
GPU_HOURLY        = 2.50     # blended $/GPU-hr, reserved + on-demand mix
UTILIZATION       = 0.30     # sustained; GPUs commonly run 15-30%
REQ_PER_DAU_DAY   = 40       # avg inference requests per active user/day
DAU               = 1_000_000
GPU_REQ_PER_SEC   = 12       # throughput per GPU at target latency

# Derived
req_per_day   = DAU * REQ_PER_DAU_DAY            # 40M req/day
req_per_sec   = req_per_day / 86_400             # ~463 rps avg
gpus_needed   = req_per_sec / (GPU_REQ_PER_SEC * UTILIZATION)
daily_cost    = gpus_needed * 24 * GPU_HOURLY
cost_per_req  = daily_cost / req_per_day
cost_per_dau  = daily_cost / DAU
# Sensitivity: sweep UTILIZATION in {0.20, 0.30, 0.50} -> watch cost_per_dau move

Sanity-check before you submit

Do the units cross out end to end. Does cost-per-active-user land in a believable range. Does the answer change in the direction you'd expect when you raise utilization. If a single typo in one assumption can flip your recommendation, that's exactly why you put assumptions at the top and ran sensitivity.

The fence-sit kills you

“It depends” with no decision is a fail. The role exists to give technical leaders a recommendation they can act on. Pick a position, state the conditions under which you'd reverse it and move. Reviewers reward a defensible point of view over a hedge every time.

A defensible cost model leads with named, challengeable assumptions

Step 1 of 2