Does a business analyst need to know SQL?

It depends on the role. Analysts on data-heavy systems, reporting or migrations often write SQL every week; others work from reports and spreadsheets. Decide before the loop, say so in the job description, and test at that level with a small, realistic dataset.

How do you run a requirements-elicitation role-play in an interview?

Write a short brief for the interviewer playing the stakeholder, with two or three facts revealed only when the candidate asks the right question. Use the same brief and the same answers for every candidate. Rate what the candidate uncovered and how, against the anchors, not how smoothly the conversation went.

Should we hire a business analyst with experience in our industry?

Domain knowledge helps from day one in regulated areas such as banking, insurance or healthcare, but elicitation and clear writing are harder to teach. If domain knowledge is truly required, name it in the job description and test it with a scenario, not a quiz on terms.

Does it matter whether a business analyst has worked in agile or plan-driven teams?

Less than it seems. The core skills are the same: finding the need, mapping the work and writing testable requirements. The format changes, from a requirements document to user stories and backlog refinement, and a capable analyst adapts to either.

Free interview kit

Business Analyst interview kit: questions and rubric

For hiring teams interviewing a business analyst with roughly two to six years of experience who works between business teams and the people who build or configure systems, in-house or for clients, in agile or plan-driven delivery. It covers a short screen, five competencies with behavioral, situational and work-sample questions, a requirements-elicitation role-play, anchored ratings, the questions never to ask, and a rule for deciding.

5 competencies · 10 questions · anchored 1-to-5 scale · Updated 10 October 2026 · Written by the Itya team

Share this kitLinkedIn X WhatsApp Email

How to use this kit

Agree the competencies with the hiring manager before the job is posted.
Give each interviewer one or two competencies, so nothing is asked twice.
Ask every candidate the same core questions; follow up freely.
Rate each competency against the anchors straight after the interview, alone.
Debrief on quotes, not adjectives, then decide with the rule at the end.

First-round screen

Fifteen to twenty minutes, by phone, video or a disclosed AI screen. The aim is to confirm the basics before the panel spends its time.

What draws you to business analysis, and what kind of problems do you want to work on next?
Tell me about a change you analyzed from the first conversation to go-live: the problem, what you produced, and what happened afterward.
This role uses the methods and tools in the job description (for example, a backlog tool, process-mapping software, SQL or spreadsheets). Which have you used at work, and for what?
The job description sets out the location, working pattern and start date. Do those work for you, what is your notice period, and what compensation range are you expecting?

Competency 1

Requirements elicitation

Stakeholders usually arrive with a solution, not a need. A business analyst earns their place by finding the problem, the constraints and the people affected before anyone builds.

Role-play (15 minutes): I am the finance operations lead. I tell you, 'We need a new approval workflow for vendor invoices. It is urgent, and the current one is a mess.' Find out what I actually need. (Interviewer brief: the real pain is that invoices above a set limit wait days for one director who travels, and audit requires two approvers above that limit. Reveal each fact only when asked.)
Follow up with
- What would you write down as the problem statement?
- Who else would you need to talk to?
- What did you hear that you would check against data?
Strong answer
Asks how the process works today and for a recent example, finds out what 'a mess' means in time or errors, and uncovers the single-approver bottleneck and the audit rule. Separates the need from the proposed solution, plays back a summary, and names the approvers, auditors and accounts payable staff still to be heard.
Weak answer
Writes down 'new workflow' as the requirement, asks mostly yes-or-no questions, or starts designing screens in the meeting. Never finds the audit rule or anyone else affected.
Tell me about a time stakeholders asked for one thing and needed another. How did you find the gap?
Follow up with
- What did you do about work already planned?
- How did the stakeholder react?
Strong answer
Names the request, the technique that revealed the real need (watching the work, a worked example, asking why the request mattered), how they confirmed it with the stakeholder, and what changed in scope as a result.
Weak answer
Delivered what was asked and the gap surfaced in testing or after go-live, or overrode the stakeholder without agreeing the change.

Rating	What it looks like
5 · Strong	Separates needs from solutions, uncovers constraints such as controls and exceptions unprompted, plays back what they heard, and identifies everyone affected before scope is set.
3 · Mixed	Uncovers the main need with open questions and examples, but misses a constraint or a stakeholder group until prompted.
1 · Weak	Records the stated solution as the requirement. Asks few open questions and misses constraints and affected groups.

Competency 2

Process analysis and mapping

Most changes a business analyst works on alter how work flows between people and systems. Mapping the real process, exceptions included, shows where time and errors come from.

