Why pre-screen business analysts before the stakeholder interview
The failure mode in business analysis is documentation without challenge. A stakeholder states a requirement, the analyst records it accurately, engineering builds it, and it solves a problem nobody had because the stated requirement was a proposed solution rather than the underlying need. Analysts who avoid that ask what happens today and why, and are willing to tell a senior stakeholder their request will not achieve what they want. A short screen finds out which kind you have.
What actually matters when screening Business Analyst candidates
- 01
Technical proficiency
Check fluency with requirements artefacts: BRDs, user stories with acceptance criteria, BPMN or swimlane process maps, data dictionaries, plus SQL querying and tools like Jira, Confluence, Visio.
- 02
Systems and trade-offs
Probe how they handled conflicting requirements between departments, scope creep on a release, or a build versus configure decision on an ERP or CRM module.
- 03
Evidence and rigour
Test how they validated requirements: data profiling before migration, as-is volumetrics, UAT test scripts, defect triage, and benefits tracked after go-live.
- 04
Collaboration and communication
Assess how they run elicitation with reluctant stakeholders: workshop facilitation, shadowing operations staff, sign-off chasing, and translating between business users and developers in sprint ceremonies.
Pre-screening questions to ask Business Analyst candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Technique command
3 questions01Which methodologies are you familiar with for analysing and improving business processes?
Listen forNamed approaches tied to when each suits a problem, with an honest view on where a technique adds ceremony rather than insight.
Methodologies listed with no basis for choosing, or a single framework applied to every situation.
02Which documents and models have you produced in previous projects?
Listen forArtefacts tied to a decision they supported, with a view on which ones nobody read and were dropped.
Long documentation lists with no account of who used them, or artefacts produced because the template required them.
03Are you familiar with lean or continuous improvement approaches?
Listen forApplied use with a measured before and after, and honesty about an improvement that did not survive contact with the team.
Approaches named from training with no application, or improvements claimed with no measurement.
Weighing the options
3 questions04What steps do you take when gathering requirements?
Listen forObserving the process as performed alongside interviews, with the workarounds people rely on surfaced rather than the official version.
Requirements gathered entirely from interviews and existing documents, with no observation of actual work.
05How do you prioritise requirements on a project?
Listen forAn explicit method applied consistently, with something deprioritised despite a senior stakeholder wanting it and how that was handled.
Priority set by seniority of the requester, or every requirement classified as essential.
06Can you describe your approach to a process redesign project?
Listen forCurrent state measured before redesign, with options compared and the chosen one justified against a stated criterion.
Jumps to a target state with no baseline, or a redesign shaped by the software that was already purchased.
Evidence they gathered
3 questions07Can you give an example where you used data analysis to solve a business problem?
Listen forAnalysis they performed themselves with a finding that contradicted what stakeholders believed, and how it was received.
Analysis performed by someone else, or findings that only ever confirmed the existing assumption.
08How do you validate your conclusions after analysing a process?
Listen forFindings tested back with the people who do the work, plus a conclusion they revised when it did not hold up.
Conclusions presented without validation, or no analysis of theirs that was ever wrong.
09Can you give an example of improving efficiency using analysis?
Listen forA measured improvement with the baseline stated, and honesty about whether it held once attention moved elsewhere.
Improvements claimed with no measurement, or gains that reverted after the project closed.
Holding the room
3 questions10Which stakeholders have you worked with, and how do you manage those relationships?
Listen forNamed roles across levels, with a case where two stakeholders wanted incompatible things and how it was resolved.
Stakeholder management described as regular updates, with no example of resolving a genuine conflict.
11How do you handle disagreements during a project?
Listen forA disagreement resolved with evidence rather than escalation, including a case where they conceded because the objection was right.
Conflicts escalated by default, or positions held with no evidence beyond their own analysis.
12Can you give an example of explaining a complex process to a non-technical audience?
Listen forAn explanation pitched at the decision being made, with the complexity that mattered retained rather than simplified away.
Simplifies by omitting a constraint that mattered, or explains at a level the audience could not act on.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Names artefacts they authored, writes acceptance criteria in Gherkin or equivalent, and queries source systems directly rather than requesting extracts.
Systems and trade-offs
25%5Explains a specific trade-off they framed for sponsors, including what was deferred, why, and the downstream cost the business accepted.
Evidence and rigour
25%5Cites baseline and post-launch numbers (cycle time, error rate, ticket volume) and admits where a requirement proved wrong in UAT.
Collaboration and communication
15%5Describes named workshop formats they ran, how they secured sign-off from a resistant department head, and gives clear, jargon-free explanations.
A stated requirement is usually a proposed solution, and recording it accurately builds the wrong thing. A one-way video screen asks what they pushed back on.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for a business analyst take?
Fifteen minutes across eight to ten questions, answered async. Enough to test technique depth, hear one requirement they challenged, and establish whether their recommendations came from evidence or from stakeholder preference.
What should the screen establish beyond methodology?
Whether they observe the process as performed rather than as documented. The gap between the two is where most of the value is, and analysts who work only from interviews and existing documentation never see it.
Evaluating answers
What is the strongest signal when screening a business analyst?
A requirement they pushed back on. Analysts adding value can name a request they challenged, what the underlying need turned out to be, and how the conversation went. Anyone who records everything faithfully is a scribe with a job title.
How do I judge their data work?
Ask what the data contradicted. Strong analysts can name a case where the numbers disagreed with what stakeholders believed about their own process, and describe how they handled presenting it. Analysis that only ever confirms is not analysis.
























