Business analyst interview questions with model answers

How to use these questions and answers

Interviewers for business analyst roles are usually testing a small number of things: whether you understand the work, whether you think clearly under questions, whether you can communicate and whether you will fit the team. The specific questions vary, but they fall into repeatable groups, which is why preparing by group works better than memorising a list.

The model answers below are examples of structure and reasoning, not scripts. Copy the shape, not the words. An interviewer can tell when an answer is recited, and a story you invent will fall apart under a follow-up question. Replace every example with something that really happened to you, or clearly present it as practice or a hypothetical. Our free interview preparation guide offers a worksheet for building your own answers.

A method for any question

1. Answer first. Give the headline in one sentence.
2. Explain briefly. Say why, in plain language.
3. Give an example. Use a real or clearly labelled practice example.
4. Note a limit or trade-off. It shows maturity.
5. Stop. Invite follow-up rather than talking for five minutes.

For behavioural questions, the STAR pattern helps: Situation, Task, Action, Result. Keep the situation short and spend most of the time on what you did and what you learned. If you do not have a measured result, describe the outcome honestly without inventing numbers.

Role and fundamentals questions

1. What is business analysis, and what does a business analyst do?

Model answer: "Business analysis is understanding what an organisation needs and describing the change that would meet that need. As an analyst I investigate the problem, work with stakeholders to gather needs, turn them into clear requirements the team can build and test, and stay involved through testing and release. The outcome is that the team builds the right thing." Detail is in what is business analysis.

2. How is a business analyst different from a project manager?

Model answer: "The project manager is accountable for delivering on time and within budget: plan, resources, risks. The analyst is accountable for making sure the right solution is defined: the problem, the requirements and the acceptance. They work as a pair, and on small projects one person may do both." See business analyst vs project manager.

3. How is it different from a data analyst?

Model answer: "A data analyst mainly examines data to find patterns and answer questions. A business analyst mainly defines needs and changes, using data as evidence. I use SQL and spreadsheets to check claims, but my deliverables are usually requirements, models and acceptance criteria." See business analyst vs data analyst.

4. Why do you want to be a business analyst?

Model answer: "I enjoy working out what is really going wrong and helping people agree on a clear fix. In my current role I noticed I was already doing this, for example when I mapped why customer queries repeated. I want to do it full time and keep learning the technical side." Use your own true reason. Avoid generic phrases and avoid claiming a passion you cannot illustrate.

5. What are the main stages of a project from the analyst's point of view?

Model answer: "Understand the problem and build a case, identify stakeholders, gather and analyse requirements, specify and confirm them, support design and build, support testing and acceptance, help with release and then check that the benefits arrived. In agile teams these steps repeat in short cycles."

6. What is the difference between agile and waterfall, and how does your work change?

Model answer: "In waterfall, phases are sequential and documents are detailed and approved up front, so I invest heavily in a complete specification. In agile, requirements emerge in small increments, so I work continuously with the team, refine the backlog and write small stories with acceptance criteria. The thinking is the same; the rhythm and the documents differ."

Requirements and stakeholder questions

7. How do you gather requirements?

Model answer: "I start with the goal and the stakeholders, then choose techniques to match: interviews for individual detail, workshops to resolve disagreements, observation to see real behaviour, and document and data review to check what people tell me. I confirm what I heard in writing." See elicitation techniques.

8. What makes a good requirement?

Model answer: "It is clear, necessary, consistent with others and testable. A tester should be able to say pass or fail. For example, 'show results quickly' is weak, while 'show search results within three seconds for ninety percent of searches' is testable."

9. What is the difference between functional and non-functional requirements?

Model answer: "Functional requirements describe what the system does, such as rejecting a transfer that exceeds the balance. Non-functional requirements describe how well it does it: speed, security, availability, accessibility. Both need to be testable." See BRD, FRD and SRS.

10. Two stakeholders give you conflicting requirements. What do you do?

Model answer: "First I check that the conflict is real, since people often mean the same thing in different words. If it is real, I clarify the underlying goal behind each, show the impact of each option with evidence, and bring the stakeholders together. If they still disagree, I escalate to the person accountable for the decision, and I record the outcome."

11. How do you handle a stakeholder who does not respond or does not attend?

Model answer: "I find out why: workload, unclear value or a different priority. I make it easy with a short, specific request and a deadline, offer a different format such as ten minutes by phone, and involve their manager if the input is essential. I document what I assumed if I must proceed without them." See stakeholder analysis and RACI.

12. How do you prioritise requirements?

Model answer: "I agree criteria with the sponsor, such as value, risk, effort and dependency, then use a technique like MoSCoW to separate musts from nice-to-haves. Prioritisation is the product owner's or sponsor's decision, so my job is to supply clear information and make trade-offs visible." See MoSCoW prioritisation.

13. What do you do when requirements change late?

Model answer: "I assess the impact on scope, time, cost and other requirements, using traceability to see what is affected, then take it to the decision maker with options. Change is normal; the risk is untracked change. I update the documents and tell everyone who is affected."

14. Write a user story for a customer who wants to reset a password.

Model answer: "As a registered customer, I want to reset my password by email, so that I can get back into my account if I forget it. Acceptance criteria: a reset link is sent only to the registered email address; the link expires after a stated time; an expired link shows a clear message and offers a new one; the new password must meet the stated rules; and old links stop working after a reset." See how to write user stories.

