IT business analyst is useful when hired well and actively harmful when hired badly. A strong BA bridges business and engineering — translating fuzzy requirements into precise, testable specs, surfacing risks before they become rework, owning UAT so launches are not surprise failures. A weak BA is a meeting attendee who writes status reports nobody reads and slows every decision by insisting on another workshop. The Indian BA talent pool spans a wide range. At the low end, coordinators who copy what engineers say into Confluence pages. At the high end, senior BAs who facilitate a workshop with five business stakeholders plus three engineers and emerge with a written spec everyone signed off on. The former earns 6 to 12 lakhs in Pune, Chennai, or Hyderabad; the latter earns 18 to 30 lakhs in Bangalore or Gurgaon. The best screening question is "show me a spec you wrote that engineers built from without a follow-up meeting." Strong BAs have one ready; weak ones describe their role in meetings instead.
Runs a workshop with five to seven stakeholders and walks out with a written specification that everyone aligns on. Not "I scheduled meetings and took notes." Uses structured techniques — user story mapping, persona interviews, as-is-to-be analysis. Ask about the last workshop they facilitated.
BPMN, UML activity diagrams, swimlane charts, or equivalent. Can diagram as-is and to-be flows on a whiteboard under interview conditions. Critical for BFSI, insurance, healthcare, and logistics clients where processes are the primary product.
Writes specifications engineers can build from without five follow-up meetings. Concrete, testable acceptance criteria, prioritized, with explicit out-of-scope. Ask for a sample. Specs that look like wish-lists with no testability are a rejection signal.
Comfortable with senior business stakeholders (directors, VPs) AND comfortable telling engineers "no, that is not what the business asked for." Not intimidated upward and not pushed around downward.
Has run real user acceptance testing cycles — not just signed off on engineering handover. Written test cases with real users, debriefed feedback, made decisions on launch vs delay. UAT is where bad BAs are exposed.
Lets BAs do their own data digging during requirements work rather than depending on an analyst. Reduces analyst dependency and accelerates decisions. Rare in the Indian BA pool; strong premium signal.
BFSI, healthcare, insurance, retail, telecom. Domain-specific BAs charge a premium because they understand vocabulary, workflows, and compliance constraints clients do not want to re-teach.
Modern teams want BAs comfortable with backlog grooming, user story writing, sprint review facilitation, and working with product managers rather than replacing them.
Figma, Balsamiq, or even PowerPoint mockups. BAs who can visually prototype requirements close the gap between business and engineering much faster than spec-only BAs.
Has owned a process change rollout — training plans, communication plans, readiness assessment. Important for enterprise BA roles where deployment is more than a technical release.
A client hires you to design a new customer onboarding experience. Walk me through your first two weeks — what you do, who you talk to, what artifacts you produce.
What to listen for
Stakeholder identification and mapping, one-on-one interviews, facilitated workshops, prototype or wireframe, as-is process documentation, to-be proposal, draft specification reviewed with stakeholders. Strong BAs have a methodology. Weak BAs improvise and schedule meetings.
A senior stakeholder says "just make the dashboard better." What do you do before writing any requirements?
What to listen for
Asks better for whom, compared to what, measured how. Drills into specific user actions and outcomes — "when you say better, do you mean faster to load, easier to find the top KPI, or more customizable." Senior BAs know vague requests are traps.
Engineering says a requirement is impossible within the timeline. What do you do before accepting that or escalating?
What to listen for
Asks what makes it impossible — technical limitation, missing data, integration dependency, capacity. Looks for alternatives that meet 80 percent of the business need at 20 percent of the cost. Not "I accept" and not "I escalate." Senior BAs are creative problem-solvers here.
Show me or describe a specification you wrote recently that engineers built from successfully. What made it work?
What to listen for
Clear user stories with acceptance criteria, concrete examples (not abstract rules), prioritization with explicit out-of-scope, linked wireframes or mockups, testability. Strong candidates describe the structure from memory. Weak candidates describe meetings rather than documents.
During UAT, a user reports a bug. The PM says it is a new requirement not in the original spec. You read the spec and it is genuinely ambiguous. How do you handle this?
What to listen for
Read the original spec, determine root cause honestly (ambiguous, missed, or an actual change), neutral escalation with options (defer and ship, fix and slip, partial fix), not finger-pointing. Senior BAs own ambiguity rather than blaming.
Three stakeholders disagree on priorities. A wants feature X, B wants feature Y, C wants a bug fix. How do you prioritize?
What to listen for
Uses a real framework — cost of delay, MoSCoW, Kano, WSJF, stack ranking. Writes up impact and cost of each. Facilitates a decision rather than making one unilaterally. Strong BAs know the name and logic of at least two prioritization frameworks.
What is the difference between a requirement, a user story, and an acceptance criterion? Give me an example of each for the same feature.
What to listen for
Clarity on the hierarchy — requirement is what the business wants at high level, user story is the actionable chunk from a user perspective, acceptance criteria are testable conditions. Strong BAs give a concrete example in under a minute for something like "user can reset password."
Tell me about a requirement that looked simple but blew up in complexity once you started digging. What warning signs did you miss?
What to listen for
Specific example with specific technical or process complexity — integration with legacy, compliance, localization, multi-tenant data isolation. Honest acknowledgment of what they would spot earlier. Senior BAs have scars and learn from them.
Score each candidate against these weighted criteria. Total: 100%.
| Criterion | Weight | Signal |
|---|---|---|
| Requirements elicitation | 30% | Real workshops, structured interviews, artifacts produced. Can name the method they used and why. |
| Spec writing | 25% | Shows a sample spec that engineers built from. Uses acceptance criteria, examples, prioritization. Engineer-friendly structure. |
| Stakeholder management | 20% | Comfortable with execs AND engineers. Has said no diplomatically. Has facilitated disagreements without escalating everything. |
| Process modeling | 15% | Diagrams a complex process flow on a whiteboard from memory in under 10 minutes. Has opinions about BPMN notation. |
| UAT discipline | 10% | Owned UAT cycles with real users. Wrote test cases, ran debriefs, made go or no-go recommendations. |
Cannot show a real spec they wrote — can only describe meetings they attended and decisions others made
Has never said no to scope creep or pushed back on an unrealistic requirement from a senior sponsor
Believes BA is "the person between PM and engineering" with no ownership of their own — pure intermediary mindset
Cannot diagram a basic process flow on a whiteboard under light time pressure despite claiming process modeling expertise
Treats UAT as a formality — signs off without engaging real users or documenting genuine test outcomes
Upload Business Analyst CVs and let AI score every candidate against the same 42-point evidence rubric.
Try CVPRO Free