Question 1

A department head says "we need a new reporting system." How do you turn that into requirements?

Accepted Answer

Start with why: which decisions the reports support, who reads them, what they do today and where it fails. Interview three or four actual users, watch them use the current process, collect the existing reports, and separate needs from wants. Produce a problem statement, a prioritised list of user needs, and a scope boundary before any solution talk. Say how long you would expect that discovery to take. Common mistake: Starting with the solution ("I would recommend Power BI"). The panel is checking that you elicit before you design.

Question 2

When would you write user stories, and when a full business requirements document?

Accepted Answer

User stories with acceptance criteria for iterative delivery where the team can talk to the business every sprint; a BRD or a formal specification when a vendor is building at a fixed price, when regulators or auditors need traceability, or when the organisation contracts on documents. Say that in practice you often do both — an approved scope document plus a backlog — and give a project where you chose. Common mistake: Treating this as agile versus waterfall. Experienced BAs pick the artefact that fits the contract and the culture.

Question 3

Two senior stakeholders disagree about a requirement and both are your customers. What do you do?

Accepted Answer

Get each position in writing with the reason behind it, find the underlying goal each is protecting, and look for an option that serves both — often the disagreement is about how, not what. If it is genuinely either-or, bring the trade-off to the sponsor with a recommendation, data if you have it, and a deadline for the decision. Give an example where you did this. Common mistake: Choosing the more senior person's option by default, or building both. The panel wants a facilitated decision with a record.

Question 4

Walk me through how you map an as-is process and find the improvement.

Accepted Answer

Observe the process, not just ask about it; map it in BPMN or a simple swimlane with the handoffs, systems and waiting times; count the steps, the rework loops and the approvals; then ask which steps create value for the customer. Give one example with numbers: an onboarding process cut from 14 days to 5 by removing two approvals and one duplicated data entry. Common mistake: Mapping what the manager says happens. The version on the floor is always different, and the panel knows it.

Question 5

Tell me about a project where scope crept. What did you do about it?

Accepted Answer

Name the original scope, the requests that arrived, and how you handled them: a change log, an impact assessment of time and cost, a decision by the sponsor or the change board rather than by you. Say what you let in and why, and what you parked to phase two. The panel wants to see a process, not a refusal. Common mistake: Presenting yourself as the person who said no to everything. Good BAs manage change, they do not block it.

Question 6

How do you write acceptance criteria that a developer and a tester both accept?

Accepted Answer

Given-When-Then or a numbered list of testable statements, one behaviour per line, with the error cases and the edge cases written out — what happens when the field is empty, when the user has no permission, when the API times out. Review them with a developer and a tester before the sprint starts. Give an example of a criterion that was too vague and what you rewrote it to. Common mistake: Criteria like "the system should be user-friendly." The developer cannot build it and the tester cannot test it.

Question 7

How do you run UAT, and what do you do when users find defects that are really missed requirements?

Accepted Answer

Write test scenarios from the requirements, recruit real users rather than managers, schedule sessions with someone from the delivery team present, log defects with severity and evidence, and hold a daily triage. When a "defect" is a missing requirement, say so honestly, log it as a change, and let the sponsor decide whether it blocks go-live. Mention exit criteria. Common mistake: Letting UAT become a second discovery phase. Set the exit criteria before you start.

Question 8

Tell me about a recommendation you made that was backed by data rather than opinion.

Accepted Answer

A concrete case: analysing six months of support tickets to show that 40% were one issue, or pulling system logs to show a feature nobody used. Say where the data came from, how you cleaned it, what you concluded, and what changed. Mention the tool — SQL, Excel, Power BI — because the panel wants to know you can get your own data. Common mistake: Describing a recommendation with no numbers in it. The question is specifically about evidence.

Question 9

How do you work with developers who say a requirement is unrealistic?

Accepted Answer

Ask them to explain the constraint so you understand it, go back to the business need behind the requirement, and look for an alternative that meets the need within the constraint. Often the requirement was a solution in disguise. Give an example where the final design was better than the original ask because of that conversation. Common mistake: Either insisting because the stakeholder wants it, or dropping it without going back to the business. Both lose trust on one side.

Question 10

What do you put in a requirements traceability matrix and when is it worth the effort?

Accepted Answer

