Data Analytics Interview: SQL Questions and Answers

1What SQL Interviews Really Test

A data analytics SQL interview tests whether you can turn a business question into a correct query and explain your reasoning out loud. Interviewers care less about obscure syntax and more about whether you choose the right join, aggregate correctly, and handle edge cases like nulls and duplicates.

The good news is that the question bank is small. Most rounds recombine the same core ideas: filtering, joining tables, grouping and aggregating, ranking with window functions, and finding the Nth-highest value. If you can fluently produce those five patterns and talk through them, you will handle the majority of what you are asked.

This guide walks through the most common questions with worked answers. Read each one, then close the page and rewrite the query yourself — recall is what sticks, not recognition.

2Joins: The Question You Will Definitely Get

Expect a question like 'return every customer and their total orders, including customers who never ordered.' The word 'including' is the tell: you need a LEFT JOIN so unmatched customers survive. An INNER JOIN would silently drop them, which is the classic trap.

The answer is roughly: SELECT c.name, COUNT(o.id) FROM customers c LEFT JOIN orders o ON o.customer_id = c.id GROUP BY c.name. Note that you count o.id, not the star — COUNT of a column ignores nulls, so a customer with no orders correctly returns zero instead of one.

Be ready to explain the difference between joins in one clean sentence each. An INNER JOIN keeps only matching rows; a LEFT JOIN keeps all left rows and fills the right side with nulls when there is no match. A self join joins a table to itself, useful for hierarchies like employee-and-manager in the same table.

3GROUP BY, WHERE, and HAVING

A favourite question: 'find customers who placed more than five orders.' The subtlety is that you cannot filter on COUNT with WHERE, because WHERE runs before rows are grouped. You filter aggregated results with HAVING.

The query is: SELECT customer_id, COUNT(*) AS order_count FROM orders GROUP BY customer_id HAVING COUNT(*) > 5. If the interviewer then adds 'only orders from 2026', you add WHERE order_date >= '2026-01-01' before the GROUP BY, because that filter applies to individual rows.

4Find the Second-Highest Salary

This is the single most-asked SQL interview question, and interviewers want to see that you handle ties and empty results gracefully. There are two clean approaches.

The window-function approach uses DENSE_RANK: SELECT DISTINCT salary FROM (SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk FROM employees) t WHERE rnk = 2. DENSE_RANK is preferred over ROW_NUMBER here because it treats tied salaries as the same rank, which is usually what 'second-highest' means.

The subquery approach is: SELECT MAX(salary) FROM employees WHERE salary < (SELECT MAX(salary) FROM employees). It reads nicely and returns null cleanly when there is no second value. Knowing both, and being able to say why you would pick one, is exactly the flexibility interviewers reward.

5Window Functions: Ranking and Running Totals

Window functions separate junior candidates from ready-to-hire analysts. The core idea: they compute across a set of rows related to the current row without collapsing them into one output row like GROUP BY does.

For 'rank products by revenue within each category', use ROW_NUMBER() OVER (PARTITION BY category ORDER BY revenue DESC). The PARTITION BY restarts the numbering for each category. For a running total of daily sales, use SUM(amount) OVER (ORDER BY sale_date). To compare each month to the previous one, LAG(revenue) OVER (ORDER BY month) gives you the prior row's value.

• ROW_NUMBER assigns a unique sequential number, even to ties.
• RANK leaves gaps after ties (1, 1, 3); DENSE_RANK does not (1, 1, 2).
• LAG and LEAD reach into the previous or next row for period-over-period comparisons.
• SUM or AVG with OVER produces running and moving aggregates without a GROUP BY.

6Finding and Removing Duplicates

'How would you find duplicate emails?' The answer is a GROUP BY with HAVING: SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1. Simple, and it directly demonstrates the WHERE-versus-HAVING understanding from earlier.

The follow-up is usually 'how would you delete the duplicates but keep one?' A robust answer uses ROW_NUMBER: number rows within each email partition and delete everything where the number is greater than one. This shows you can combine window functions with data-cleaning logic, which is real analyst work.

7Handling NULLs Correctly

Nulls cause more wrong answers in interviews than any syntax mistake. Remember that null is 'unknown', not zero or empty, so almost any comparison with it returns unknown rather than true.

You cannot write WHERE commission = NULL; you must write WHERE commission IS NULL. To substitute a default, use COALESCE(commission, 0), which returns the first non-null argument. When you aggregate, remember COUNT(column) ignores nulls while COUNT(*) does not — a distinction interviewers love to probe.

8Talking About Performance

Even in an analytics role, expect a light performance question. You do not need deep internals — you need to sound like someone who has felt a slow query.

Good talking points: indexes speed up filtering and joining on the indexed columns but slow down writes; SELECT * pulls unnecessary columns and should be avoided in production queries; filtering early (in WHERE) reduces the rows later steps must process; and a query that works on a thousand rows may crawl on ten million, so you think about the data volume, not just correctness.

9How to Answer Out Loud

Writing the query is only half the test. Interviewers score how you think, so narrate as you go. State your assumptions ('I'll assume order_date is not null'), name the pattern ('this is a LEFT JOIN because we keep all customers'), then write, then read it back in plain English.

If you get stuck, say what you are trying to do. 'I want to filter after counting, so I need HAVING' earns partial credit even before you finish. Silence earns nothing. Practise talking through three queries a day until it feels natural.

10Frequently Asked Questions

What SQL topics should I prioritise for a data analytics interview? Focus on joins, GROUP BY with HAVING, window functions, subqueries, and null handling. These five patterns cover the large majority of questions asked in analytics rounds.

Do I need to memorise exact syntax? You need fluent, correct syntax for the common patterns, but interviewers care more that you pick the right approach and can explain it. Minor typos are usually forgiven if your logic is sound.

Is the second-highest salary question really that common? Yes — it or a close variant appears constantly because it tests joins or window functions, ties, and edge cases in one small problem. Prepare both the subquery and DENSE_RANK solutions.

How is HAVING different from WHERE? WHERE filters individual rows before grouping, while HAVING filters grouped results after aggregation. Any condition using COUNT, SUM, or AVG must go in HAVING.

How long does it take to get interview-ready with SQL? With focused daily practice, most beginners reach interview readiness in four to six weeks. Solving and re-solving pattern questions matters far more than the total hours.

Can I learn all of this for free? Yes — SkillVeris offers free SQL and data analytics study material with worked examples, so you can practise every pattern in this guide without paying for a course.

11Next Steps

You now have the core question bank: joins that respect edge cases, correct grouping and filtering, window functions for ranking and running totals, and clean null and duplicate handling. Rewrite each query from memory, then invent small variations — that is how the patterns become automatic under pressure.

You can build all of this for free on SkillVeris, where the SQL and data analytics material is designed around the exact patterns interviewers test. Pair the reading with a hands-on practice database, narrate your answers aloud, and walk into the interview ready to explain, not just recite.