Top 11 Requirements Interview Questions
Browse 11 real-world technical and behavioral interview questions about Requirements. Review scenarios, edge cases, and architectural best practices.
You have been asking clarifying questions for eleven minutes and have not drawn anything. When did that stop helping you?
Clarifying questions stop helping at the first one whose answer would not change what you draw. Past that point you are moving risk onto the interviewer, not reducing it. Turn every remaining question into a stated assumption, draw a first diagram, and ask the rest against that diagram.
A stakeholder keeps using a term you have never heard. What do you do in the meeting?
Judge whether the term blocks the decision in front of you: if it does, ask immediately, and ask for a concrete instance rather than a definition; if it does not, note it and follow up afterwards. Then play back your understanding in your own words so the correction happens in the meeting rather than in the code.
What goes in a BRD versus an FRD versus a user story, and how do you decide which to produce?
A BRD explains the business objective and sponsor decision, an FRD describes required system behavior, and a user story is a small testable slice with acceptance criteria. Choose the artifact by audience, governance need and delivery granularity.
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.
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.
How do you spend the first ten minutes of a system design round?
Spend roughly three minutes agreeing the functional scope, three pinning the numbers that change the architecture, and four turning those numbers into a derived estimate of request rate, storage and bandwidth — then state which design decision each number forces.
The business insists on a requirement that nobody can test — "the system must be intuitive". What do you write instead?
Convert the adjective into an observable: who is doing what task, under which conditions, and what result counts as a pass. Where no honest measure exists, record it as a design constraint with a named reviewer rather than leaving an unverifiable sentence in a document somebody signs.
You are handed a feature with no specification and two days to test it. How do you spend them?
Work in timeboxed charters rather than ad-hoc clicking: build a model of the feature from the code, the UI and whoever asked for it, name your oracles, attack the highest-risk areas first, and record findings and open questions as you go.
The sponsor has already bought the software and wants you to write the requirements for it. How do you approach that?
Do not campaign to reverse a signed purchase; change what the requirements are for. Capture the business needs and outcomes independently of the product, run a fit-gap against them, and report each gap with a closure option and a cost so the sponsor can decide where to configure, change process or accept a shortfall.
Two stakeholders give you directly contradictory requirements. How do you resolve it?
Do not arbitrate between the stated requirements; trace each back to the business objective behind it, because most contradictions dissolve at that level, and escalate the genuine ones as a documented decision for a named owner rather than deciding yourself.
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.