What to expect in a graduate BA interview
The questions usually cover three areas: BA methods and knowledge (gathering requirements, mapping processes, writing documentation), analysis and problem-solving (how you break a problem down and explain a solution), and behavioural questions (working with stakeholders, communicating, and coping when things are unclear).
Some organisations also set a case study or written exercise based on a business scenario. If you get one, structure your response clearly and spend most of it on what your findings mean for the business and what you'd do about them.
Where a BA fits
The BA sits between the people who need a change and the people who build it. In the interview, show that you can ask good questions, challenge assumptions politely, and write requirements clearly enough that both sides read them the same way.
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 know what a BA actually does, and why a project needs one?
How to answer it
A business analyst helps a project build the right thing. The work includes eliciting and documenting requirements, mapping how processes work now and how they should work after the change, keeping the business and IT talking to each other, spotting gaps and risks, and checking that what's delivered meets the original need. A good BA keeps asking why until the underlying problem is clear, instead of only writing down what stakeholders say they want.
Question 02
"What is the difference between functional and non-functional requirements?"
What they're really asking
Basic BA vocabulary. Can you explain the difference with an example?
How to answer it
Functional requirements describe what the system must do: its behaviour and functions. "The system must let users reset their password by email." Non-functional requirements describe how well it must do it, covering qualities such as performance, security, reliability and scalability. "The reset email must arrive within 30 seconds", or "The system must support 10,000 users at the same time." A project needs both. With only functional requirements, you can end up with a system that does everything it should but is too slow, or falls over when a lot of people use it.
Question 03
"What is a use case and how do you write one?"
What they're really asking
A standard way to document requirements. Can you explain it and write one?
How to answer it
A use case describes how an actor (a person, or another system) interacts with the system to reach a goal. A good one names the actor and the goal, any preconditions, the trigger that starts it, the main success flow step by step, alternative flows (other ways it can go) and exception flows (what happens when something goes wrong). Write the steps as an exchange between the actor and the system, in the words the business uses: "Customer searches for a product", then "System shows matching products". Leave out screen layouts and how the system works inside. Developers and testers can then see exactly what should happen.
Question 04
"What techniques do you use to elicit requirements from stakeholders?"
What they're really asking
Whether you can get requirements out of people in more than one way.
How to answer it
Name several techniques and say when you'd use each. Use interviews, often one-on-one, to explore one person's view in detail, and workshops to get a group to agree, or to settle conflicting views. Observation or job shadowing means watching people do the work, and it often turns up steps they'd never think to mention. Document analysis means reading existing reports, procedures and system specifications, and surveys or questionnaires let you hear from a large group quickly. People often can't describe what they need until they see something concrete, so use more than one technique, and show early drafts or mock-ups to check you've understood.
Question 05
"What is process mapping and why is it useful?"
What they're really asking
Do you know what a process map is for, as well as how to draw one?
How to answer it
A process map is a diagram of how a piece of work moves through a team or organisation from start to finish, with each step, decision and handover. Once it's drawn, people can see the bottlenecks, duplicated effort, gaps and handovers where things get dropped. A current-state ("as-is") map is worth doing early in a project, because it gives everyone the same picture of how the work is actually done, which is often different from how people think it's done. A future-state ("to-be") map then shows how the process should work after the change.
Question 06
"What is the difference between a business requirement, a functional requirement, and a technical requirement?"
What they're really asking
Whether you can work at different levels of detail, and know which suits which audience.
How to answer it
A business requirement says what the business needs to achieve and why, in business language: "We need to cut customer onboarding time by 50%." A functional requirement says what the system must do to help get there: "Customers must be able to upload identity documents through the portal." A technical requirement says how the system will do it: "Documents must be stored as PDFs of up to 10MB, encrypted at rest with AES-256." A BA spends most of their time on the first two, and works with architects and developers on the third. You could also mention that the BABOK Guide, the IIBA's guide to business analysis, groups requirements a little differently: business, stakeholder, solution (functional and non-functional) and transition requirements.
Question 07
"What is a gap analysis and when would you use one?"
What they're really asking
Do you know when a gap analysis is worth doing?
How to answer it
In a gap analysis you compare where things are now (the current state) with where they need to be (the future state). Use it when you're scoping a change program, choosing a new system, or checking whether today's processes and systems can meet new requirements. The result is a list of gaps, each with the action, investment or process change needed to close it. Do it early, before anyone has settled on a solution, so the team knows it's solving the right problem and how much has to change.
Practise your behavioural answers out loud
InterviewZap asks behavioural questions like 14–20 below, written from your CV and the job description. Answer by typing or out loud, and after each answer you'll see what was missing and a stronger way to put it.
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
A vague request. Can you ask the questions that turn it into a real requirement?
How to answer it
Don't start building it. Ask what "everything" means and, more usefully, what decisions the report will help someone make. Find out who will use it, how often, what they'll do differently once they can see it, and what a good result looks like for them. You're looking for the business need behind the request. Often "everything" turns out to mean "I can't see what's happening with X at the moment", and once you know what X is, the requirement becomes specific enough to build.
Question 09
"How would you handle conflicting requirements from different stakeholders?"
What they're really asking
Stakeholders often want different things. Can you work through that calmly?
How to answer it
Start by understanding both positions properly, and don't assume they can't both be met until you've explored them. Conflicting requirements often come from different priorities rather than a real contradiction. Bring the stakeholders together and use the shared business goal as the reference point: "Given that the goal is X, which approach gets us closer to it?" If they still disagree, take it to the project sponsor or steering committee with the trade-offs set out clearly. Write down what's agreed and send it round, because people remember spoken agreements differently.
Question 10
"How do you prioritise requirements when there are more than can be delivered in scope?"
What they're really asking
Do you have a method for deciding what makes the cut?
How to answer it
MoSCoW is a common method: Must have (without it, the solution doesn't work), Should have (important, but the solution still works without it, perhaps with a workaround), Could have (nice to have, and easy to leave out) and Won't have this time (deliberately left for later). Base the priorities on business value, risk and dependencies, not on who is most senior or loudest. As the BA, your job is to run an honest conversation about priorities so the final list reflects what the business needs.
Question 11
"How do you validate that requirements are complete and correct before development begins?"
What they're really asking
Whether you check requirements before anything gets built.
How to answer it
The BABOK Guide separates verification (is each requirement clear, consistent, complete and testable?) from validation (will the requirements deliver what the business needs?). Ways to do both include structured walkthroughs with stakeholders to confirm the requirements say what they meant, prototypes or wireframes that make requirements concrete enough to expose misunderstandings, reviews with the technical team to confirm they can be built, walking through the use cases to check every flow and unusual case is covered, and traceability, linking each requirement to a business objective to show it's still needed. The aim is to catch misunderstandings before anything is built.
Question 12
"What is user acceptance testing (UAT) and what is the BA's role in it?"
What they're really asking
Do you know what a BA does after the requirements are written?
How to answer it
UAT is when business users test the finished system against the requirements to confirm it does what they need before it goes live. The BA's part can include writing test scenarios from the requirements and use cases, helping testers understand what they're checking and how to report problems, sorting reported issues into real defects and change requests, and organising sign-off. Testers often find requirements that were misunderstood or never spelled out, so a good BA also learns from it how to write clearer requirements next time.
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 learn an unfamiliar area quickly and still produce something useful?
How to answer it
Start by reading what already exists: procedures, process guides, org charts. Then talk to the people who do the work, not only their managers, because frontline staff often describe the process quite differently. Watch the process happen if you can. Draft a map and check it with people in different roles. Pay attention to where their versions disagree, because that's often where the problems are. You don't need to know the area already, as long as you ask good questions and check what you've heard.
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
How you get useful information from people who are busy, wary or uninterested.
How to answer it
Use a real example: a stakeholder who was too busy, resisted the change, or was protective of their area. Say what you did about it, such as changing how you communicated, picking a better time, explaining that you were there to help rather than to check up on them, or starting with easy questions to build trust. Show that you adjusted to the person instead of expecting them to work on your terms.
Question 15
"Describe a time you identified a problem that wasn't in your original brief."
What they're really asking
If you find a bigger problem than the one you were asked to look at, will you raise it?
How to answer it
Pick a time your analysis turned up a deeper problem than the one in your brief. Explain how you decided to raise it: what evidence you had, who you told, and how you put it. Make it clear you raised it to help the project, because fixing the cause would work better than the narrow fix you'd been asked for, and say what happened next.
Question 16
"Tell me about a time you had to explain a complex concept to a non-technical stakeholder."
What they're really asking
Can you explain technical ideas in business terms?
How to answer it
Say what the concept was, who you were explaining it to, and how you adapted your explanation. Things that help: comparing it to something familiar, talking about what it means for the business rather than how it works, drawing a diagram, and asking the person to explain it back to you in their own words. Your explanation worked if they understood it well enough to make the decision they needed to make.
Question 17
"Describe a time the requirements changed a lot partway through a project. How did you manage it?"
What they're really asking
Whether you can handle a change without throwing the project off course.
How to answer it
Describe the change, what caused it, and how you handled it: assessing the effect on scope, time and cost, explaining that effect to the stakeholders, and taking it through the project's change process (a change request, or the backlog on an agile team) rather than quietly absorbing it. Say plainly that you expect requirements to change, and that your job is to make sure each change is assessed, agreed and written down.
Question 18
"Tell me about a time you had to challenge a stakeholder's assumption or request."
What they're really asking
Can you question a request without getting someone offside?
How to answer it
Explain the assumption or request, why you thought it was worth questioning, and how you raised it. One way to open: "Can you help me understand the business need behind this? I want to make sure we're solving the right problem." Put that way, the challenge comes across as wanting to help, which is easier to hear than disagreement. Then say whether the stakeholder changed their view, and how it turned out.
Question 19
"How do you manage your own workload when you're supporting multiple projects simultaneously?"
What they're really asking
BAs often work on more than one project at a time. Can you keep track without dropping things?
How to answer it
Talk about how you keep on top of things: one view of what's due when across every project, telling people early when you have too much on, asking your manager to help prioritise when two things really do clash, and writing things down so you're not carrying everything in your head. When you're stretched, it's easy to do a quick, shallow job on everything. Show that you know this, and explain how you decide where to go deep.
Question 20
"Do you have any questions for us?"
What they're really asking
Are you interested in this job and this organisation?
How to answer it
Questions you could ask: "Do BAs here stay with a project from requirements through to UAT, or hand over at certain points?" / "How much of the team's work is business change, and how much is IT?" / "How do the BAs work with the product and delivery teams?" / "What would a new graduate BA work on in their first three months?"
If you haven't worked as a BA
Think about where you've done similar work already: writing down how something gets done, collecting information from different people to make a decision, or noticing a gap between what was happening and what should have been. Any of these can be a good example in a BA interview, even if nobody called it business analysis at the time.