Business Analyst interview questions (India, 2026): what to ask and what to listen for

12 interview questions for a Business Analyst role, grouped by what each round should establish, each with what a strong answer contains, plus a five-point scorecard so every interviewer rates the same things.

Last updated 3 September 2026. Competitor pricing and plan limits are re-verified against each vendor’s own pages.

Interviewing a Business Analyst well means asking about work the candidate has actually done, listening for specifics, and scoring every candidate on the same five criteria. The questions below are grouped by what they establish; each one comes with what a good answer contains, which is the part most question lists leave out.

A Business Analyst in an Indian company works out what a process or a system should do before anyone builds or changes it — gathering requirements from the people who do the work, documenting current and future processes, writing specifications, and checking that what was delivered solves the original problem.

Use the screening questions on the job description page to filter before anyone reaches an interview, and the scorecard at the end so a panel can compare candidates rather than impressions.

Changes they have made

Tell me about a process you changed. What was broken, how did you find out, what did you specify, who built it, and what improved by how much?: A strong answer: A full arc from evidence to outcome with a number. Analysts who have owned a change describe the resistance and the measurement, not just the document.
Show me a specification you wrote. Where did the builders come back with questions, and what did you change about how you write?: A strong answer: Clear structure, acceptance criteria, edge cases, scope boundaries — and a learning loop.
Tell me about a requirement that was wrong — the business asked for X and needed Y. How did you find out and what did you do?: A strong answer: Observation and questioning beyond what was asked, and the diplomacy to redirect a stakeholder.
Describe a rollout that went badly. What happened and what would you do differently?: A strong answer: Honesty about adoption failures — training, timing, a missed edge case — and a concrete change.

Analysis and craft

Here is a process from our business [describe one with a problem]. How would you investigate it in the first week, and what would you produce?: A strong answer: Talks to the people who do it, watches it, pulls the data, maps the current state with the problems evidenced — before proposing anything.
How do you size a problem before deciding to fix it?: A strong answer: Frequency, cost, impact on customers or cash — with data — and the judgement to leave small problems alone.
Write the acceptance criteria for [a small feature or process change] right now.: A strong answer: Testable, specific, covers the failure cases, and states what is out of scope.
When would you recommend a no-code tool, an ERP configuration, or custom engineering for a change?: A strong answer: Cost, speed, control and longevity weighed with examples — not a default to any one.

Stakeholders and fit

Two department heads disagree about how a shared process should work. What do you do?: A strong answer: Grounds the discussion in the customer and the data, finds the underlying interests, proposes a design that serves both, and escalates cleanly if needed.
How do you get busy operational staff to give you their time and tell you the truth about how the work is really done?: A strong answer: Respect for their expertise, observation rather than interrogation, and showing them the benefit.
How do you run user acceptance testing so it actually finds problems?: A strong answer: Real users, real scenarios, real data, a structured script, and defects tracked to closure before go-live.
Where do you want this role to lead — product, operations leadership, a domain — and does this company offer it?: A strong answer: A realistic direction; business analysts in operating companies often grow into product or operations roles.

Scorecard for Business Analyst interviews

Score each candidate on these five criteria, one to four, straight after the interview and before talking to the other interviewers. Written scores taken independently are what make a panel decision defensible; a discussion first produces one opinion with several signatures.

Outcome ownership: changed a process and measured the improvement.
Specification craft: clear, testable, complete, with a learning loop.
Investigation method: observes, questions and sizes with data before proposing.
Solution judgement: chooses no-code, configuration or engineering with reasons.
Stakeholder handling: disagreements, busy staff and testing managed well.

Screen before you interview

Most Business Analyst interviews that go badly were avoidable at the application stage. The job description template for this role carries five screening questions that settle the deal-breakers — notice period, location, the one or two hard requirements — before anyone books a slot.

Have you specified a process or system change that was implemented and measurably improved a business outcome? — knockout
How many years of business or process analysis experience do you have in an operating company or product team (not IT services delivery)? — knockout
Have you administered or configured a business system — an ERP, CRM or helpdesk — yourself? — for context
What is your current notice period, in days? — for context

Questions, answered straight

What is the best Business Analyst interview question?

Ask about a process they changed — what was broken, how they found out, what they specified, who built it, what improved by how much. The full arc with a number is what separates analysts who change things from those who write documents.

Should a Business Analyst interview include a case?

Yes, on a real process from your business with a known problem: how would they investigate it in the first week and what would they produce. Analysts who start by talking to the people who do the work and pulling the data, before proposing, are the ones you want.

How do I assess specification quality?

Ask them to write acceptance criteria for a small change on the spot, and to show a specification they wrote with the questions builders came back with. Testable, specific criteria that cover failure cases, plus evidence of learning from ambiguity, are what you are looking for.