Business Analyst Evaluation Guide
IT BA is one of the most useful roles when hired well and one of the most useless when hired badly. The strong BA is the bridge between business and engineering — translating fuzzy requirements into precise specs, surfacing risks early, owning UAT. The weak BA is a meeting attendee who writes status reports. This guide separates them.
Key skills
Must-have
Requirements elicitation
Can run a workshop with 5 stakeholders and walk out with a written spec everyone aligns on. Hardest skill to fake.
Process modeling
BPMN, swimlane, or equivalent. Can diagram an as-is and to-be flow without floundering.
Spec writing
Writes specs that engineers can build from without 5 follow-up meetings. Concrete, testable, prioritized.
Stakeholder management
Comfortable with senior business stakeholders. Comfortable telling engineers "no, we cannot ship this without X."
Nice-to-have
SQL fluency
Lets BAs do their own data digging. Reduces dependency on data analysts.
Domain depth
BFSI, healthcare, retail — domain-specific BAs charge a premium and ramp faster.
Agile experience
Many modern teams want BAs comfortable with backlog grooming, story writing, sprint planning.
UAT ownership
Has run UAT cycles with real users, not just signed off on test cases.
Interview questions (6)
Walk me through how you would gather requirements for a new customer onboarding feature.
What to listen for
Stakeholder mapping, interviews, workshops, prototyping. Not "I would ask the PM what they want."
A stakeholder gives you a vague requirement: "make the dashboard better." What do you do?
What to listen for
Asks "better for whom" and "compared to what." Drills into specific user actions and outcomes.
Describe a time engineering said something was impossible. What did you do?
What to listen for
Asked why, found alternatives, scoped down. Not "I escalated to my boss."
How do you write a spec that engineers actually build from?
What to listen for
Acceptance criteria, examples, prioritization, what is OUT of scope. Not just "I write user stories."
A user reports a bug during UAT. The PM says it is a new requirement. How do you handle it?
What to listen for
Read the original spec, determine root cause, escalate with neutrality. Real BAs decide based on evidence, not politics.
How do you prioritize when stakeholders disagree?
What to listen for
Cost/value framing, kano model, MoSCoW, stack ranking. Real frameworks, not "I let the PM decide."
Evaluation rubric
Score each candidate against these weighted criteria. Total: 100%.
| Criterion | Weight | Signal |
|---|---|---|
| Requirements elicitation | 30% | Has run real workshops, conducted real interviews, written real specs. |
| Spec writing | 25% | Can show a sample spec. Engineer-friendly, testable, scoped. |
| Stakeholder management | 20% | Comfortable with execs and engineers. Examples of mediating disagreement. |
| Process modeling | 15% | Can diagram a complex flow on a whiteboard from memory. |
| UAT discipline | 10% | Has owned UAT, written test cases, debriefed users. |
Red flags
Cannot show a real spec they have written
Has never said "no" to scope creep
Believes BA is "between PM and engineering" with no own ownership
Cannot diagram a basic process flow without prompting
Treats UAT as a checkbox, not a quality gate
Apply this rubric automatically with CVPRO
Upload Business Analyst CVs and let AI score every candidate against the same 42-point evidence rubric.
Try CVPRO Free