Data Analyst vs Business Analyst: Skills, SQL, and Interview Preparation

Data analyst and business analyst roles overlap. Both may use SQL, investigate business problems, and explain recommendations to stakeholders. The most useful distinction is the primary deliverable: a data-focused role may emphasize a defensible measurement or diagnosis, while a requirements-focused role may emphasize the change an organization should implement.

Choose your preparation from the job description, not the title alone. An analytical business analyst position can require substantial SQL and statistics. A data analyst who cannot explain a recommendation is also missing an important part of the work.

This guide uses official sources checked on September 12, 2026, and an original subscription-cancellation case.

Compare the Work Products, Not the Stereotypes

Business analysis concerns understanding organizational needs and recommending changes that create stakeholder value. That is the substance of IIBA’s professional definition. IIBA also describes business analysis work across multiple job titles; its definition is not a rule that every employer uses the same responsibilities.

For this comparison, a data-analysis deliverable is a traceable answer derived from data: the population, calculation, checks, findings, and limitations. A requirements or process deliverable describes the intended change: affected users, current behavior, proposed rules, exceptions, and acceptance conditions.

Those deliverables can belong to the same person. Separating them helps you see what a posting emphasizes without inventing a hard boundary between professions.

Work product	Data-focused emphasis	Requirements-focused emphasis
Problem definition	Which measurement would answer the question?	Which user need or process should change?
Evidence	Reliable datasets, calculations, uncertainty	Stakeholder needs, business rules, constraints
Main artifact	Analysis, metric definition, dashboard, recommendation	Process model, requirements, acceptance examples
Quality check	Can someone reproduce and interpret the result?	Can users and implementers agree on expected behavior?

Communication belongs in both columns. The analyst must explain why the evidence supports the proposed action and where it does not.

Does a Business Analyst Need SQL?

Sometimes SQL is explicitly required. Official example: Amazon’s Business Analyst II, WW FBA, FBA Analytics listing in Bengaluru includes SQL among its basic qualifications. Its responsibilities also include metrics, reporting, large datasets, query performance, stakeholder recommendations, and statistical techniques.

That is evidence about one team and posting. It is not an estimate of how many business analyst jobs require SQL, and it does not establish a standard interview sequence. It does show why “choose BA to avoid SQL” is unreliable advice.

When a posting mentions querying, data modeling, metric ownership, or dashboard development, investigate the expected technical depth. When it emphasizes elicitation, process mapping, user acceptance testing, or requirement traceability, investigate the expected change-management artifacts.

If SQL is absent, mark it as not stated, rather than “not needed.” Ask the recruiter whether the role queries data directly, works through an analytics partner, or uses an existing reporting layer. Then prioritize practice based on the answer.

Read Job Requirements in Three Categories

Use three labels when reviewing a real posting: explicitly required, specific to this team, and not stated. A tool listed in basic qualifications is different from a technology mentioned in a project example. A blank does not tell you the employer has no expectation.

For each explicit requirement, attach an item of evidence from your experience. For SQL, that could be a query whose grain, joins, and edge cases you can defend. For requirements work, it could be an example where two stakeholders meant different things by the same phrase and you resolved the disagreement.

For team-specific context, identify what you need to learn rather than pretending to have done the same job. Subscription metrics, warehouse operations, and financial reporting can share analytical techniques while requiring different definitions and operating knowledge.

For unstated requirements, prepare a precise question. “Will I own dashboard implementation or define requirements for another team?” is more useful than “Is this role technical?” The latter invites a label; the former clarifies the work you would actually deliver.

One Subscription Problem, Two Useful Deliverables

Here is an original practice case, not an employer question or real company dataset. A subscription product manager says, “Cancellation requests rose from ten in April to sixteen in May. We should make the cancellation journey longer.”

A data-focused response first checks the population. Suppose April had 100 eligible subscriptions and May had 200, and both groups have complete thirty-day observation windows. Define the metric as the percentage of eligible subscriptions with at least one cancellation request during that window.

The rate is 10/100, or 10%, for April and 16/200, or 8%, for May. Requests increased in count while the request rate decreased by two percentage points. This does not prove the product improved; it shows the opening claim omitted the denominator.

A requirements-focused response asks what outcome the proposed change should achieve and what customer problem it solves. Is the concern unwanted renewal, payment failure, low product use, or confusion about when cancellation takes effect? A longer journey could hide dissatisfaction without solving its cause.

Both responses are necessary. A sound calculation does not choose a responsible process change by itself, and a well-documented process change can still be based on the wrong metric.

The Data Diagnosis: Define Grain and Handle Duplicates

For the small exercise, let cohort contain one row per eligible subscription, assigned to April or May. Let events contain cancellation requests already restricted to each subscription’s thirty-day observation window. That preprocessing assumption matters: this query does not calculate the date boundary itself.

The following SQLite query counts subscriptions with a request rather than counting request events. We ran it locally against the stated fixture, including a duplicate May request.

SELECT c.month, COUNT(*) AS eligible,
       SUM(CASE WHEN EXISTS (
         SELECT 1 FROM events e
         WHERE e.subscription_id = c.subscription_id
           AND e.event = 'cancel_request'
       ) THEN 1 ELSE 0 END) AS requested
FROM cohort c
GROUP BY c.month
ORDER BY c.month;