15. What are acceptance criteria and how do you write them?

Model answer: "They are specific conditions a story must meet to be accepted. I write them as a checklist or in Given/When/Then form, cover the normal case, errors and boundaries, and make each pass or fail. I review them with a developer and a tester." See acceptance criteria and Gherkin examples.

Process, data and technical questions

16. How do you document a process?

Model answer: "I first observe and interview to capture the AS-IS process as it really runs, including workarounds. I draw it as a flow with lanes for each role, mark handoffs and pain points, then confirm it with the people who do the work. For the TO-BE I show what changes." See BPMN for beginners and AS-IS versus TO-BE.

17. What is a gap analysis?

Model answer: "It compares the current state with the desired state and lists the differences, with the impact of each and an action to close it. For example, if we want same-day loan decisions and the scoring is automatic but document checks are manual, the manual check is a gap." See gap analysis template and example.

18. Do you know SQL? What have you used it for?

Model answer: "Yes, at a working level: SELECT with filters, joins, GROUP BY and basic checks. I have used it to count records and check that a report matched the source. I'm clear about my limits, and I'd ask a developer for anything complex." Be truthful about your level. See SQL for business analysts.

19. What is the difference between INNER JOIN and LEFT JOIN?

Model answer: "INNER JOIN returns only rows with a match in both tables. LEFT JOIN returns every row from the left table, with empty values where there is no match. If I need every customer, including those with no orders, I use LEFT JOIN." See SQL joins explained.

20. Here is a table of orders. How would you find the number of orders per customer?

Model answer: "SELECT customer_id, COUNT(*) AS order_count FROM orders GROUP BY customer_id; I would also check for duplicates and decide whether cancelled orders should be counted, because the business definition matters as much as the query." The follow-up about definitions is what interviewers want to hear.

21. What is an API and why does it matter to an analyst?

Model answer: "An API is a defined way for one system to request data or actions from another. It matters because many requirements are really about what data moves between systems, in which format and what happens on failure. I document endpoints, fields and error handling." See APIs for business analysts.

22. What do HTTP status codes 200, 400, 401, 404 and 500 mean?

Model answer: "200 means success. 400 means the request was malformed or invalid. 401 means the caller is not authenticated. 404 means the thing was not found. 500 means a server error. In requirements I specify the expected code for each situation so testers can check it." See REST status codes for business analysts.

23. How would you decide which KPIs belong on a dashboard?

Model answer: "I ask who uses it and which decisions they make, then choose a few measures tied to the goal, define each precisely with a formula and source, and test that users can read the message quickly. A KPI without a clear definition causes arguments later." See KPI versus metric.

Delivery, testing and agile questions

24. What is UAT and what is your role in it?

Model answer: "User acceptance testing is where business users check the solution supports real work before release. I help prepare scenarios from the acceptance criteria, support the testers, log and clarify defects, and help the business decide whether to sign off." See the UAT guide.

25. What is a requirements traceability matrix?

Model answer: "A table that links each requirement to its tests and other artefacts, so I can show every requirement is tested and every test comes from a requirement. It also helps with impact analysis when something changes." See the traceability matrix guide and our worked traceability example.

26. What does a business analyst do in a Scrum team?

Model answer: "I work with the product owner to keep the backlog clear, write and refine stories with acceptance criteria, join planning and refinement, answer questions during the sprint and help check work against the criteria. In some teams I act as the product owner." See the agile BA and product owner guide.

27. A developer says your requirement is unclear. How do you respond?

Model answer: "I treat it as useful feedback. I ask what exactly is unclear, give an example to clarify, then rewrite the requirement so the next reader does not have the same problem, and I update the story and acceptance criteria."

Behavioural questions and questions to ask them

28. Tell me about a time you had to influence someone without authority.

Model answer shape (STAR): Situation: "A team lead resisted changing how handovers were recorded." Task: "I needed agreement because the report depended on it." Action: "I listened to her concerns, found that she worried about extra typing, and proposed a shorter form. I showed her the time lost in rework using a small sample." Result: "She agreed to a trial and the rework reduced." Replace this with your own true story, and describe the result honestly even if it is modest.

29. Describe a mistake you made and what you learned.

Model answer shape: choose a real, moderate mistake, such as assuming a term meant the same thing to two teams. Explain what happened, what you did to fix it, and what you now do differently, for example confirming definitions in a glossary at the start. Avoid answers that disguise a strength as a flaw.

30. What would you do in your first 30 days?

Model answer: "Listen and learn: meet stakeholders, understand the domain vocabulary and the current process, read existing documents, learn the tools, and find one small piece of work where I can help early. I would avoid proposing big changes before I understand the context."

Questions you can ask them

• How are requirements captured and approved here, and what tools does the team use?
• How do analysts work with product owners, developers and testers?
• What does success look like in the first six months?
• What is the hardest part of the role right now?
• How does the team learn from projects after release?

Practise before the day

Practise aloud, ideally with another person who interrupts with follow-ups. Use our free interview preparation guide, review the vocabulary in the glossary and attempt the scenarios in the BA Lab, where each task asks you to explain your reasoning. Treat all of this as practice. No guide, including this one, can promise a particular interview result, but preparing by group makes unseen questions much less frightening.

If you are early in your journey, read how to become a business analyst with no experience and how to build a portfolio so you have real examples to draw on.

Frequently asked questions