Interview Questions - Scenario Based

These are scenario based questions that test a BA’s practical thinking, problem-solving, and stakeholder management skills under pressure

1. Stakeholders give vague requirements like “We need a better system.” How do you proceed?

I’d probe with open-ended questions to uncover pain points: “What does ‘better’ mean for you?” Then I’d use techniques like process mapping and root cause analysis to define measurable problems (e.g., system slowness, reporting gaps). Once clarified, I’d translate them into structured requirements and validate with stakeholders.

2. Midway through a project, a senior stakeholder demands a major change that will delay delivery. What do you do?

I’d document the requested change, assess impact on scope, timeline, cost, and quality, and present trade-offs clearly. If the change adds significant value, I’d help re-prioritize. If not, I’d recommend deferring it to a future release. This ensures transparency and balanced decision-making.

3. Developers say the requirements are unclear, but stakeholders insist everything is documented. How do you handle this gap?

I’d organize a joint review session with developers and stakeholders. Using examples, wireframes, or prototypes, I’d bridge the interpretation gap. My goal would be to rephrase requirements in technical and business terms until both sides confirm shared understanding.

4. Scenario: You’re working on a banking project and discover that some requirements may conflict with regulatory guidelines. What’s your approach?

I’d immediately flag the potential compliance issue, consult with the legal/regulatory team, and gather evidence. Then I’d work with stakeholders to adjust requirements so they align with regulations while still meeting business needs. This avoids future risk and costly rework.

5. You join a project where previous documentation is poor, and deadlines are tight. How do you catch up?

I’d start with quick discovery sessions to capture critical business processes and pain points. I’d prioritize documenting high-risk, high-value requirements first while maintaining a lightweight backlog of remaining items. Simultaneously, I’d create a living requirements repository to build structure as the project progresses.