The output is April: 100 eligible, 10 requested; May: 200 eligible, 16 requested. An extra event for the same May subscription does not increase the numerator. A direct one-to-many join followed by an unqualified count could inflate the population or requests.

Before applying this to real data, resolve subscription restarts, multiple subscriptions per customer, time zones, event delays, and whether eligibility is assessed at signup or another defined point. The fixture deliberately avoids those complications so the denominator and duplicate-event issue remain visible.

Do not call this completed churn. A cancellation request can be withdrawn or take effect later. Distinguish request rate, completed cancellation rate, and retained paid subscriptions according to the decision being made.

The Process Deliverable: State What Should Happen

Now write a separate process proposal. For the practice case, assume customer interviews suggest users are uncertain about the final access date. That is an exercise assumption to investigate, not a conclusion from the request counts.

A bounded proposal is to show the effective cancellation date clearly and give the user a confirmation record. Define what happens when a subscription is already scheduled to end, when the request is repeated, and when the update fails. These rules should be understandable before implementation begins.

An acceptance example could read: “Given an active subscription with an agreed end date, when the user confirms cancellation, the system shows that date and records the request once.” Another should cover failure: “If the update fails, show that cancellation has not been completed and provide a recoverable next step.”

Identify who approves the wording, who implements the state change, and who verifies billing behavior. Do not let a screen-level confirmation imply that every downstream system has already updated unless that is the agreed system behavior.

This is where process analysis becomes concrete. It connects the user’s expectation to business rules, system states, and testable exceptions. A diagram with boxes labeled “improve retention” would not provide enough detail.

Bring the Two Deliverables Back Together

The data diagnosis should inform the process proposal, and the proposal should define what needs to be measured after a change. In this case, track whether users understand the effective date and whether cancellation requests are processed correctly, rather than celebrating fewer visible requests alone.

You could propose a controlled evaluation of clearer information, with a defined population and checks for unsuccessful cancellation attempts. That is a suggested next step, not a claim that the fictional change caused a retention improvement.

A concise recommendation might be: “The higher request count is explained partly by a larger eligible population; the request rate is lower in this fixture. We have not established a cause. Investigate confusing end-date communication and validate the revised flow before making a retention claim.”

Notice how this answer combines calculation, restraint, and action. You do not need to choose between being quantitative and understanding the customer. The strongest work connects both.

Match Interview Practice to the Job Description

The following is a preparation map, not a prediction of rounds. Use it to decide where your practice time should go after reading the actual role requirements.

Posting signal	Practice emphasis	Evidence to produce
SQL and metric ownership	Joins, grain, windows, denominators	Query plus expected output and edge cases
Statistical analysis	Assumptions, uncertainty, comparison design	Explanation of what the data can establish
Requirements and process change	Clarification, state transitions, exceptions	Small process proposal with acceptance examples
Stakeholder recommendations	Prioritization and trade-offs	Short recommendation tied to evidence
Dashboard delivery	Definitions, refresh behavior, readability	A chart whose population and timing are clear

Official employer example: Wise’s analytics case-study guidance assesses analytical depth, customer-oriented problem solving, and presentation. That supports practicing communication alongside technical analysis. It does not mean another employer will use Wise’s task or timing.

For a data-heavy interview, rehearse the cancellation calculation and explain why event rows are not the denominator. For a requirements-heavy interview, rehearse the ambiguous request and failure cases. For a hybrid role, present both and explain how the findings affect the proposed change.

Five Questions to Expose Your Preparation Gaps

The links are skill exercises, not evidence that a specific employer asks them.

Practice question	What to demonstrate
Define and compute retention and churn precisely	Define the event, population, and observation window
Build cohort 30-day retention from signup date	Treat incomplete windows deliberately
How do you prioritize requirements	Explain value, constraints, and what can wait
Clarify Ambiguous Requirements and Resolve Team Conflicts	Resolve competing definitions before implementation
Clarify an Ambiguous Product Question and Define a Metric	Connect a business question to a measurable answer

After answering, ask someone to challenge one assumption. What if users have two subscriptions? What if the cancellation timestamp is logged late? What if the requested process change conflicts with a billing constraint? Your ability to revise the answer is part of the skill.

Choose a Role from Evidence You Can Defend

Choose a target role by comparing its daily deliverables with the work you want to do repeatedly. If you enjoy tracing unexpected numbers, constructing reliable datasets, and defending calculations, prioritize positions with substantial analytical ownership. If you enjoy resolving conflicting needs and turning them into implementable rules, investigate requirements-focused positions.

If both appeal to you, seek a hybrid role and ask how responsibilities are divided. Avoid assuming one title is easier, more communicative, or more technical in every organization. Also avoid choosing from salary figures that mix locations, seniority, and different job families.

For your application, prepare one work sample with two clearly separated sections: what the evidence shows and what change you recommend. State the parts you actually completed. A local exercise can demonstrate reasoning without being presented as paid work or a production success.

Begin with Define and compute retention and churn precisely, then adapt your explanation to the target posting. A clear denominator and a defensible next action are useful in either career path.

Sources and Further Reading

• IIBA: What is business analysis? — professional definition and overlapping job titles.
• Amazon: Business Analyst II, WW FBA, FBA Analytics — one Bengaluru posting with explicit SQL and analytical responsibilities.
• Wise: Analytics case-study guidance — employer-specific evidence that analysis and communication are assessed together.