Work sample (10 minutes): here is a half-page description of how a customer refund is handled today across the support desk, finance and the warehouse. Sketch the current process on paper or a whiteboard, then tell me where it breaks. (Plant a re-keyed step, a duplicate approval and an exception nobody owns.)
Follow up with
- What happens when the returned item never arrives?
- What data would you want before proposing a change?
- Which notation did you use, and why?
Strong answer
Uses a lane for each team, marks hand-offs, decisions and waiting points, and finds the re-keyed step, the duplicate approval and the unowned exception. Asks for volumes and times before proposing changes. Keeps the notation simple and consistent.
Weak answer
Lists the steps in a single line with no owners, ignores exceptions, or proposes automating everything without locating where time is lost.
Tell me about a process you mapped where the documented version and what people actually did were different. What did you do with that?
Follow up with
- Why had the workaround grown up?
- Which version did the requirements follow?
Strong answer
Watched or walked through the work with the people doing it, documented the real process, found why the workaround existed, and used that to shape the requirements rather than enforcing the written procedure.
Weak answer
Mapped from the procedure manual or from managers' accounts alone, or recorded the workaround as the users' fault.

Rating	What it looks like
5 · Strong	Maps the real process with the people who do it, captures exceptions and hand-offs, locates delays and errors with data, and keeps the map clear enough for anyone to check.
3 · Mixed	Maps the main flow with owners and hand-offs, but misses exceptions or proposes changes before measuring where time is lost.
1 · Weak	Produces a list of steps with no owners or exceptions. Maps from documents rather than from the work.

Competency 3

Stakeholder management

A business analyst rarely has authority over the people whose needs conflict. They make disagreements visible and help the right person decide, without quietly taking sides.

Tell me about a time two stakeholders wanted conflicting things from the same change. How was it resolved?
Follow up with
- Who made the final call?
- How did you record the decision?
- How did the stakeholder who lost out respond?
Strong answer
Made the conflict explicit, traced each requirement to the business goal behind it, set out the options and their impact, brought both sides to the person who owned the decision, and recorded the outcome where the team could find it.
Weak answer
Sided quietly with the more senior person, specified both versions, or left the conflict for the developers to discover.
Halfway through delivery, a senior stakeholder who missed every workshop asks for a significant change. What do you do?
Follow up with
- What would you say in the first conversation?
- What would you do so it does not happen on the next project?
Strong answer
Listens for the reason, assesses the impact on scope, time and other requirements, routes the request through the agreed change or backlog process with the product owner or sponsor, and finds a way to involve that stakeholder from then on.
Weak answer
Agrees to avoid conflict and squeezes the change in, or refuses flatly because the requirements were signed off.

Rating	What it looks like
5 · Strong	Maps who is affected early, surfaces conflicts with options and their impact, gets decisions from the right owner, records them, and keeps the trust of the side that lost out.
3 · Mixed	Handles routine stakeholder needs well and raises conflicts, but relies on others to frame the options or record the decision.
1 · Weak	Avoids conflict, takes sides without saying so, or lets the loudest stakeholder set the scope.

Competency 4

Data analysis for requirements

Requirements built on anecdotes fix the wrong problem. The depth varies: some business analysts write SQL daily, others work in spreadsheets and reports, so test at the level the job description sets.

Work sample (10 minutes): here is a spreadsheet of 200 invoices with amount, submitted date, approved date and approver. The finance lead believes most delays come from invoices above the approval limit. Test that belief and tell me what you find. Use the spreadsheet or SQL, whichever you prefer.
Follow up with
- What did you do with invoices still waiting for approval?
- What would you check before trusting the dates?
- How would you run this on the full table?
Strong answer
Calculates approval time per invoice, splits it by amount band and by approver, handles the open invoices rather than dropping them, notes what 200 rows can and cannot show, and says plainly whether the belief holds.
Weak answer
Eyeballs the sheet, averages without handling open invoices, or confirms the belief without testing it.
Tell me about a time data changed a requirement or its priority.
Follow up with
- Where did the data come from, and how did you check it?
- How did the stakeholders respond?
Strong answer
Describes pulling or requesting specific data, checking it, and using it to change scope or priority, with the stakeholders agreeing the change.
Weak answer
Cannot give an example, or the data only decorated a decision already made.

Rating	What it looks like
5 · Strong	Turns each claim into a quick test, handles the awkward records, states what the data does and does not show, and uses it to set scope and priority.
3 · Mixed	Tests claims with data at the level the role needs, but misses a pitfall such as open records or duplicate rows until prompted.
1 · Weak	Relies on anecdotes. Cannot turn a claim into a simple test with the data available.

