Top 10 Discovery Interview Questions
Browse 10 real-world technical and behavioral interview questions about Discovery. Review scenarios, edge cases, and architectural best practices.
Mid-demo, the prospect asks whether the product does something it does not. What do you say?
Say it does not, then find out what the requirement behind the question is, because what decides the deal is whether the gap blocks them and what the honest path around it costs. A soft yes turns into a contractual obligation that somebody else has to deliver.
The domain expert tells you one thing and the written procedure says another. How do you work out which one the system should follow?
Treat both as evidence, not verdicts: a document records an intention on a date, an expert reports today's practice inside their own scope. Most contradictions resolve as staleness, scope or the exception path, and practice departing from a control is a finding to escalate rather than a requirement to build.
How do you know a problem is real before you build anything to solve it?
You look for evidence of the behaviour, not enthusiasm for your idea: interviews about past specific episodes rather than hypothetical futures, triangulated against what usage data, support tickets and lost deals show people already do.
Take me through how you run a technical discovery call.
Set an agenda, ask about the business outcome and current process before any technology, and use the call to qualify rather than to collect requirements: establish who decides, what changed to make this the quarter they act, and what would have to be proven, then confirm it in a written recap.
You are joining a business whose industry you have never worked in. How do you get up to speed in ninety days?
Trace one real unit of work end to end, read the operational artefacts rather than the marketing ones, interview the people who handle exceptions, and publish a glossary inviting correction. Understanding shows as prediction and knowing why a rule exists; fluency only names things.
You cannot speak to your users directly because sales owns every account relationship. How do you run discovery?
Treat blocked access as a research design problem rather than a blocker. Make the account team's job easier so they open the door, triangulate the proxies you can reach against behavioural evidence, and state explicitly which decisions your sample cannot support.
Your A/B test came back not significant. What do you do next?
Establish whether the test could ever have detected the effect you cared about, because an underpowered null tells you nothing; then read the confidence interval rather than the verdict and decide whether to extend, test a larger change, or accept that the assumption was wrong.
A prospect asks for a capability your product genuinely does not have. How do you respond?
Say clearly that it is not available today, find out what outcome sits behind the request, and offer the nearest credible path — never imply a roadmap commitment you cannot get in writing, because that is the objection that loses deals at renewal rather than at signature.
The customer keeps asking for one thing and everything else you hear says they need something different. What do you do with that in discovery?
Treat the contradiction as information rather than an error to correct: work out whether the stated requirement is stale, a proxy for a driver nobody will say aloud, or a political commitment, then test it against something already decided, and put both readings in writing with a price on each.
You have inherited a system nobody left behind any knowledge of, and you have two weeks to produce a plan. Walk me through it.
Spend the first week building an evidence map from money, traffic, incidents and deploys rather than from code, and interviewing the people who touch it with one fixed set of questions. Spend the second producing a risk-ordered plan of stabilisation before structure, with unknowns listed explicitly.