BA Interview Questions That Reveal Real Skill — With Answers

Why standard BA interview questions fail

"Tell me about a time you gathered requirements from a difficult stakeholder." You have heard this question. You have probably answered it. And you have probably heard impressive-sounding answers from candidates who turned out to be mediocre BAs.

The problem with standard competency questions is that they test the ability to tell a good story, not the ability to do good BA work. The questions below are different. They reveal how a BA thinks, not just what they have done.

The 12 questions

1. "Walk me through how you would approach a project where the stakeholder says 'I want a new reporting system' but cannot tell you what they actually need."

What it reveals: Whether the BA understands that stated wants and underlying needs are different things, and whether they have a method for closing that gap.

Strong answer pattern: Start with the business problem — why do they want reports? What decisions are they currently unable to make? What would change if they had better reporting? Only after understanding the business need would they begin to elicit specific requirements.

2. "What do you do when two senior stakeholders have directly conflicting requirements?"

What it reveals: Political navigation, escalation judgment, and whether they try to solve conflicts themselves or involve the right people.

Strong answer: Surface the conflict explicitly rather than papering over it. Facilitate a conversation between the stakeholders. If they cannot resolve it, escalate to the project sponsor with the options and the implications of each. Never pick a side without authority to do so.

3. "Show me a user story you have written and explain your acceptance criteria."

What it reveals: The actual quality of their written output. Ask them to write one live if they cannot produce an example.

What to look for: Specific actor (not "user"), actionable and outcome-focused statement, Gherkin acceptance criteria with concrete data values, not abstract conditions.

4. "How do you know when you have gathered enough requirements?"

What it reveals: Whether they have a principle-based approach or whether they stop when the project schedule forces them to.

Strong answer: When the development team can build without asking clarifying questions, when the test team can write test cases without assumptions, and when the business can describe the acceptance test without help from IT.

5. "What is the most important non-functional requirement category and why?"

What it reveals: Whether they understand NFRs beyond "performance and security" and whether they can reason about trade-offs.

Strong answer: Depends entirely on the system. For a payment system, security. For a real-time monitoring system, availability. For a consumer app, usability. A BA who cannot say "it depends" and explain what it depends on does not yet understand NFRs.

6. "Describe a requirements document you wrote that turned out to have a significant gap. What happened and what did you learn?"

What it reveals: Self-awareness, honesty, and the ability to learn from failure. Be suspicious of candidates who cannot identify any gaps in their own work.

7. "How do you handle a stakeholder who keeps changing their requirements after sign-off?"

What it reveals: Whether they have a change control process and the professional discipline to enforce it.

Strong answer: Use a formal change request process. Every change is assessed for impact on scope, timeline, and cost. The stakeholder decides whether to proceed knowing the implications. If they insist on changes without formal process, escalate to the project sponsor.

8. "What is the difference between a use case and a user story?"

What it reveals: Technical knowledge and the ability to choose the right tool for the context.

Strong answer: User stories are short, collaborative, and focused on the actor's goal. Use cases are formal, comprehensive, and specify the system's response in detail including alternative and exception flows. User stories are better for agile sprints. Use cases are better for complex system interactions that require precise specification.

9. "You have been given two weeks to gather requirements for a three-year programme. How do you approach it?"

What it reveals: Prioritisation, time management, and the understanding that not all requirements need the same depth at the same time.

Strong answer: Focus on the MVP scope and the architectural decisions that constrain everything else. Gather high-level requirements for all areas and detailed requirements only for what is needed for the first release. Document what is deferred and establish a plan to gather it before it is needed.

10. "Describe how you validate requirements before handing them to development."

What it reveals: Quality mindset and the specific techniques they use.

Strong answer: Peer review with another BA. Structured walkthrough with a developer to check technical feasibility. Review with a tester to confirm the requirements are testable. Sign-off review with the business stakeholder. Requirements that cannot be peer-reviewed, are not feasible, cannot be tested, or are not signed off are not ready.

11. "What does 'good requirements' look like to you?"

What it reveals: Their professional standard and what they optimise for.

Strong answer patterns: SMART (Specific, Measurable, Achievable, Relevant, Time-bound). INVEST for user stories. Complete, consistent, correct, unambiguous, testable, and traceable. Whatever framework they use, they should be able to apply it to a requirement you give them on the spot.

12. "What do you do when you disagree with a stakeholder's requirements?"

What it reveals: Professional courage, the ability to separate facts from opinions, and when to push back versus accept.

Strong answer: Share the concern clearly and once, with evidence. If the stakeholder has authority over the decision, document the concern and the stakeholder's decision and proceed. If there is a risk to the project, escalate through the project governance structure. Never silently comply with a requirement you believe is wrong without recording your concern.