Business Analyst Interview Questions in India (2026)

Business Analyst roles are active across India right now. Knok's job radar (as of July 2026) shows 398 open Business Analyst positions, with strong clusters in Bangalore (53 openings), Delhi (48), Mumbai (24), Hyderabad (21), Pune (21), and Chennai (16). Whether you are targeting your first BA role or stepping into a senior position, interviews follow a consistent pattern: they test your understanding of requirements and processes, your ability to handle messy real-world scenarios, and how you work with people under pressure. This guide covers the questions you are most likely to face, model answers, and a realistic preparation plan.

1. Design a rate limiter for an API serving millions of requests per day.
2. Explain a production incident you debugged. What was root cause?
3. How do you approach system design for high availability?
4. Walk through a code review where you caught a serious bug.
5. Trade-offs between SQL and NoSQL for a payments ledger.
6. How do you estimate task complexity for a sprint?

Here are three worked answers. For scenario and behavioural questions, structure matters as much as content.

Q: What is the difference between a BRD and an FRD?

A BRD captures what the business needs: the problem, the goal, and the expected outcome, written in business language for stakeholders and sponsors. An FRD takes those business needs and translates them into what the system must do, written in more precise language for developers and testers. Think of a BRD as 'we need customers to be able to check their order status at any time' and the FRD as the specific screens, inputs, outputs, and logic that make that happen. In practice, some organisations combine them into a single document, especially on smaller Agile projects where user stories replace formal specs.

Q: A key stakeholder keeps changing requirements after sign-off. What do you do?

First, I do not treat it as a conflict. I schedule a focused conversation to understand what has changed: is it new business information, a shift in priorities, or a misunderstanding of what was signed off? Once I understand the root cause, I document the proposed change formally and walk the stakeholder through the impact on timeline, scope, and the team. If the change is genuinely needed, I raise a change request through the agreed process and get sign-off from all affected parties before anything moves to development. The goal is to make the cost of changing requirements visible, not to block change.

Q: Describe a project where you faced scope creep. What did you do? (STAR answer)

Situation: I was the lead BA on a customer portal project. Mid-sprint, the marketing team requested a new campaign banner feature that was not in the original scope, and the product owner initially agreed without consulting the delivery team.

Task: My responsibility was to protect the sprint commitments while still taking the request seriously.

Action: I put together a one-page impact note showing which existing stories would be delayed if we absorbed the new feature immediately. I then facilitated a short meeting between marketing, the product owner, and the tech lead. We agreed to add the feature to the backlog, prioritise it for the next sprint, and keep the current sprint intact.

Result: The sprint delivered on time, and the banner feature shipped in the following sprint with proper requirements and QA sign-off. The product owner later said the impact note became a standard template the team used going forward.

STAR for behavioural questions: 20% situation, 10% task, 50% action, 20% result with numbers.

CIRCLES for product cases (PM): Comprehend, Identify customer, Report needs, Cut through prioritisation, List solutions, Evaluate trade-offs, Summarise recommendation.

For system design (engineering): clarify scale (DAU, QPS), draw high-level boxes, deep-dive one component, discuss failure modes and monitoring.

Signals that move Business Analyst candidates forward in India:
- Ownership of outcomes, not tasks
- Comfort with ambiguity and incomplete data
- Collaboration with cross-functional partners
- Understanding of India-specific constraints (UPI, logistics, multilingual users, price sensitivity)
- Realistic salary expectations aligned with level

Three weeks is enough time to prepare well if you are consistent.

Week 1: Build your foundation
Start by reviewing core concepts: requirements types, SDLC methodologies, and the BA toolkit (BRD, FRD, user stories, use cases). Pick one process modelling approach, swimlane diagrams are a good starting point, and practice drawing a simple process from your own work experience. Revise SQL basics: you should be comfortable writing a query with a JOIN and a GROUP BY from scratch.

Week 2: Practice scenario and behavioural questions
Work through the scenario-based questions in this guide. For each one, write down your answer in bullet points before you speak it aloud. Record yourself if you can. For behavioural questions, prepare four to six STAR stories from your past work that can flex across different questions (scope creep, stakeholder conflict, project failure, cross-team collaboration). One strong story told well beats several vague ones.

Week 3: Mock interviews and company research
Ask a friend or colleague to run a mock interview using the questions in this guide. If you cannot find a partner, record yourself answering questions on camera and review the footage critically. Spend time researching the company: their industry, their products, and the kind of BA work they do (internal systems, customer-facing products, data projects). Tailor at least one answer per round to show you understand their context. Review your resume line by line so you can speak fluently about every project listed.

