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. Middle: deeper understanding, optimization, and real-world situations.
A user story follows "as a role, I want an action, so that a benefit" — the last clause matters most because it captures why, which lets the team propose better solutions. Acceptance criteria define done in testable terms, often in Given-When-Then form covering the happy path, edge cases, and errors. A story without criteria is an invitation for three people to interpret it three ways.
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.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle Business Analyst interview →