Business analyst interview questions — and the CV claims behind them
The requirements, stakeholder and process questions business analysts actually get, what each is really probing, and which line on your CV an interviewer will press hardest.
What this interview is actually testing
Whether you elicit requirements or transcribe them — and whether the process improvements on your CV were implemented or merely recommended.
The questions, and what each one is really asking
1.How do you get requirements out of a stakeholder who can't articulate what they want?
What it probes: The core skill. Weak answers describe sending a template; strong ones describe watching someone do the job, or showing a wrong mock-up to provoke a correction.
2.Tell me about conflicting requirements from two stakeholders.
What it probes: Whether you escalated a decision or invented a compromise. Analysts who resolve genuine business conflicts themselves usually resolve them wrongly.
3.Walk me through a process you mapped.
What it probes: Whether the map matched reality or the policy. Every organisation has a documented process and an actual one, and knowing the gap is the value.
4.What happened after you recommended the change?
What it probes: Implementation. This is where most BA CVs get thin, and the question is asked precisely because it is.
5.How do you know a requirement is done?
What it probes: Acceptance criteria and testability. A requirement nobody can verify is a sentence, not a requirement.
6.Tell me about something you specified that was built wrong.
What it probes: Whether you own the ambiguity. Almost always the spec had a gap, and candidates who blame the developers are telling you how they handle handover.
7.What did you find that nobody asked you to look for?
What it probes: Curiosity versus order-taking, which is the difference between a BA people request by name and one they assign.
The CV claim they'll press hardest
A process improvement figure — "reduced processing time by 40%", "saved 200 hours a year".
Business analysts recommend far more than they implement, and the interviewer's question is simply: did it get built, and did anyone measure it afterwards? A great many process improvements on CVs are the projected savings from a business case, not the realised savings from a post-implementation review — and projected figures are usually calculated by the person who wants the project approved. Saying "the business case projected 40%; it went live nine months later in reduced form, and to my knowledge nobody re-measured" is a strong, senior answer. Presenting a projection as a result fails the moment the interviewer asks who measured it.
The business analyst interview turns on a distinction that the job title does nothing to communicate: are you an elicitor or a transcriber?
A transcriber sends a requirements template, receives it back, formats it, and circulates it for sign-off. The document is accurate in the sense that it faithfully records what people said they wanted.
An elicitor assumes that what people say they want is an approximation, and goes looking for the difference. They sit with someone doing the job. They show a deliberately wrong mock-up because a correction is easier to produce than a specification. They ask what the workaround is, because the workaround is where the real requirement lives.
Every question in this interview is aimed at telling those two apart.
The most useful answer you can prepare
“How do you get requirements out of someone who can’t articulate what they want?”
Weak answers are procedural: workshops, templates, structured interviews. They are not wrong, and every candidate gives them.
Strong answers are specific and slightly undignified. Watching someone process a claim and noticing they had a spreadsheet open the entire time that appeared in no documentation. Showing a wrong screen and letting the wince do the work. Asking “what do you do when the system won’t let you?” and discovering the actual business rule.
That is the anecdote to have ready. It is the fastest way to establish which kind of analyst you are.
The implementation gap
Business analysis CVs thin out at exactly one point, and interviewers know where to press: what happened after the recommendation?
Analysts produce recommendations. Someone else decides. Someone else again builds. Frequently the thing that ships is a reduced version, nine months later, run by a different team. And very often nobody measures the result, because the person who would have measured it has moved on to the next business case.
This creates a specific and extremely common CV problem: the projected saving presented as a realised one. “Reduced processing time by 40%” is usually the figure from the business case — a number calculated by someone who needed the project approved, before anything was built.
The honest version is more credible and, importantly, is not a weaker answer: “the business case projected 40%, it went live about nine months later without the automation piece, and as far as I know nobody re-measured it. What I can tell you is the manual reconciliation step is gone, because I checked.”
That answer demonstrates the exact scepticism about numbers that the job requires. The inflated version fails the moment someone asks who measured it — and in a room full of analysts, someone always does.
Preparing
For every improvement on your CV, write down: what you recommended, what was actually implemented, when, and who measured the result. Where the honest answer is “nobody”, say so in the interview before you are asked.
Then prepare one elicitation story with a physical detail in it, and one thing you specified that was built wrong.
Our free claim checker flags the lines likeliest to invite a follow-up; the STAR guide covers the answer shape.
Questions about the interview itself
- What questions are asked in a business analyst interview?
- Requirements elicitation, conflicting stakeholders, process mapping, and how you handle ambiguity — plus, at most companies, a practical exercise: given this vague business problem, what would you ask and what would you produce. The exercise is weighted heavily because the job is largely the skill it tests.
- How do I show business analysis impact if I only wrote documents?
- Trace the document to a decision. A requirements pack that led to a system being scoped differently, a process map that showed a step nobody could justify, an acceptance criterion that caught a defect before release. Documents are the artefact, not the outcome, and interviewers are asking what changed because the artefact existed.
- Do business analysts need to know SQL?
- It depends on the team — some BA roles are close to data analysis, others are almost entirely stakeholder and process work. Read the posting. If SQL is listed, be honest in the interview about your level rather than claiming general fluency, because a live query exercise is a common and unpleasant surprise.