13 Business Analysis Interview Questions That Actually Get Asked (and What Good Answers Look Like)

A hiring manager at a mid-size insurance company told me her team had interviewed 14 candidates for a senior BA role last spring. Eleven of them gave textbook definitions of requirements elicitation. Two gave examples. One talked through a specific conflict they’d had with a stakeholder, what they got wrong initially, and what they changed. They hired that person within a week.

That’s the shape of a BA interview. It’s not a quiz on terminology. It’s a test of whether you’ve actually done the work and can talk about it with enough specificity to be credible. This guide covers 13 questions that come up repeatedly in BA interviews, what the interviewer is actually measuring, and where candidates usually miss the mark.

Why BA interviews are harder than they look

The role is genuinely broad. A business analyst in a bank deals with different systems, stakeholders, and pressures than a BA at a SaaS startup. Interviewers know this, so the best ones don’t ask “what is a use case” – they ask you to walk through how you’d handle a situation where a stakeholder keeps changing scope after sign-off. The question is checking whether you’ve been there, not whether you read the BABOK.

The U.S. Bureau of Labor Statistics projects 9% growth for management analysts through 2034, well above the average for all occupations, with about 98,100 openings per year. That sounds good. The problem is that competition is also up – more candidates are completing BA bootcamps and certification programs, so hiring teams are applying more rigorous screens to separate people who’ve done BA work from people who’ve studied what it looks like.

The 13 questions, and what’s actually being measured

1. “Walk me through how you gather requirements when you’re starting fresh on a project.”

This is the most common opening question, and it’s deceptively simple. Interviewers aren’t checking if you know what elicitation means. They’re checking whether you ask clarifying questions before diving in (do you understand who the stakeholders are?), whether you’ve used multiple techniques (interviews plus workshops plus document review, not just one), and whether you know when to stop gathering and start scoping.

Weak answers name techniques in abstract. Strong answers say “on a healthcare portal project, I started with a two-hour workshop with the project sponsor to understand the business problem, then ran individual interviews with three frontline users who processed claims daily, because I knew the sponsor’s mental model of the process was different from what actually happened.”

2. “Tell me about a time a stakeholder disagreed with your requirements documentation.”

This is a conflict question in disguise. The interviewer wants to know if you get defensive, if you blame the stakeholder, or if you have a real process for resolving disagreements. Good answers show you went back to the business problem (“what outcome are you trying to achieve?”) rather than arguing about whether your document was accurate.

One pattern that tends to land well: “I scheduled a walkthrough of the document with them, asked them to mark every section they weren’t confident in, and we went through those together. Three of the five issues were me using terminology they didn’t recognize. Two were genuine gaps I’d missed.”

3. “How do you distinguish between a business requirement, a functional requirement, and a user story?”

Pure knowledge question. The right answer, quickly: a business requirement is what the organization needs to achieve (“reduce claims processing time by 30%”). A functional requirement is what a system must do to support that (“the system shall auto-route claims under $500 without manual review”). A user story is a lightweight expression of a need from a user perspective (“As a claims processor, I want to see the routing decision before I approve it, so I can catch errors”). Interviewers who ask this are checking whether you can shift between documentation levels, not just whether you can define the terms.

4. “Describe a time you dealt with scope creep. What happened?”

I’d argue this is the most revealing question in a BA interview. The way someone answers it tells you how they think about accountability. Candidates who say “the project manager handled it” have probably not actually been the person responsible for managing requirements. Candidates who say “we just absorbed the changes” haven’t worked in a tight deadline environment. The answer you want to be able to give involves a change control process – how did you log it, who did you escalate to, how did you communicate the impact on timeline and budget.

5. “How do you prioritize requirements when you have more requests than the team can deliver?”

MoSCoW (Must / Should / Could / Won’t) is the most common framework, and it’s fine to reference it. But interviewers want to see that prioritization involves stakeholders, not just the BA. Who decides what’s a “must”? How do you handle two stakeholders with competing priorities? What’s your tie-breaking mechanism? If you can reference a specific method you’ve used – weighted scoring, business value vs. technical complexity matrix, whatever – and explain why that worked in your context, that’s more useful than naming the framework.

6. “Tell me about a project where the requirements you gathered didn’t fully match what got built. What did you do?”

This is testing self-awareness and process discipline. Almost every experienced BA has had this happen. The candidate who claims it’s never happened is either new or not being honest. The good answer doesn’t assign blame – it explains how you caught the gap (UAT, demo review, stakeholder walkthrough), what you did immediately, and what you changed about your process afterward to catch it earlier.

7. “What’s your process for creating a traceability matrix?”

A requirements traceability matrix (RTM) maps requirements to their source and to the test cases that will validate them. Not every company uses one – this question is partly checking whether you’ve worked in environments where compliance or audit trails matter (financial services, healthcare, government). If you haven’t used one, say so honestly and describe what you’ve used instead. If you have, explain what columns you tracked, who owned updates to it, and how it actually got used during testing.

