Skip to main content
VirtualInterview.ai
Sign InSign Up

Mock interviews by role · Business, Finance & Consulting

Business Analyst mock interview

Business analyst interviews ask whether you can turn a messy request into a requirement someone can build and test. A long list of techniques without a requirement you wrote is a weak answer.

Walk through one change: who asked, what you clarified, what you left out, and how you knew it was done.

Practice this role with an AI interviewer

What the loop usually looks like

  1. Screen

    25 min

    A requirement you owned and the stakeholder.

  2. Exercise

    45 min

    Elicit requirements from a vague prompt.

  3. Communication

    30 min

    Conflict between stakeholders or a missed requirement.

What interviewers score

  • Clear requirements
  • Process understanding
  • Stakeholder alignment
  • Testable acceptance

10 business analyst interview questions and model answers

  1. Domain

    1. A stakeholder says make it more user friendly. What do you ask next?

    What they are testing: Elicitation.

    I ask which task is failing, for whom, and what done looks like. I turn that into a scenario with an acceptance check. I do not write user friendly into a specification.

  2. Situational

    2. Two departments define the same term differently. What do you do?

    What they are testing: Shared language.

    I put both definitions on one page and ask them to pick or to rename one. The requirement uses the chosen word. I do not average two meanings into a vague sentence.

  3. Behavioral

    3. Tell me about a requirement you cut.

    What they are testing: Scope.

    A report asked for twelve filters. Users needed two. I showed the usage from a similar report and we shipped the two, with the rest listed as later. The build was testable in the sprint.

  4. Domain

    4. How do you write acceptance criteria a tester can use?

    What they are testing: Testability.

    Given a starting state, when the user acts, then the observable result. I include one failure case. If a tester cannot tell pass from fail, the sentence is not done.

  5. Behavioral

    5. Describe a requirement that was wrong in production.

    What they are testing: Learning.

    We missed a permission case for a secondary role. I added that role to the question list I use in elicitation, and I sent a correction note the day we found it. I did not treat it as only a testing miss.

  6. Situational

    6. Engineering says the requirement is too vague to estimate. What do you change?

    What they are testing: Precision.

    I ask which sentence blocks the estimate and I rewrite that sentence with an example. I do not add pages of background. The example is usually what they needed.

  7. Domain

    7. How do you map a process without boiling the ocean?

    What they are testing: Process scope.

    I follow one trigger to one outcome and note the handoffs and the waits. I stop at the teams who do not affect that outcome. A wall-sized map that nobody maintains is not the goal.

  8. Behavioral

    8. Tell me about a workshop that did not go as planned.

    What they are testing: Facilitation.

    A senior person answered for everyone. I split the next exercise so each role wrote their step before discussion. The second half produced the exception path we had missed.

  9. Situational

    9. You discover the sponsor’s goal and the user’s goal differ. What do you document?

    What they are testing: Alignment.

    I write both and the release can only optimize one of them. I ask the sponsor to choose in writing. Building toward both without a choice is how rework starts.

  10. Domain

    10. How do you know requirements are ready for delivery?

    What they are testing: Definition of ready.

    The user, the trigger, the outcome, the exception, and a named approver are written. Open questions are listed, not hidden. I do not call it ready because the meeting ended.

Frequently asked questions

Will there be a case exercise?

Often. Practice asking questions before you propose a solution. Interviewers score the questions as much as the diagram.

How technical should I be?

Enough to know what is testable and what is expensive. You are not the engineer. A requirement that ignores a known constraint will be challenged.

What is a good sample to bring?

One redacted user story or process note with acceptance criteria. Be ready to defend what you excluded.

Can I practice elicitation by voice?

Yes. A business analyst mock can play the vague stakeholder and wait to see if you pin down done.

Keep practicing