Business analyst interviews test how you gather requirements, handle disagreeing stakeholders, and turn ambiguity into something a team can build. Below are the most common questions with model answers. Senior: architecture, trade-offs, mentoring, and decision-making.
Interviews go deep on one person's perspective, workshops surface conflict between stakeholders early, observation reveals what people actually do rather than what they say, document analysis captures existing rules, and prototypes get concrete feedback that abstract discussion never produces. The choice depends on how well the domain is understood — the less certain the problem, the more you lean on observation and prototypes.
Make the conflict explicit rather than quietly picking a side: document both positions, the reasoning behind each, and the trade-off. Then bring the stakeholders together with data — usage numbers, cost, risk — and get a decision from whoever owns the outcome. The failure mode is resolving it privately, because the losing stakeholder discovers it at delivery and the work gets rejected.
MoSCoW sorts requirements into Must have, Should have, Could have, and Won't have this time. Must items are the ones without which the release has no value; Won't is the most useful category because it makes exclusions explicit and stops silent scope creep. A common discipline is capping Must at around sixty percent of capacity so there is room for what discovery inevitably reveals.
A use case diagram shows which actors interact with which system capabilities — good for scoping conversations with business stakeholders. A sequence diagram shows the ordered messages between components over time and is aimed at developers designing an interaction. Activity and BPMN diagrams sit between them for process flow, and a state diagram is the right tool when an entity has a lifecycle such as an order or a claim.
A BRD captures business needs and objectives in business language — the why. An FRD translates those into specific system behaviours — the what. An SRS is the full specification including functional and non-functional requirements, constraints, and interfaces, often for a technical audience. Many Agile teams replace all three with a product backlog plus lightweight supporting documents, keeping formal specs only where compliance requires them.
The strongest signal is the questions asked during refinement — silence usually means the team has not engaged rather than that everything is clear. Practical checks are having a developer restate the story in their own words, reviewing acceptance criteria with QA before development starts, and using a prototype or example mapping session to surface hidden assumptions. Anything discovered here is far cheaper than after implementation.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior Business Analyst interview →