8. “How do you handle a stakeholder who isn’t engaged or keeps missing meetings?”

Soft skill question, but it has a concrete right answer. The worst approach is to escalate immediately or route around them. The right approach starts with understanding why they’re disengaged – too busy, unclear on their role, skeptical of the project – and addressing that directly. Good candidates mention they’ve tried shorter sync formats, asynchronous review options (email summaries, recorded walkthroughs), or explicit conversations about what decisions can’t move forward without them.

9. “Describe how you write acceptance criteria.”

Acceptance criteria should be testable. The standard format most teams use is Given/When/Then: “Given a user is logged in and has submitted a claim, When the claim value is under $500, Then the system routes it automatically without a manual review step.” The question is checking whether your criteria are specific enough that a developer and a tester read the same thing and reach the same conclusion about what “done” means.

10. “What tools have you used for requirements management and process modeling?”

This varies a lot by company. Common tools include Confluence, Jira, Azure DevOps, IBM DOORS (in regulated industries), Visio, Lucidchart, and various Agile backlog tools. The expected answer isn’t a list – it’s a description of what you used and why, including what you didn’t like about it. Saying “we used Confluence but we had to add a custom tagging system because the default structure didn’t support our approval workflow” tells you more than listing six tools.

11. “How do you facilitate a requirements workshop with a group that has conflicting opinions?”

Workshop facilitation is a real skill and many BAs underestimate how much preparation it takes. Strong answers describe pre-work (agenda distributed in advance, pre-reads, roles assigned), a structured method for surfacing disagreement (affinity mapping, dot voting, parking lot for off-topic items), and a defined output (decisions made, open items documented with owners). If the group leaves a workshop with conflicting opinions still unresolved, the workshop failed regardless of how much discussion happened.

12. “Can you write or read basic SQL? When have you used data analysis in a BA role?”

This varies by company. In some BA roles, especially in analytics-heavy or data engineering environments, basic SQL is expected. In others it’s a nice-to-have. Be honest about your skill level. If you can write simple SELECT statements with JOINs and WHERE clauses, say so. If you’ve done more – writing validation queries during UAT, checking row counts against expected outputs – describe that specifically. Interviewers penalize overselling here because they often test it.

13. “How do you build a business case for a project?”

The components are usually consistent: problem statement, current state vs. desired state, options considered, recommended option, cost-benefit analysis, risks, and timeline. The harder question inside this question is how you quantify benefits when they’re soft (time saved, error reduction, user satisfaction). Good candidates describe how they’ve converted those to dollar estimates – how many hours saved at what loaded cost, what error rate means in rework cost – even when those estimates are rough. Rough and honest is better than no number at all.

Where most candidates lose points

There are a few patterns that show up consistently in BA interviews. First, candidates describe what they would do in a hypothetical situation instead of what they did in a real one. Interviewers know the difference – past-tense specifics are harder to invent convincingly. “In my last role, when we were migrating a legacy billing system, I ran four separate elicitation sessions…” is much stronger than “I would first identify all stakeholders and then…”

Second, candidates undersell communication. The work of a BA is largely about translating between groups – developers, project managers, executives, end users – who think about problems differently. Answers that skip over the communication part and jump straight to the artifact (the requirements doc, the process diagram, the user story) are missing what makes the difference between a BA and a documentarian.

Third, a lot of candidates come in having prepared for only one delivery style. If you’ve only worked in waterfall, you’ll struggle with Agile questions. If you’ve only done Agile, questions about formal requirements documentation will catch you off guard. It’s worth being honest about your experience rather than bluffing into territory where follow-up questions will expose gaps.

A note on practicing these out loud

Reading through question lists is genuinely useful for identifying gaps in your experience. It’s less useful for the actual delivery. The difference between knowing a good answer and saying it clearly, under mild stress, to someone who’s evaluating you, is significant – and it’s a gap that only closes with practice.

Candidates who’ve used LastRoundAI’s mock interview tool for BA prep report that their first few attempts at answering behavioral questions out loud are noticeably worse than their later ones. Not because the content changed, but because working through the question in real time reveals filler habits and vague phrasing that don’t show up when you’re just thinking through an answer in your head. The AI interview copilot can also surface follow-up probes mid-answer – the kind of questions a real interviewer would ask – which is harder to replicate with a list of questions alone.

BA interviews reward candidates who can think clearly about messy situations and communicate that thinking without getting lost in jargon. The questions above are mostly consistent across industries – financial services, tech, consulting, healthcare. What changes is the context of your examples. Use the domain you know best.

One last thing: the question I can’t answer is whether AI-assisted requirements gathering will meaningfully change what BA interviews look like over the next few years. My intuition is that stakeholder management and facilitation skills become more valuable, not less, as the templated documentation work gets easier to automate. But I’m genuinely uncertain about that.