On the day
Arrive (or log in) a few minutes early. Bring a notepad. It is completely fine to ask for a moment to think before answering a scenario question. Structured, calm answers beat rapid, scattered ones every time.

• Rambling without a clear result metric
• Badmouthing previous employers
• Quoting global salary data without India context
• Ignoring the 'why this company' question
• Over-indexing on frameworks without showing real shipped work

Questions in Business Analyst interviews broadly fall into three buckets. Here they are, grouped by theme.

Fundamentals

1. What is the role of a Business Analyst, and how would you explain it to a non-technical stakeholder?
2. What is the difference between a BRD (Business Requirements Document) and an FRD (Functional Requirements Document)?
3. How do you distinguish between functional and non-functional requirements? Give one example of each.
4. What SDLC methodologies have you worked with, and which suits BA work best in your view?
5. How do you handle requirements that are vague or incomplete at the start of a project?
6. What tools do you use for requirements management, process mapping, or project documentation?

Scenario-based

1. A key stakeholder keeps changing requirements after the sign-off. What steps do you take?
2. The development team says a requirement is not technically feasible. How do you respond?
3. Two departments give you conflicting requirements for the same feature. How do you resolve this?
4. You have joined a project midway and the existing documentation is outdated. What is your first move?
5. Walk me through how you would conduct a gap analysis for a system that needs to be replaced.
6. How do you verify that requirements are testable before handing them over to QA?

Behavioural

1. Tell me about a time you used data to convince a stakeholder to change their position.
2. Describe a project where you faced scope creep. What did you do?
3. Give an example of a project that did not go as planned. What did you learn from it?
4. How do you manage your workload when you are contributing to multiple projects at the same time?

Focus your revision on these areas. Candidates report that gaps here are what typically cause rejections.

Requirements and documentation
Requirements elicitation techniques: stakeholder interviews, workshops, surveys, and observation. The difference between business, functional, and non-functional requirements. BRD, FRD, and user story formats. Writing clear, testable acceptance criteria.

Process and modelling
Flowcharts, swimlane diagrams, and basic BPMN notation. Use case diagrams and activity diagrams from UML. As-is vs to-be mapping and gap analysis methodology.

SDLC methodologies
Agile and Scrum: user stories, epics, sprint planning, backlog grooming, and the BA's role in each ceremony. Waterfall and hybrid approaches. Knowing when to apply which methodology is a common interview topic.

Data and tools
SQL basics: SELECT, JOINs, GROUP BY, and WHERE clauses. Many BA roles in India, especially in BFSI and product companies, include a SQL round. Excel for data analysis and pivot tables. Familiarity with Power BI or Tableau is a bonus. Wireframing with Figma, Balsamiq, or Miro.

Collaboration tools
JIRA for backlog management and Confluence for documentation are commonly cited in job descriptions. Knowledge of Confluence templates for requirements docs is worth brushing up on.

Soft skills under the hood
Stakeholder management, facilitation techniques, and conflict resolution. Interviewers often use scenario questions to test these indirectly, so prepare concrete examples from your experience for each area.

These are the patterns that candidates report hurting them most in BA interviews.

Answering without examples. Saying 'I am good at stakeholder management' means nothing on its own. Every claim needs a brief, specific example. If you cannot think of one, the interviewer assumes you do not have the experience.

Confusing BA with PM. Business Analysts focus on requirements, process, and solutions. Project Managers focus on timelines, resources, and delivery. Know the boundary clearly, and know where your role sits on both sides of it.

Listing tools without context. Saying 'I use JIRA and Confluence' is a starting point, not an answer. Explain how you used them: what you tracked, what templates you created, how the team benefited from your contributions.

Skipping SQL preparation. Many candidates underestimate how common SQL questions are in BA interviews, especially in banking, insurance, and product companies. Even a basic working knowledge sets you apart from candidates who avoid it entirely.

Giving vague answers to scenario questions. When asked 'what would you do if...', interviewers want a step-by-step response. Vague answers like 'I would talk to the stakeholder' are not enough. Walk through who you would talk to, what you would ask, what you would document, and what outcome you would aim for.

Not asking clarifying questions. A strong BA instinct is to ask good questions before jumping to solutions. Doing this in an interview, especially for ambiguous scenario questions, signals exactly the right mindset.

Ignoring the business side. BA interviews often include questions about business impact and cost-benefit thinking. If you only speak in technical terms, you leave the impression that you are not truly business-facing.