Requirement ID, source, priority, the design element or story it maps to, the test case, and status. Worth it in regulated or contracted deliveries, large integrations, or anywhere an auditor will ask "show me where this requirement was tested." Not worth the overhead on a small product team with a good backlog tool. Say which tools you have used — Jira, Azure DevOps, Confluence, Excel. Common mistake: Claiming it is always necessary. The panel wants judgement about overhead.

Question 11

Describe a time you had to deliver a requirements document to a vendor or offshore team who could not talk to the users.

Accepted Answer

Say how you compensated for the distance: more worked examples, screen mock-ups, sample data, explicit business rules with edge cases, a glossary of terms, and a scheduled walkthrough call with a recording. Then what went wrong anyway and how you caught it early — a demo after the first two weeks rather than at the end. Common mistake: Suggesting that a good enough document removes the need for conversation. It never does, and the panel has the scars.

Question 12

How do you prioritise a backlog of eighty requests when the business says they are all urgent?

Accepted Answer

Score against two or three agreed criteria — business value, effort, risk or regulatory deadline — using MoSCoW or a simple value-effort grid, do it in a workshop with the stakeholders in the room so the trade-offs are visible, and publish the result. Say how you handle the executive who adds a request on top afterwards. Common mistake: Prioritising by who shouted loudest, or asking the sponsor to decide all eighty. The panel wants a transparent method.

Question 13

Which domain do you know best, and what is one thing a new BA would get wrong there?

Accepted Answer

Pick the domain honestly — banking onboarding and KYC, insurance claims, retail supply chain, HR systems, government e-services — and name a rule or a subtlety that took you time to learn, such as how a partial shipment affects invoicing or what a KYC refresh cycle triggers. This shows depth and self-awareness at once. Common mistake: Claiming to be domain-agnostic. True for some, but the panel wants at least one area where you are the expert in the room.

Question 14

Why do you want to work here, and what kind of BA do you want to become?

Accepted Answer

Link the company's situation — a digital transformation, a core-system replacement, a scale-up building its first product team — to what you want to learn, and be specific about the direction: product ownership, data and analytics, enterprise architecture, or senior BA leading discovery. Mention a certification only if it is genuinely in progress (CBAP, PSPO). Common mistake: A generic "I want to grow." The panel is scoring whether you have thought about their problems.

Business Analyst interview questions — and what a strong answer includes

A department head says "we need a new reporting system." How do you turn that into requirements?

When would you write user stories, and when a full business requirements document?

Two senior stakeholders disagree about a requirement and both are your customers. What do you do?

Walk me through how you map an as-is process and find the improvement.

Tell me about a project where scope crept. What did you do about it?

How do you write acceptance criteria that a developer and a tester both accept?

How do you run UAT, and what do you do when users find defects that are really missed requirements?

Tell me about a recommendation you made that was backed by data rather than opinion.

How do you work with developers who say a requirement is unrealistic?

What do you put in a requirements traceability matrix and when is it worth the effort?

Describe a time you had to deliver a requirements document to a vendor or offshore team who could not talk to the users.

How do you prioritise a backlog of eighty requests when the business says they are all urgent?

Which domain do you know best, and what is one thing a new BA would get wrong there?

Why do you want to work here, and what kind of BA do you want to become?

Answer these out loud, get coached

More technology roles

Before the interview

Get new business analyst questions by email

Business Analyst interview questions — and what a strong answer includes

A department head says "we need a new reporting system." How do you turn that into requirements?

When would you write user stories, and when a full business requirements document?

Two senior stakeholders disagree about a requirement and both are your customers. What do you do?

Walk me through how you map an as-is process and find the improvement.

Tell me about a project where scope crept. What did you do about it?

How do you write acceptance criteria that a developer and a tester both accept?

How do you run UAT, and what do you do when users find defects that are really missed requirements?

Tell me about a recommendation you made that was backed by data rather than opinion.

How do you work with developers who say a requirement is unrealistic?

What do you put in a requirements traceability matrix and when is it worth the effort?

Describe a time you had to deliver a requirements document to a vendor or offshore team who could not talk to the users.

How do you prioritise a backlog of eighty requests when the business says they are all urgent?

Which domain do you know best, and what is one thing a new BA would get wrong there?

Why do you want to work here, and what kind of BA do you want to become?

Answer these out loud, get coached

More technology roles

Before the interview

Get new business analyst questions by email