SQL Interview Preparation: What Data Engineers Should Know

SQL interviews for data engineering roles test more than syntax. Interviewers want to see whether you can reason about imperfect data, preserve the intended grain, and explain why the result is correct.

Start with the grain

Before writing a query, state what one row in each table represents. An orders table may have one row per order, while order_items has one row per product within an order. Joining them changes the grain. Summing orders.total_amount after that join can multiply revenue.

Ask or clarify:

• Which columns are unique?
• Can a key be null?
• Is this a current-state table or event history?
• How should ties and missing records be handled?
• What should one output row represent?

This short step prevents many common mistakes.

Topics worth practising

Joins and set behavior

Know inner, left, right, and full joins, but concentrate on their effect on rows. Practise finding unmatched records, many-to-many joins, anti-joins, and differences between UNION and UNION ALL.

Aggregation

Be comfortable with GROUP BY, conditional aggregation, distinct counts, and grouping at multiple levels. Understand why filtering before aggregation differs from filtering grouped results with HAVING.

Window functions

Window functions are central to analytical SQL. Practise ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, and aggregate windows. Be able to explain PARTITION BY, ordering, and window frames.

A standard deduplication pattern assigns ROW_NUMBER() within each business key, ordered by the newest update, then keeps row one. State how ties are resolved so the answer is deterministic.

Nulls and three-valued logic

Null is not equal to anything, including another null. Learn IS NULL, COALESCE, and how nulls affect comparisons, joins, counts, and NOT IN. Where nullable values are possible, NOT EXISTS is often easier to reason about than NOT IN.

Dates and time

Practise daily and monthly grouping, rolling periods, interval calculations, and finding gaps. Mention time zones when the business meaning of a day matters. Avoid assuming every month has the same number of days.

Query performance basics

You are not expected to tune every database from memory, but you should recognize costly patterns. Learn how filters reduce data, why indexes can help selective lookups, why functions on indexed columns may prevent efficient access, and how large joins or sorts consume resources.

For analytical engines, understand partition pruning, column selection, and avoiding unnecessary shuffles or repeated scans. Use an execution plan to validate an assumption instead of claiming that one syntax is always faster.

Use a repeatable interview process

1. Restate the problem and output grain.
2. Confirm assumptions and edge cases.
3. Describe the approach in plain language.
4. Write the query in small, named steps.
5. Test it mentally with empty inputs, duplicates, nulls, and ties.
6. Discuss performance only after correctness.

Clear communication matters. If you spot an error, say what failed and correct it. That demonstrates debugging, not weakness.

Practise like the real task

Timed practice is useful, but review is where learning happens. After each question, record the concept you missed and write a second solution. Compare readability and behavior rather than chasing the shortest query.

Build a small local database and create your own edge cases. Then use SkillFutura assessments to identify topics that need another practice cycle. The target is reliable reasoning under time pressure, not memorizing a library of answers.