Competency 5

Writing clear specifications

Developers and testers build what is written, not what was meant. Clear, testable requirements prevent the rework that ambiguity causes later.

Work sample (10 minutes): from what you learned in the role-play, write one user story with acceptance criteria, or one requirement in the format you prefer.
Follow up with
- How would a tester check each criterion?
- What did you leave out of scope, and why?
Strong answer
Names the user and the outcome, writes testable criteria that cover the exceptions (an invoice exactly at the limit, an approver on leave, a rejection), states what is out of scope, and describes behavior rather than screen layout.
Weak answer
Uses untestable words like 'fast' or 'user-friendly', describes the screen instead of the behavior, or covers only the happy path.
Tell me about a requirement you wrote that the team built differently from what you meant. What happened, and what do you do differently now?
Follow up with
- How was the gap found?
- Who reviews your requirements before the build starts?
Strong answer
Owns the ambiguity, explains how it was found, and names a lasting change such as worked examples, Given-When-Then criteria, a glossary, or walking through stories with developers and testers before build.
Weak answer
Blames the developers for not reading carefully, or cannot recall a single misunderstanding.

Rating	What it looks like
5 · Strong	Writes requirements a tester can check line by line, covers exceptions and scope boundaries, defines terms, and reviews them with the people who build and test.
3 · Mixed	Writes clear, testable requirements for the main path, but misses some exceptions or leaves scope boundaries implicit.
1 · Weak	Writes vague requirements that cannot be tested, misses exceptions, and prescribes design without reason.

Never ask

Don't ask a candidate's age, or their graduation year to work it out. Why: age says nothing about analysis skill, and age-based decisions are unlawful in many places.
Don't ask about marital status, children, pregnancy or plans to start a family. Why: none of it is job-related, and the question is still put mostly to women, which makes it discriminatory as well as irrelevant.
Don't ask about religion, caste, community or the origin of a surname, directly or by proxy ('What does your father do?'). Why: in India these questions signal caste and religion, which have no bearing on the job.
Don't ask 'Where are you from originally?' or 'What is your native place?'. Why: it invites judgments about region and community. If location or client travel matters, ask whether the candidate can meet what the job description sets out.
Don't ask about health conditions, disabilities or past medical leave. Why: the only relevant question is whether the candidate can perform the essential functions of the job, with or without reasonable accommodation.
Don't ask for salary history where the law restricts it, as many US states and cities do. Why: it carries past pay gaps into the new offer. Ask for the expected compensation range instead.
Don't make a certification such as CBAP or an agile certificate a pass-or-fail screen unless a client contract requires it. Why: certificates show study of a method, not elicitation skill. The role-play and work samples show the skill directly.
Don't ask the candidate to map or specify one of your live processes as homework. Why: that is unpaid consulting. Use a fictional process, like the refund example, for every candidate.

Making the decision

The must-haves are requirements elicitation, stakeholder management and writing clear specifications. Set the expected depth of data analysis from the job description before the loop. Any 1 on a must-have is a no, and so is any competency rated 1 by two interviewers. A hire needs an average of 3.5 or higher. Each interviewer rates alone before the debrief; the hiring manager decides after it and records the role-play and work-sample evidence behind each rating.

Questions people ask

Does a business analyst need to know SQL?: It depends on the role. Analysts on data-heavy systems, reporting or migrations often write SQL every week; others work from reports and spreadsheets. Decide before the loop, say so in the job description, and test at that level with a small, realistic dataset.
How do you run a requirements-elicitation role-play in an interview?: Write a short brief for the interviewer playing the stakeholder, with two or three facts revealed only when the candidate asks the right question. Use the same brief and the same answers for every candidate. Rate what the candidate uncovered and how, against the anchors, not how smoothly the conversation went.
Should we hire a business analyst with experience in our industry?: Domain knowledge helps from day one in regulated areas such as banking, insurance or healthcare, but elicitation and clear writing are harder to teach. If domain knowledge is truly required, name it in the job description and test it with a scenario, not a quiz on terms.
Does it matter whether a business analyst has worked in agile or plan-driven teams?: Less than it seems. The core skills are the same: finding the need, mapping the work and writing testable requirements. The format changes, from a requirements document to user stories and backlog refinement, and a capable analyst adapts to either.

A kit is step one.

Itya holds every interviewer to the same rubric, records the interview, and drafts the scorecard with the quotes behind each rating. The AI drafts; your team decides. Free plan, unlimited teammates.

Run this kit in Itya All interview kits