How SQL Skills Boost Your Business Analyst Job Search

Common business analyst job requirements:

- "Strong Excel and SQL skills"
- "Write queries to pull data from databases"
- "Build dashboards using SQL and BI tools"
- "Comfortable with large datasets"
- "Ability to answer business questions independently"

SQL appears in the majority of analyst job posts.
It is the skill most likely to be tested live in an
interview, which makes it the highest-leverage
thing to practise before applying.

SQL replaces these in a BA workflow:

1. Waiting on the data team for a fresh export
2. Rebuilding pivots after every data refresh
3. Manual reconciliation between two sources
4. Guessing which segment caused a change
5. Sending people spreadsheets they cannot verify

What SQL does NOT replace:
- business judgment
- choosing the right metric
- explaining the result to a stakeholder

That combination — SQL plus judgment — is what
hiring managers are actually looking for.

Question:
"Show monthly revenue per region for the last
6 months, including regions with no orders."

Wrong approach:
- INNER JOIN only (drops regions with no orders)
- no date filter
- no ordering

Right approach:
1. Filter orders to the last 6 months
2. LEFT JOIN regions so empty regions still appear
3. GROUP BY month and region
4. SUM(revenue), COALESCE to 0 for empty groups
5. ORDER BY month, region

The interviewer is testing whether you think
about missing data, not whether you memorised
syntax.

How to answer out loud in a SQL round:

1. Restate the question
   "So you want monthly revenue by region,
   including regions with no orders."

2. State your plan
   "I will filter orders to six months, then
   LEFT JOIN from regions so empty ones remain."

3. Write the query in small steps
   - start with the SELECT
   - add the JOIN and ON condition
   - add WHERE
   - add GROUP BY

4. Check edge cases out loud
   "What happens if revenue is null? I will
   COALESCE to zero."

5. Summarise
   "This returns all regions, even those with
   no orders, over the last six months."

Interviewers score this reasoning as much as
the final query.

Query patterns to practise:

1. Monthly totals
   SELECT month, SUM(revenue)
   FROM orders
   GROUP BY month;

2. Monthly totals by region
   SELECT month, region, SUM(revenue)
   FROM orders
   GROUP BY month, region;

3. Customers with no orders
   SELECT c.id
   FROM customers c
   LEFT JOIN orders o ON o.customer_id = c.id
   WHERE o.id IS NULL;

4. Top 3 products per region
   WITH ranked AS (
     SELECT region, product,
            SUM(revenue) AS rev,
            ROW_NUMBER() OVER (
              PARTITION BY region
              ORDER BY SUM(revenue) DESC
            ) AS rn
     FROM orders
     GROUP BY region, product
   )
   SELECT region, product, rev
   FROM ranked
   WHERE rn <= 3;

5. Month-over-month change
   WITH m AS (
     SELECT month, SUM(revenue) AS rev
     FROM orders
     GROUP BY month
   )
   SELECT month, rev,
          rev - LAG(rev) OVER (ORDER BY month) AS diff
   FROM m;

Data quality checks to practise:

1. Count nulls
   SELECT
     SUM(CASE WHEN customer_id IS NULL THEN 1 ELSE 0 END) AS null_cust,
     SUM(CASE WHEN revenue IS NULL THEN 1 ELSE 0 END) AS null_rev
   FROM orders;

2. Find duplicates
   SELECT id, COUNT(*)
   FROM orders
   GROUP BY id
   HAVING COUNT(*) > 1;

3. Orphan rows
   SELECT o.id
   FROM orders o
   LEFT JOIN customers c ON c.id = o.customer_id
   WHERE c.id IS NULL;

4. Date range sanity check
   SELECT MIN(order_date), MAX(order_date)
   FROM orders;

5. Value distribution
   SELECT status, COUNT(*)
   FROM orders
   GROUP BY status;

Business analysts who can run these checks
become trusted faster than analysts who only
write reports.

Every SQL project in your portfolio should follow
this template:

1. Business question
   "Which regions underperformed in the last quarter?"

2. Data
   - source (open dataset or public sample)
   - tables used
   - date range

3. Queries
   - stored in .sql files, one per question
   - commented to explain each CTE

4. Result
   - the query output (CSV or screenshot)
   - one chart if possible

5. Recommendation
   - one sentence the business could act on

6. Limitations
   - what the data does not tell you

If you can complete this template for two
projects, you have more proof than most
candidates in the pipeline.

SQL portfolio README checklist:

□ Title states the business question
□ Data source is linked
□ Tables and date range listed
□ SQL files included in the repo
□ Queries have comments explaining each CTE
□ Result table or screenshot attached
□ One chart included
□ Recommendation written in one sentence
□ Limitations stated clearly
□ Rerun instructions included

Extras that help:
- a data dictionary
- a note on which join types were used
- a short paragraph on what you would do
  with more time

30-Day SQL Plan — Daily Schedule:

7:00 AM — Wake up, quick review of yesterday
8:00 AM — 20 min reading or video on the day's topic
9:00 AM — 45 min writing queries against real data
   - Week 1: basics and filters
   - Week 2: joins and aggregation
   - Week 3: CTEs and window functions
   - Week 4: portfolio and interview prep
1:00 PM — 30 min solving one interview-style question
5:00 PM — 15 min reviewing errors and notes
8:00 PM — 15 min explaining a query out loud

Rules:
- type every query by hand
- always check for nulls and duplicates
- save queries in a repo as you go
- explain each query in one sentence

Week 1 Review:
□ Can I write a JOIN without looking it up?
□ Can I explain the difference between WHERE and HAVING?
□ Have I queried a real dataset?

Week 2 Review:
□ Can I choose INNER vs LEFT JOIN correctly?
□ Can I group by two dimensions at once?
□ Have I checked for nulls before reporting?

Week 3 Review:
□ Can I use ROW_NUMBER with PARTITION BY?
□ Can I compute a month-over-month change?
□ Can I read someone else's CTE query?

Week 4 Review:
□ Do I have two documented SQL projects?
□ Can I explain each query in 30 seconds?
□ Have I practised a live SQL round out loud?

If any answer is "no", repeat that week rather
than moving on.