Business analyst phone screen questions: elicitation, stakeholders and domain
On this page
- Which business analyst seat: IT, process or agile-embedded
- Requirements elicitation: the core skill test
- Stakeholder management and translation
- Domain and process knowledge
- Documentation and tools
- IIBA certifications: what each one proves
- How business analyst resumes overstate the work
- Knockout checklist and scorecard
- Questions people ask
A business analyst phone screen should find out whether the candidate can turn a vague business problem into a requirement someone can build from, and whether they can survive a room where two stakeholders want different things. Ask for a specific requirements document they owned, how they ran an elicitation session, and one requirement that changed after everyone thought it was locked. Candidates who did the work describe a process: interviews, workshops, a draft, a review, a sign-off. Overstated resumes say "gathered requirements" and "liaised with stakeholders" with no artifact and no story behind either phrase.
This is a different screen from data analyst phone screen questions, which tests SQL and dashboards rather than requirements and process work. Many roles blend the two; confirm which one the job description is actually asking for before you screen, and ask which skill set carries more weight.
Which business analyst seat: IT, process or agile-embedded
| Seat | What the work usually is | Facts to ask for | Common overstatement |
|---|---|---|---|
| IT / systems business analyst | Bridges business needs and engineering: functional specs, system requirements, UAT | Systems involved, artifact types, who they handed requirements to | "Requirements gathering" for a role that only compiled notes from a manager's meetings |
| Process / operations business analyst | Maps current-state processes, finds inefficiencies, proposes future-state changes | A specific process mapped, the change proposed, whether it was implemented | Process maps that were never acted on presented as completed projects |
| Agile-embedded BA (often hybrid with product owner) | Writes user stories and acceptance criteria, works inside a scrum team, grooms the backlog | Sprint cadence, who owned prioritization, how stories were written | Confuses "wrote tickets" with owning requirements decisions |
| Data / reporting-leaning business analyst | Requirements work that feeds dashboards or reports rather than system builds | Whether SQL or BI tools were part of the role or a separate team's job | Data analyst title relabeled as business analyst, or the reverse |
Requirements elicitation: the core skill test
Ask: "Walk me through the last requirements document you owned, from the first conversation to sign-off." This single question does most of the work of the screen.
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| How did you gather the requirements — interviews, workshops, surveys, observation? | Names the method and why they chose it for that situation, sometimes more than one. | "I asked the stakeholder what they wanted and wrote it down." |
| How did you know when a requirement was actually done? | A defined acceptance criteria or sign-off process, with a named approver. | No clear definition of done; requirements were "understood." |
| What artifact did you produce — BRD, user stories, process flows, wireframes? | Names the specific document type and can describe its structure without prompting. | Cannot describe what the document actually contained. |
| Tell me about a requirement that changed after you thought it was locked. | A specific story: what changed, who raised it, how they handled the rework. | Nothing has ever changed after sign-off, which is not how real projects work. |
| How did you handle two stakeholders who wanted contradictory things? | Facilitated a decision, escalated with a recommendation, or used data to resolve it. | Picked whichever stakeholder was more senior with no reasoning given. |
Stakeholder management and translation
- "Who were your stakeholders, and how did their priorities differ?" Strong: names roles (product owner, ops manager, compliance, engineering lead) and a real tension between them.
- "Describe a time you had to explain a technical constraint to a non-technical stakeholder." Strong: translates without jargon and describes how the stakeholder's expectation changed as a result.
- "How did you handle a stakeholder who kept changing their mind?" Strong: a process for managing scope creep — change requests, impact analysis, re-approval — not just frustration.
- "What did you do when engineering said a requirement wasn't feasible?" Strong: went back to the business need behind the requirement and found another way to meet it, rather than just relaying the rejection.
Domain and process knowledge
A business analyst's value depends heavily on domain: a BA who has spent five years in claims processing is not directly transferable to a supply chain implementation, even though the skill of eliciting requirements is the same.
- "Which industry or business function have you worked in most — and what's specific to it that a BA from outside that domain wouldn't know?"
- "Walk me through a process you mapped current-state to future-state. What changed and what was the measured result?"
- "What systems have you written requirements for?" (ERP module, CRM, a homegrown application, a data warehouse — this shapes what the candidate can actually do on day one.)
Worked example: testing a process improvement claim (invented figures)
A candidate says: "I redesigned the onboarding process and cut processing time by 40 percent."
- Ask: "What was the process before, in steps, and what did you remove or change?"
- Ask: "40 percent of what baseline — average time per case, and how was that measured?"
- Ask: "Who approved the change, and did it actually go live?" A requirement proposed is not the same as a process implemented.
A BA who owned this can answer all three without pausing. A BA who watched someone else do it usually cannot.
Documentation and tools
| Claim | Question | Strong answer | Red flag |
|---|---|---|---|
| BRD / FRD writing | "What sections did your BRD template have?" | Describes structure: business objectives, scope, functional requirements, non-functional requirements, assumptions. | Cannot describe the document's structure. |
| User stories and acceptance criteria | "Show me how you'd write one, verbally." | Format like "As a [role], I want [goal], so that [benefit]," with testable acceptance criteria. | Cannot produce a well-formed story on the spot. |
| Process mapping (Visio, Lucidchart, BPMN) | "What notation did you use, and for what audience?" | Names a tool and adapts detail level for executives versus engineers. | Tool name with no example of an actual map. |
| JIRA, Confluence, Azure DevOps | "What did you own in the tool beyond writing tickets?" | Backlog grooming, traceability from requirement to ticket, reporting. | Only ever assigned tickets someone else wrote. |
IIBA certifications: what each one proves
Certifications are optional for most roles. Know what each requires (as of September 2026, per IIBA's own certification pages):
| Credential | Requirement | Question to ask |
|---|---|---|
| ECBA | Entry-level; IIBA positions it as the first step for people starting in business analysis, per IIBA's ECBA page | "What did the coursework cover that you've since applied?" |
| CCBA | Two to three years of business analysis work experience in the last seven years (3,750 hours), plus 21 hours of professional development in the last four years and two references, per IIBA's CCBA page | "Which of those hours came from requirements work versus adjacent roles?" |
| CBAP | Five or more years of business analysis work experience in the last ten years (7,500 hours), plus 35 hours of professional development in the last four years and two references, per IIBA's CBAP page | "What's the most complex requirements effort you led that qualified you for this?" |
How business analyst resumes overstate the work
| Claim | Question to test it |
|---|---|
| "Gathered and documented requirements" | "Show me the document. What sections, and what did you personally write versus consolidate from others?" |
| "Liaised between business and IT" | "Give me one specific disagreement between the two sides and how you resolved it." |
| "Led process improvement initiatives" | "What was the baseline, what changed, and did it actually go live?" |
| "Agile business analyst" | "Whose backlog was it — did you prioritize it, or write tickets someone else prioritized?" |
Knockout checklist and scorecard
Must-ask on every business analyst phone screen
- Seat: IT/systems, process, agile-embedded, or data-leaning.
- One requirements document owned start to finish, with the artifact named.
- A requirement that changed after sign-off, and how they handled it.
- One real stakeholder conflict and how it was resolved.
- Domain fit for the client's industry or function.
- Tools and documentation style relevant to the client's process.
Knock out, or flag before submitting, if the candidate cannot describe an artifact they personally produced; if every stakeholder interaction they describe was conflict-free, which is not credible for real project work; if the role needs deep domain knowledge the candidate does not have; or if the role is genuinely a data analyst role and the candidate has no SQL or reporting experience at all.
| Area | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Elicitation | Notes from a meeting | Ran interviews or surveys | Ran workshops, built artifacts | Owns the full lifecycle to sign-off |
| Stakeholder work | No real conflict described | Basic translation | Resolved a real disagreement | Facilitates decisions across senior stakeholders |
| Domain fit | No relevant domain | Adjacent domain | Direct domain match | Deep domain match, specific detail |
| Documentation | Cannot describe artifacts | Generic description | Specific structure and tools | Built templates or standards others used |
| Logistics fit | Deal-breaker | Two open questions | One open question | All aligned |
Write the evidence next to each score, in the candidate's own words: "Ran three requirements workshops for the claims intake redesign, wrote the BRD, and caught a scope conflict between compliance and ops before it reached development." Interview Signal attaches quotes like that to each score from the call itself, so the write-up matches what was actually said.
Questions people ask
How is a business analyst phone screen different from a data analyst screen?
A data analyst screen tests SQL, dashboards and data quality. A business analyst screen tests requirements elicitation, stakeholder translation and process or domain knowledge; the artifacts are business requirements documents and user stories, not queries. Some roles blend both, so ask which one this job actually needs before you screen.
Is an IIBA certification required to hire a business analyst?
No. ECBA, CCBA and CBAP are respected credentials but not legally required. Treat them as a signal of formal training and test the actual elicitation and stakeholder work on the call.
What's the single best question for spotting a weak business analyst?
Ask them to describe a requirement that changed after they thought it was finalized, and what they did about it. A real BA has a specific story about a missed stakeholder, a misread process, or scope that shifted, and what they changed in their process afterward.
Should I test BABOK knowledge directly?
Only lightly, and only if the role is certification-heavy. Asking someone to recite BABOK terminology tests memorization, not whether they can run a requirements workshop. Ask for the workshop instead.