What to expect in a graduate BA interview
Business analyst interviews typically span three areas: BA methodology and knowledge (requirements gathering, process mapping, documentation), analytical and problem-solving questions (how you break down complex problems and communicate solutions), and behavioural questions (stakeholder management, communication, and handling ambiguity).
Some organisations also include a case study or written exercise — a business scenario you're asked to analyse and present recommendations for. If you get one, structure your response clearly and focus on the "so what" rather than just the analysis.
What great BA candidates demonstrate
The BA role sits between the business and IT. The best candidates show they can ask the right questions, challenge assumptions politely, and translate complex requirements into clear, unambiguous language that both sides can work from. Communication is the core skill.
BA methodology and knowledge
Questions 1–7 · Methodology & Knowledge
Question 01
"What is the role of a business analyst in a project?"
What they're really asking
Do you have a clear understanding of what a BA actually does — and the value they add?
How to answer it
A business analyst bridges the gap between business stakeholders and technical teams — ensuring that what gets built actually solves the right business problem. Core responsibilities: eliciting and documenting requirements, modelling current and future-state processes, facilitating communication between business and IT, identifying gaps and risks, and validating that delivered solutions meet the original need. The BA is often the person who asks "but why?" until the real problem is surfaced — not just the one who documents what stakeholders say they want.
Question 02
"What is the difference between functional and non-functional requirements?"
What they're really asking
Core BA vocabulary. You need to know this cold.
How to answer it
Functional requirements describe what a system must do — the specific behaviours and functions. "The system must allow users to reset their password via email." Non-functional requirements describe how the system must perform — quality attributes like performance, security, reliability, and scalability. "The password reset email must be delivered within 30 seconds" or "the system must support 10,000 concurrent users." Both are essential — ignoring non-functional requirements is one of the most common causes of systems that technically work but fail in production.
Question 03
"What is a use case and how do you write one?"
What they're really asking
A fundamental BA documentation technique. Can you explain and apply it?
How to answer it
A use case describes how a user (actor) interacts with a system to achieve a specific goal. A well-written use case includes: the actor, the trigger (what initiates the interaction), the main success flow (step-by-step), alternative flows (what happens if something different occurs), and exception flows (what happens if something goes wrong). Good use cases are written from the user's perspective, not the system's — "User searches for a product" not "System displays search results." They're valuable because they make requirements concrete and testable.
Question 04
"What techniques do you use to elicit requirements from stakeholders?"
What they're really asking
Requirements elicitation is the most important BA skill. Do you have a varied toolkit?
How to answer it
Describe several techniques and when you'd use each: interviews (one-on-one, good for detailed exploration of individual perspectives), workshops (group sessions, good for aligning multiple stakeholders and resolving conflicts), observation/job shadowing (watching users perform tasks — often reveals requirements that people can't articulate), document analysis (reviewing existing reports, process docs, and system specifications), surveys (scalable for gathering information across a large group). The key insight: stakeholders often don't know what they want until they see what they don't want — good elicitation uses multiple techniques to surface the real need.
Question 05
"What is process mapping and why is it useful?"
What they're really asking
Process analysis is a core BA skill — do you understand the purpose, not just the technique?
How to answer it
Process mapping is the visual documentation of how work flows through a system or organisation — from inputs to outputs, showing each step, decision point, and handoff. It's useful because it makes invisible processes visible: it reveals bottlenecks, redundancies, gaps, and handoff failures that nobody has formally acknowledged. A current-state ("as-is") process map is often the most valuable artefact a BA can produce early in a project — it creates a shared understanding of how things actually work, not how people think they work. Future-state ("to-be") maps then show the intended improvement.
Question 06
"What is the difference between a business requirement, a functional requirement, and a technical requirement?"
What they're really asking
Can you operate at different levels of abstraction — and know which level is appropriate for which audience?
How to answer it
A business requirement describes what the business needs to achieve and why — written in business language, not technical terms. "We need to reduce customer onboarding time by 50%." A functional requirement describes what the system must do to meet the business requirement. "The system must allow customers to upload identity documents directly through the portal." A technical requirement describes how the system will implement it. "Documents must be stored as PDFs, maximum 10MB, encrypted at rest using AES-256." The BA typically works primarily at the first two levels and collaborates with architects and developers on the third.
Question 07
"What is a gap analysis and when would you use one?"
What they're really asking
A standard BA technique — do you know it and can you explain when it adds value?
How to answer it
A gap analysis compares the current state (where you are) against the desired future state (where you want to be) to identify what needs to change. It's useful when scoping a change programme, selecting a system, or assessing whether current capabilities meet new requirements. The output is a list of gaps and the actions, investments, or process changes needed to close them. Gap analysis is most valuable early in a project — before solutions are proposed — to make sure the team is solving the right problem and understands the scale of change required.
Practise these BA questions out loud
Business analyst interviews reward candidates who can explain their thinking clearly and concisely. InterviewZap helps you practise with real questions and instant feedback on your answers.
Start Practising Free →No credit card. Free to start.
Analytical and problem-solving questions
Questions 8–13 · Analytical Thinking
Question 08
"A stakeholder says 'I want a report that shows everything.' How do you handle that?"
What they're really asking
The classic vague requirements scenario. Can you ask the right questions to get to a real requirement?
How to answer it
Don't build the report. Instead, ask questions to uncover what "everything" actually means and — more importantly — what decisions the report will inform. Who will use it? How often? What will they do differently based on what they see? What does "good" look like for them? The goal is to surface the underlying business need behind the stated request. Almost always, "I want everything" actually means "I feel like I'm missing visibility into X" — and once you understand that, the requirement becomes specific and buildable.
Question 09
"How would you handle conflicting requirements from different stakeholders?"
What they're really asking
Stakeholder conflict is a daily reality in BA work. Do you have a constructive approach?
How to answer it
Start by understanding both positions fully — don't assume they're incompatible before you've explored them. Often conflicting requirements reflect different priorities rather than genuine contradictions. Bring stakeholders together with the shared business objective as the reference point: "Given that the goal is X, which approach better serves that?" If genuine conflict remains, escalate to the project sponsor or steering group with a clear articulation of the trade-offs. Document whatever is agreed — verbal alignment that isn't written down has a habit of being forgotten or misremembered.
Question 10
"How do you prioritise requirements when there are more than can be delivered in scope?"
What they're really asking
Prioritisation is one of the most valuable BA skills. Do you have a framework?
How to answer it
Describe a framework — MoSCoW is the most common in BA work: Must have (without this, the solution fails), Should have (high value but not critical), Could have (nice to have, low risk to exclude), Won't have this time (explicitly deferred). The key is that prioritisation should be driven by business value and risk, not stakeholder seniority or loudness. The BA's role is to facilitate honest prioritisation conversations, not just capture whatever the loudest person in the room says.
Question 11
"How do you validate that requirements are complete and correct before development begins?"
What they're really asking
Do you understand that poorly validated requirements are one of the primary causes of project failure?
How to answer it
Multiple validation techniques: structured walkthroughs with stakeholders to confirm requirements match intent, prototyping or wireframes to make abstract requirements concrete and surface misunderstandings early, requirement reviews with the technical team to confirm feasibility, use case testing to check that requirements cover all flows and edge cases, and traceability — mapping each requirement back to a business objective to confirm it's still necessary. The goal: catch misunderstandings before they're built, not after.
Question 12
"What is user acceptance testing (UAT) and what is the BA's role in it?"
What they're really asking
Do you understand the full project lifecycle — not just the requirements phase?
How to answer it
UAT is the phase where business stakeholders test a built system against the original requirements to confirm it meets their needs before it goes live. The BA's role in UAT: create test scenarios based on requirements and use cases, help stakeholders understand what they're testing and how to report issues, triage defects to determine whether they're genuine bugs or change requests, and facilitate sign-off. UAT often surfaces requirements that were misunderstood or incompletely specified — a good BA treats UAT feedback as a requirements quality signal, not just a list of things to fix.
Question 13
"How would you approach mapping the current state of a complex business process you know nothing about?"
What they're really asking
Can you get up to speed in an unfamiliar domain and produce useful analysis quickly?
How to answer it
Start by reading everything available — existing documentation, process guides, org charts. Then interview the people who actually do the work (not just managers who describe how they think it works — frontline staff often have very different perspectives). Shadow the process if possible. Build a draft map and validate it with multiple stakeholders across different roles — the discrepancies between their versions are often the most important findings. Curiosity and structured listening are the most important skills here — domain knowledge can be acquired, but the habit of asking good questions can't be faked.
Behavioural questions
Use the STAR method for these.
Questions 14–20 · Behavioural
Question 14
"Tell me about a time you had to gather information from someone who was difficult to engage."
What they're really asking
BA work requires building relationships with people who are busy, resistant, or sceptical. Can you navigate that?
How to answer it
Describe a real example — a stakeholder who was too busy, resistant to change, or protective of their domain. Walk through how you approached it: adapting your communication style, finding the right moment, demonstrating that you were there to help not to audit them, or starting with lower-stakes questions to build trust. The key message: you adjust your approach based on the person, rather than expecting everyone to engage on your terms.
Question 15
"Describe a time you identified a problem that wasn't in your original brief."
What they're really asking
Good BAs often find the real problem is different from the one they were asked to solve. Do you have the initiative and judgment to raise that?
How to answer it
Describe a situation where your analysis revealed a more fundamental issue than the one you were originally tasked with. Walk through how you decided to raise it — with what evidence, to whom, and how. Show that you did it constructively, not as a way of derailing the project, but because addressing the root cause would produce a much better outcome than the narrow fix originally requested.
Question 16
"Tell me about a time you had to explain a complex concept to a non-technical stakeholder."
What they're really asking
Translation between technical and business language is the BA's core value. Can you do it well?
How to answer it
Describe the concept, the audience, and how you adapted your explanation. Good techniques: analogies to familiar concepts, focusing on the business implication rather than the technical mechanism, using visual aids, and checking comprehension by asking the person to summarise their understanding back to you. The goal of a BA explanation is always a decision or action — not just comprehension. Did they understand it well enough to make the decision that was needed?
Question 17
"Describe a time requirements changed significantly mid-project. How did you manage it?"
What they're really asking
Changing requirements are a reality. Can you manage them professionally without derailing the project?
How to answer it
Describe the change, what caused it, and how you handled it: assessing the impact on scope, timeline, and cost; communicating the impact clearly to all stakeholders; going through a formal change control process rather than just absorbing it quietly. The key message: scope changes aren't the problem — undocumented, unmanaged scope changes are. A BA who treats every change as a formal decision point protects both the project and the stakeholders.
Question 18
"Tell me about a time you had to challenge a stakeholder's assumption or request."
What they're really asking
Good BAs don't just capture requirements — they test them. Can you push back constructively?
How to answer it
Describe the assumption or request, why you thought it was worth challenging, and how you raised it. The best approach: "Can you help me understand the business need behind this? I want to make sure we're solving the right problem." This positions the challenge as a desire to help, not a disagreement. Walk through whether the stakeholder updated their view, and what the outcome was.
Question 19
"How do you manage your own workload when you're supporting multiple projects simultaneously?"
What they're really asking
BAs are frequently spread across multiple workstreams. Can you manage that without dropping things?
How to answer it
Describe your approach: maintaining a clear view of what's due when across all projects, communicating proactively when capacity is stretched, asking for help prioritising when two things are genuinely in conflict, and using structured documentation to avoid carrying context in your head. The biggest risk for a stretched BA is producing shallow analysis across everything rather than deep analysis where it matters. Show you're aware of that risk and have strategies to manage it.
Question 20
"Do you have any questions for us?"
What they're really asking
Are you genuinely interested in this role and organisation?
How to answer it
Strong questions for BA roles: "How embedded are BAs in project teams here — do they stay with a project from requirements through to UAT, or hand off at certain points?" / "What's the balance between business change and IT-focused work in this team?" / "How does the BA function interact with the product and delivery teams?" / "What does the ramp-up period look like for a new grad BA — what would I be working on in my first three months?"
One more thing
If you don't have formal BA experience, think broadly about where you've done BA-adjacent work: documenting a process, gathering information from different people to make a decision, identifying a gap between what was happening and what should be happening. The skills are more transferable than the job title suggests.