Four solution design interview questions on sizing, total cost of ownership, build vs buy, stakeholder conflict and proposal risk, with worked numbers.
What you'll learn: how to answer four solution design questions (sizing and total cost of ownership, build vs buy, a conflict between stakeholders, and risk in a fixed-price proposal) by stating assumptions, showing the arithmetic and recommending one option with a reason.
Solution design questions reward a candidate who puts numbers on the table early and says what would change the answer. Interviewers rarely care whether your figure matches theirs; they care whether you can size a system from a few facts, name the costs people forget, and protect a proposal from risks nobody mentioned. All numbers here are illustrative, every price is a placeholder to be replaced with the provider's published price, and the examples are reasoning, not scripts.
Figure 1. Answer framework for sizing, cost and proposal questions
flowchart TD
accTitle: Answer framework for solution design questions
accDescr: State assumptions, compute the numbers, compare two or three options, recommend one, then say what would change the recommendation. A changed assumption loops back to the compute step.
A["State assumptions"] --> B["Compute the numbers"]
B --> C["Compare two or three options"]
C --> D["Recommend one with a reason"]
D --> E["Say what would change it"]
E -- "assumption changes" --> B
How to read this: the last box feeds back to the second, because a good answer is a model the interviewer can change, not a single number.
How to use this page
Speak your answer for four minutes, then compare it with the example. When the example gives a number, redo the arithmetic yourself. If you cannot reproduce it, you cannot defend it.
Q1. A distributor wants an assistant for 400 sales engineers. Size it and estimate the twelve-month total cost of ownership.
What it assesses. Whether you can turn a headcount into load, concurrency and cost from stated assumptions, and whether you remember the costs that are not the model bill: hosting, evaluation, upkeep and people time.
Answer framework.
State assumptions: users, queries per user per day, working days, tokens per query, peak share.
Compute volume: queries per day and per month.
Compute peak concurrency from peak requests per second times latency.
Compute usage cost with placeholder prices, then add fixed costs and engineer-days.
Show the sensitivity: what moves the total most, and what you would measure in the pilot.
Strong answer example. The table is the working; the spoken answer follows it.
Quantity
Working
Result
Queries per day
400 users x 12
4,800
Queries per month
4,800 x 21 days
100,800
Peak hour
30% of 4,800
1,440 an hour, 0.4 a second
Concurrent requests
0.4 x 8 s latency
3.2, plan for about 10
Input tokens a month
100,800 x 3,000
302.4 million
Output tokens a month
100,800 x 400
40.32 million
Model cost a month
302.4 x $1 + 40.32 x $4 (placeholder prices per million tokens)
$463.68
I would state the assumptions first: 12 questions per engineer per working day, 21 days a month, 3,000 input tokens and 400 output tokens per request, an 8 second response time, and 30% of the day's traffic in the busiest hour. That gives 100,800 queries a month and about 3.2 concurrent requests at peak by Little's law, which says concurrency equals arrival rate times time in system. I would plan for roughly 10 to cover bursts, not the average.
With placeholder prices of $1 per million input tokens and $4 per million output tokens, the model costs $463.68 a month, or $5,564.16 a year. The rest of the year adds a vector index at a placeholder $300 a month, monitoring and evaluation tooling at $150 a month, and 88 engineer-days: 40 to build, 3 a month for upkeep and 1 a month to refresh the test set. Non-labour total is $10,964.16, and the model bill is only about 51% of it. If usage doubled, the yearly model line would double to $11,128.32 and the total would rise to $16,528.32, about half as much again. I would measure real tokens per query in the pilot first, because the 3,000 is the number I trust least.
Common mistakes.
Using the average request rate for capacity and ignoring the peak.
Counting only the model bill.
Leaving out people time, which is usually the largest line.
Presenting a single number with no assumptions or range.
Quoting a real price from memory instead of labelling it a placeholder.
Follow-up questions.
Retrieved context raises input tokens to 6,000. What changes?
How would caching or a cheaper model for simple questions change the total?
What would make you plan for 30 concurrent requests instead of 10?
How do you decide the number of engineer-days for upkeep?
Scoring rubric.
Criterion
Weak
Acceptable
Strong
Assumptions
Hidden or missing
Stated but unchecked
Stated, with the weakest one flagged for measurement
Capacity
Uses averages
Computes peak load
Converts peak rate to concurrency and adds headroom
Completeness of cost
Model bill only
Adds hosting
Adds hosting, evaluation, upkeep and engineer-days
Sensitivity
None
Mentions "it depends"
Shows what changes with usage doubling and what to measure
Q2. The customer can license a product for the same use case or have you build it. How do you decide?
What it assesses. Whether you compare options on cost over a horizon, fit and risk, and whether you resist the engineer's bias toward building. A strong answer also says when the cost comparison is not the deciding factor.
Answer framework.
List the requirements that are fixed, such as data residency, and test each option against them first.
Compute cost over the same horizon for each option: money and engineer-days.
Find the break-even: the value of an engineer-day at which the options cost the same.
Compare risk and differentiation: who maintains it, and does it make the customer different?
Recommend one, state the horizon, and say what would change the decision.
Strong answer example. The numbers below compare a licensed product with the build from the previous question.
Option, 12 months
Money
Engineer-days
Buy: licence at a placeholder $2,000 a month
$24,000
27 (15 to configure, 1 a month upkeep)
Build
$10,964.16
88
After checking the fixed requirements, which both options pass in this example, I would compare cost. Buying costs $24,000 and 27 days. Building costs $10,964.16 and 88 days. The difference in money is $13,035.84 in favour of building, and the difference in effort is 61 days in favour of buying. Dividing, $13,035.84 over 61 days is about $214: building is cheaper over one year only if an engineer-day costs the customer less than that, so compare it with the customer's real day rate.
The horizon matters. Over three years the licence is $72,000 plus 51 days, while the build is $32,892.48 plus 184 days, which moves the break-even to about $294. So I would not say "building is cheaper" or "buying is cheaper" without a horizon. My default is to buy or configure, because maintenance is a cost that never ends, and to build only where the capability is a differentiator or a fixed requirement rules the product out. I would also run the licensed product against the same 40-question test set before committing, because a licence that cannot pass it is not an option.
Illustrative numbers: the price, effort and upkeep figures are invented for this example.
Common mistakes.
Comparing the licence with the model bill and ignoring engineer-days.
Comparing over different horizons.
Treating "we can build it" as a reason to.
Skipping the fixed-requirement test, so a product that cannot meet residency gets costed.
Ignoring exit cost: how hard it is to leave the product later.
Follow-up questions.
The product handles 80% of the use case. What do you do about the rest?
How do you price the risk that a vendor changes terms?
What would make you recommend building even though the break-even says buy?
How would you compare options when a team has no free capacity?
Scoring rubric.
Criterion
Weak
Acceptable
Strong
Constraints first
Starts with cost
Mentions requirements
Filters options by fixed requirements before costing
Cost model
Licence vs model bill
Adds engineering time
Same horizon, money and days, with a break-even
Judgment
Always builds or always buys
Weighs fit and cost
States a default, the horizon and when it flips
Verification
Trusts the brochure
Suggests a trial
Runs the same test set on each option
Q3. Security will not allow customer documents to reach an external model, and sales wants a launch in three weeks. How do you handle it?
What it assesses. Whether you resolve a conflict by reframing it as options with costs, rather than by choosing a side or splitting the difference. Interviewers watch for respect for both constraints and for explicit decisions.
Answer framework.
Separate the interests from the positions: what each side is protecting.
Find the part of the scope that satisfies both.
Price each path in time and risk.
Put two or three options in front of the person who owns the decision.
Write down the decision and what each side accepted.
Strong answer example. The example uses a real sample, not opinions.
Security is protecting customer data from leaving the boundary; sales is protecting a date. Those are not opposed unless the launch needs the restricted documents. So I would sample 50 questions the sales engineers actually ask and check what each needs. Suppose 30 can be answered from the public product catalogue, which is 60%, and 20 need restricted documents.
That gives three options. One: launch in three weeks with public documents only, about 8 engineer-days, and add restricted documents later. Two: host a model inside the customer's own cloud account so restricted data stays inside, about 15 engineer-days plus approvals, which uses the whole 15-working-day window for one engineer and leaves no slack for the approvals. Three: redact restricted fields before sending them out, which I would not recommend, because redaction misses are exactly the incident security is worried about. My recommendation is option one now and option two as phase two, with the 60% figure measured in the pilot. I would present it to the sponsor who owns both teams' priorities, and write down that sales accepts a smaller first release and security accepts the public-only scope.
Illustrative numbers: the sample split and effort estimates are invented for this example.
Common mistakes.
Taking sales' side because the deadline is visible.
Taking security's side and delivering nothing for a quarter.
Proposing a compromise nobody has priced.
Negotiating with each party separately, so each hears a different story.
Skipping the written decision, so the conflict returns in week five.
Follow-up questions.
Security says the public-only scope is still not acceptable. What next?
How would you measure that 60% figure before promising anything?
Who is the right person to make the call in your own team?
What evidence would persuade security that a hosted model is acceptable?
Scoring rubric.
Criterion
Weak
Acceptable
Strong
Interests
Takes a side
Hears both sides
States what each side is protecting
Options
One compromise
Two options
Two or three options, each with time and risk
Evidence
Opinion
Uses a general estimate
Samples real questions and measures coverage
Decision
Negotiates informally
Seeks a manager
Gets the owner's decision in writing, with acceptances
Q4. You are asked to bid a fixed price for "AI that answers supplier emails at 95% accuracy". What risks do you raise, and how do you protect the proposal?
What it assesses. Whether you can read a vague bid for undefined terms, hidden dependencies and open-ended acceptance, and turn them into contingency, assumptions and gates. It tests commercial judgment as much as engineering.
Answer framework.
Mark the undefined terms: "answers", "accuracy", "supplier emails".
List risks that depend on the customer: data access, labelling, integrations.
Estimate each as probability times impact in days.
Decide what goes into contingency, what into assumptions, and what into exclusions.
Propose structure: a short paid discovery, milestone gates and change control.
Strong answer example. The register below turns risks into days.
Risk
Probability
Impact in days
Expected days
Data access delayed
0.5
8
4.0
Customer labelling of 100 test questions slips
0.4
5
2.0
Undocumented legacy interface
0.3
10
3.0
Model behaviour changes after a provider update
0.2
4
0.8
Total
9.8
Before pricing, I would ask what "accuracy" means. 95% of what, on whose labels, measured on which emails? Without a test set the customer can always say the number was missed. So I would make building and agreeing a 100-question test set the first milestone.
On a base estimate of 40 days, the register adds 9.8 expected days, about 24.5%, so I would carry roughly 10 days of contingency and list four assumptions: data access by week one, labelled questions by week two, a documented interface, and a fixed model version during acceptance. I would exclude languages, attachments and any system not named. And I would propose a 5-day paid discovery to confirm the data before the fixed price is set, because the largest risk is not engineering but what we do not know yet. Change control would price any addition in days, using the same rule as the estimate.
Illustrative numbers: probabilities, impacts and the base estimate are invented for this example.
Common mistakes.
Accepting "95%" without a definition or a test set.
Pricing the happy path and calling the gap "buffer".
Hiding assumptions in the appendix instead of the front page.
Treating every risk as the same size.
Offering fixed price for work whose input data nobody has seen.
Follow-up questions.
The customer will not pay for discovery. What do you do?
Which risk would you move to the customer through a contract clause?
How do you handle a 95% target that is unrealistic for the data?
What do you do when a risk fires halfway through?
Scoring rubric.
Criterion
Weak
Acceptable
Strong
Definitions
Accepts terms as given
Questions "accuracy"
Defines accuracy, labels and test set before pricing
Risk quantification
A list of worries
Ranks risks
Probability times impact in days, summed into contingency
Contract structure
Single fixed price
Adds assumptions
Assumptions, exclusions, gates and change control
Reduction of uncertainty
Prices through it
Suggests a pilot
Proposes paid discovery targeted at the largest risk
Lesson 11 of 15 · AI Solution Architect: Estimate, Propose and Defend
Four solution design interview questions on sizing, total cost of ownership, build vs buy, stakeholder conflict and proposal risk, with worked numbers.
In the rest of this lesson
How to practise
Next
Enrolling is free. It unlocks every lesson in AI Solution Architect: Estimate, Propose and Defend, tracks your progress across devices and keeps your quiz scores. The newsletter is optional.
Real architecture decisions, LLMOps patterns that survive production, and engineering leadership advice — from 12+ years of building at enterprise scale. Free. No spam. Unsubscribe anytime.
Get new articles by email
Free. We email a confirmation link first, and you can unsubscribe from any email.