A Technical Interview Exercise About Build vs Buy After a Pilot
Practice a build-versus-buy interview after a pilot exposes a constraint, using observed evidence to revise the decision without defending sunk effort.
TL;DR
- In this fictional build-versus-buy exercise, use the pilot's observed results rather than an earlier preference.
- Compare complete ownership responsibilities and keep untested alternatives explicitly uncertain.
- Propose the next evidence-gathering step and explain which result would change the sourcing decision.
The practice prompt
In this fictional build vs buy interview practice, your team has piloted a third-party reporting service. The pilot completed simple reports quickly, but a required data transformation still needs custom engineering. Another team argues that you should build the entire reporting system internally.
You are asked to recommend the next step. The useful question is not whether buying or building is generally better. It is which responsibilities the team should own given the pilot evidence and the actual requirement.
Start by separating what the pilot demonstrated from what remains untested.
Inventory the observed boundary
List the tasks the service completed, the work your team still performed and the failure or limitation that triggered reconsideration.
| Pilot evidence | Decision implication |
|---|---|
| Basic reports worked | Preserve that result without generalizing to every report |
| Transformation required custom code | Estimate and own that integration explicitly |
| Recovery was not tested | Do not assume the operational behavior is acceptable |
| Full internal build is only proposed | Compare it as an uncertain option, not a finished solution |
Treat these as fictional facts supplied for the exercise. Do not add invented cost savings or performance measurements to make one option look stronger.
Compare complete ownership options
Consider at least three paths: continue with the service and a bounded custom component, change vendors, or build internally. Define the work each option leaves with the team.
An internal build includes more than initial implementation. Ask about ongoing changes, support, operation and the people available to maintain it. A purchased service also leaves integration and customer-facing responsibilities.
The pilot's existence is not a reason to continue at any cost. Equally, discovering one custom requirement does not prove that replacing the entire service is sensible.
Propose the next evidence-gathering step
Choose a small test that could change the decision. For this scenario, it might implement the required transformation against representative input and exercise a controlled failure.
State the acceptance conditions before running it. If the integration burden remains bounded and recovery is understandable, a hybrid approach may be viable. If it exposes a fundamental mismatch, reconsider the provider or internal option.
Our system design frameworks guide can help you organize these constraints. Keep the interview answer focused on the evidence needed for this particular sourcing decision.
Related reading: How to Prepare for System Design Interviews: A Complete Guide (2026).
Respond when the interviewer challenges your prior choice
A practice partner can ask, “You recommended the pilot; are you changing your mind?” Explain that the pilot was intended to reduce uncertainty and that its findings now inform the next decision.
Take responsibility for any assumptions that should have been tested earlier. Do not blame the vendor for a requirement the team never communicated or treat the initial recommendation as something to defend at all costs.
Then ask the partner to reveal a new constraint, such as an internal team losing maintenance capacity. Reassess ownership rather than changing your answer only at the feature level.
Evaluate the rehearsal
Check whether you used observed pilot results, kept untested options uncertain and compared complete responsibilities. Your recommendation should name a decision owner and a test or condition that would change it.
A strong answer can conclude that more evidence is needed, provided the next step is specific and bounded. The exercise rewards a traceable decision, not a universal preference for building or buying.