Choosing Best Solution
Practice this question in a realistic, spoken behavioral interview.
Tell me about a time you had to analyze several different solutions to a problem and choose the best one.
The version of this story worth telling is a decision where two or three options were close enough that the right answer was not obvious. Walk through what each option optimized for, which constraint ended up mattering most, the evidence that shifted the choice, and the trade-off you knowingly accepted when you picked the winner.
- Should you build a new feature from scratch or integrate a third-party service?
- Should you use a well-known, stable technology or a newer, more productive one?
- Should you choose the solution that is quickest to implement or the one that is more scalable in the long run?
What Makes the Decision Convincing
Make the decision process visible:
- Show the options were real: A choice story needs at least two plausible paths, not one obvious answer and two straw men.
- Define the criteria before the winner: Explain what mattered most: latency, correctness, cost, delivery date, migration risk, team familiarity, or customer impact.
- Compare beyond technical elegance: The best design on paper may lose to a simpler option with lower maintenance or faster delivery.
- Bring evidence into the decision: Use a prototype, benchmark, incident history, customer data, operational experience, or a quick spike to move the discussion beyond opinion.
- Explain how you got alignment: The recommendation matters, but so does how you made it legible to teammates and stakeholders.
Where This Answer Usually Goes Wrong
- Skipping the criteria: "We picked X" without saying what you optimized for leaves nothing to evaluate.
- Pretending only one option existed: A choice story has to include at least one alternative you seriously considered.
- Ignoring cost, team skill, and maintenance: A purely technical comparison leaves out half the decision. Mention the non-technical factors.
- No mention of how you would revisit: Mature decisions include a checkpoint: "we will know in three months whether this was right."
- Optimizing for technical purity: If the best technical answer was not the one you picked, say why the business factor won.
How to Make the Decision Process Visible
In the Action section, slow down before the recommendation. Show the options you took seriously, the criteria you used, and the evidence that tipped the decision.
Lay Out the Options
Clearly lay out the 2-3 distinct solutions you considered. That makes the choice feel deliberate instead of like the first idea that came to mind.
Define the Criteria
State the criteria before revealing the winner. Useful criteria often include:
- Performance & Scalability
- Time to Implement (Speed to Market)
- Development Cost & Operational Cost
- Maintainability & Simplicity
- Team's Existing Skill Set
Make the Trade-Off Explicit
Walk through the comparison in a way another engineer would respect. State the criteria, identify the option that looked attractive but lost, and explain the trade-off you accepted knowingly.
How to Build the Story
Situation
Frame the problem tightly enough that the solution has criteria. "Search was bad" is vague; "support could not find customers by old order IDs during calls" gives the decision shape.
- Example: "Our support team kept getting tickets from customers who could not find invoices by partial company name or old order ID. The existing Postgres search worked for exact matches, but it was slow and missed common real-world queries."
Task
State your goal. The aim was to choose the right long-term technical approach rather than to ship the feature on the nearest path.
- Example: "As the tech lead for the fix, I had to recommend whether we should stretch the existing Postgres search, add a dedicated search engine, or buy a managed search service."
Action
Walk through the options, the criteria, and the decision.
- Identify options: "I identified three primary options. Option A was to build it ourselves using full-text search capabilities in our existing Postgres database. Option B was to use a dedicated open-source search engine like Elasticsearch. Option C was to use a third-party, managed search API service."
- Define criteria: "I then established the five key criteria for our decision: 1) Quality of search results, 2) Performance at scale, 3) Time to implement, 4) Long-term operational cost, and 5) Maintainability."
- Analyze and decide: "I created a simple decision matrix to evaluate each option. The Postgres solution was the fastest to implement but had the worst search quality and wouldn't scale well. The third-party API was also fast to implement but was very expensive and gave us less control. Elasticsearch had the best performance and search quality but had the highest implementation time and operational overhead. After building a small proof-of-concept for both Postgres and Elasticsearch, the data showed that Elasticsearch's search quality was dramatically better. I made the recommendation that we should choose Elasticsearch. I argued that the trade-off of a longer initial development time was worth the significantly better user experience and long-term scalability."
Result
Close with the outcome of the decision, including any operational cost or follow-up work that came with it.
- Example: "I presented my findings in a short design document, and the team agreed to use Elasticsearch despite the extra operational work. The first version improved the slowest searches enough that support tickets about search relevance dropped, and we had a clear follow-up list for tuning synonyms and monitoring index lag. It was a better trade-off for the product we were building, with the operational cost going in eyes open."
Answer Comparison
Thin Decision
"Search was not working well, so I looked at Postgres and Elasticsearch. Elasticsearch seemed better, so we picked that."
The answer names options, but not the criteria. Without the decision process, there is no way to tell whether the choice was thoughtful or lucky.
Decision With Criteria
(S) "We needed to replace a polling-based alert flow in our operations dashboard. Dispatchers were refreshing the page to see whether high-priority jobs had changed status, and during busy periods the polling traffic also added load to an already noisy API.
(T) My task was to recommend the first version of a real-time update path. It had to be reliable enough for operations, but we did not yet know whether usage would justify owning a lot of custom infrastructure.
(A) I seriously considered three options: improving the polling interval and caching, using a managed realtime service, or building our own WebSocket service.
The criteria were latency for dispatchers, implementation time, operational ownership, and the cost curve if more teams started using it.
I time-boxed a small proof of concept. The improved polling version was the least risky but still produced delayed updates under load. A self-hosted WebSocket service gave us the most control, but it meant our small team would own connection handling, deploys, monitoring, and incident response. The managed service was quick to integrate and had better operational support, but the pricing could become painful if we expanded it broadly.
My recommendation was to use the managed service for the first version, with usage alerts and an explicit review threshold in the design doc. The trade-off was higher vendor cost in exchange for avoiding a new operational surface while we proved the workflow mattered.
(R) We launched the first version to one operations group instead of the whole company. Dispatchers stopped manually refreshing for the highest-priority jobs, and the cost stayed below the review threshold during the pilot. We did not declare the architecture final; we documented the point where we would revisit self-hosting if adoption expanded."