Business Analyst Interview Questions, Answered by a Practising BA

The format varies by employer, but most BA hiring processes combine some of these:

• A screening call about your background and why you want the role
• A competency interview on documents, techniques and tools
• Scenario questions about stakeholders, changing requirements and testing
• A practical task: write user stories for a feature, map a process, or critique a requirement
• A panel with the people you'd work with, often including a developer or product owner

Across all of them, interviewers are checking the same three things: can you find the real problem, can you write it down so it can't be misread, and can you get people who disagree to a decision.

"What does a business analyst do?"
They're checking you understand the job beyond "gathering requirements". A strong answer follows the work: understand the business problem, agree what the solution must do with stakeholders, document it so it can be built and tested, and confirm at the end that it delivers the value it promised. What does a business analyst actually do? walks through a real week.

"Why business analysis?" or "How does your background prepare you?"
For career changers this is the most important question in the interview. Translate what you've done into BA language. Banking operations staff know the processes BAs are hired to fix. Customer service staff see where systems fail every day. Researchers already frame questions and read data. Name one concrete example.

"How is a BA different from a project manager or product owner?"
The project manager owns the plan, budget and timeline. The product owner owns the product's priorities and backlog. The BA owns understanding what the solution must do and making sure it meets the business need. On many teams the roles overlap, so say how you'd work with each.

"Walk me through how you'd write a BRD."
Start before the document: agree the problem, who signs off and how success is measured. Then name the main sections and finish with sign-off. Mentioning traceability to test cases sets you apart. My BRD guide has the full structure.

"How do you write a good user story?"
Give the format, then an example with acceptance criteria in Given/When/Then, including one unhappy path. Mention that stories should be small enough to deliver in a sprint and testable. See user stories and acceptance criteria for examples.

"What's the difference between functional and non-functional requirements?"
Functional requirements say what the system does: "the system must hold the investment amount on submission". Non-functional requirements say how well it does it: performance, security, availability, audit. Give one of each.

"Which elicitation techniques do you use, and when?"
Interviews for depth with one person, workshops when several teams must agree, observation when people can't describe what they do, document analysis for existing rules, prototypes when users need to see something to react to it. The point is matching the technique to the situation.

"How do you prioritise requirements?"
Name a method, such as MoSCoW or RICE, then say how you'd use it with stakeholders: prioritisation is a decision the business makes, and the BA facilitates it and records it.

"What is UAT, and what is the BA's role in it?"
User acceptance testing confirms the solution meets the business need, tested by business users. The BA usually plans it, writes or reviews test cases from the requirements, supports testers, triages defects and collects sign-off.

"How comfortable are you with SQL and APIs?"
Be honest. BAs aren't expected to build either, but being able to write a simple query with a join, and read an API's request and response, makes you far more useful in requirements and testing.

Scenario and behavioural questions are where interviews are won. Answer them with STAR: the Situation, your Task, the Actions you took, and the Result, with a number if you have one.

Here's how I'd answer "Tell me about a process you improved", using work from Access Bank:

• Situation: end-of-day GL reconciliation took analysts over eight hours every day, which delayed overnight reporting.
• Task: lead the requirements for automating it with RPA.
• Actions: mapped the as-is process in BPMN, wrote the bot specification with its exception rules, and coordinated UAT with Finance, IT and Audit.
• Result: reconciliation dropped to 45 minutes, an 89% reduction. The case study has the detail.

Prepare answers for these common scenarios. If you don't have work experience yet, use a portfolio project and say so.

For the stakeholder questions, the 4C Framework gives you a clear structure to talk through: clarity on the problem, productive conflict, documented consensus, then committed owners.

For roles in Nigerian banks and fintechs, expect questions that test whether you understand the business you'll be analysing:

• How does a payment or transfer move between banks, and where can it fail?
• What is KYC, and how does it affect onboarding requirements?
• What is maker-checker, and why do regulated processes need it?
• What does reconciliation mean, and what causes breaks?
• What do you know about open banking in Nigeria?

You don't need to be an expert. Showing that you've thought about the controls and failure points is enough.

• What does a typical project look like here, from request to go-live?
• Which documents do BAs own, and which templates do you use?
• How do BAs work with product owners and developers day to day?
• What would a successful first 90 days look like in this role?

1. Read the job description and list the five skills it stresses most. Prepare one example for each.
2. Write STAR answers for the five scenarios above, and say them out loud.
3. Prepare two portfolio pieces you can walk through: a BRD or set of user stories, and a process map.
4. Learn the company's products and the regulations that apply to them.
5. Do one mock interview with someone who'll give you honest feedback.