Business Analysis Interview Questions and Answers

When stakeholders cannot articulate what they want, it usually means the real problem is unclear, not that they have no needs.

I start with the problem and the outcome, not the solution. I ask about their day, what is frustrating, what takes too long and what happens when things go wrong. Concrete stories and examples reveal more than abstract questions.

Techniques I use include one to one interviews, facilitated workshops, observation or job shadowing, process mapping, document analysis and reviewing existing system reports. I ask "what would good look like?" and "how would you know it worked?"

I then play requirements back as scenarios and prototypes, because people recognise what they need when they see it far more easily than they can specify it.

I confirm understanding in writing and iterate. Silence and a quick nod often mean confusion, not agreement.

A user story is a short statement of a need from the user's perspective, usually in the form: as a role, I want a capability, so that I get a benefit. The value is in the "so that", because it explains why the story matters.

The story alone is not a specification. Acceptance criteria define the conditions that must be true for it to be considered done. I write them as concrete, testable statements, often in given when then form. For example: given an expired card, when the user checks out, then the payment is declined with a clear message.

Good criteria cover the happy path and the important edge cases, and they provoke a conversation between the business analyst, the developer and the tester rather than replacing it.

I keep stories small enough to complete in a sprint and split large ones vertically, so each delivers a slice of user value rather than a technical layer.

I model a process to create a shared, accurate picture of how work actually flows, not how people think it flows.

I start by defining the scope and boundaries, where it begins and ends, and the outcome it produces. Then I gather information through interviews, workshops and observation. Walkthroughs of real cases, rather than descriptions in the abstract, surface the exceptions and workarounds that matter most.

I map the steps, decisions, roles, systems and handoffs, using a simple notation such as BPMN or a swimlane diagram. I capture the unhappy paths too: what happens when information is missing, a system is down or an approval is rejected. I also record volumes and cycle times where available.

I validate the model with the people who do the work, because they will spot gaps immediately. The as-is model then becomes the basis for identifying delays, rework and bottlenecks, and for designing the to-be process.

Late change requests are normal. Uncontrolled late change is the problem.

First I understand the request and why it is late. There may be a genuine regulatory deadline or a real missed requirement, in which case we need to act. I assess the impact on scope, schedule, cost, quality and risk, and I make that impact explicit rather than absorbing it silently.

Then I present options: swap it for something of lower priority within the same timeline, extend the timeline, add resource, or park it for the next release. This turns the conversation from yes or no into a trade off.

The decision goes through the agreed change process with the right authority, and I document it, including who approved and why.

If late changes recur, I look at the root cause, perhaps insufficient elicitation or unclear scope, and improve the front end rather than blaming the requester.