Top 8 Unit economics Interview Questions
Browse 8 real-world technical and behavioral interview questions about Unit economics. Review scenarios, edge cases, and architectural best practices.
You are asked to cut cloud spend by thirty percent without hurting reliability. Walk me through the case you would bring.
Agree whether thirty percent means run-rate or this year's cloud spend, absolute or per unit. Then attribute the bill, phase the cuts as quick wins, structural fixes and commitments last, and guard every change with SLO burn and a protected list. Show both the run-rate and the in-year figure.
A large retailer wants to white-label your product and sell it to their own customers. Do you do the deal?
Work out who owns the customer after the deal, because that decides whether this is distribution or the slow loss of your product. Price the engineering the partner's requirements will consume, and set the conditions under which you would walk away before you see the revenue figure.
Size the UK market for a paid meal-planning app, and tell me whether you would build it.
A product market sizing case should define the revenue pool, work top-down from households to willingness to pay, sanity-check penetration, then turn the estimate into a build-or-don't-build recommendation. It also connects estimation to the point an interviewer is testing.
The same risk comes back to you five times in one day through an aggregator, with slightly different answers each time. What does that do to your quote pipeline, and what does it do to your book?
Treat the five as one risk being re-presented, not five prospects. Resolve them to one entity, budget the response time and the per-quote cost of external data against a low conversion rate, and read the edits as price probing, because the version that finally binds is the cheapest description of the risk rather than the truest.
Two customer segments each bring in the same revenue and you can only focus on one next year. How do you choose?
Equal revenue hides unequal quality of revenue, so compare the two on retention, expansion, cost to serve, cost to acquire and headroom, then pick the one whose limiting constraint you can actually change in a year and name the condition that would reverse the choice.
What does one prediction cost you, and how would you work it out?
Divide the all-in hourly cost of the serving capacity by the predictions it delivers in that hour at your real utilisation, then add the per-request cost of feature reads. Utilisation dominates the result, and most of what people call cost per prediction is fixed cost that one more request does not change.
Your cloud bill is too high. Where does the money go, and how do you bring it down without degrading the service?
Attribute the bill before touching it, then work in order: fix the architectural decisions that generate spend, right-size against measured demand, and only commit to discounts once the shape is stable. Track a unit cost so a reduction can be told apart from a traffic drop.
Your largest customer costs more to serve than they pay you. What do you do about that architecturally?
Earn the right to the claim by attributing infrastructure cost per tenant, then separate cost caused by their usage shape from cost caused by your own design. Architecture can change the shape; the decision about who pays is commercial, and it needs the engineering evidence to happen at all.