Data Engineering Fundamentals, Part 1: Why SQL Is Still Your Most Important Skill
This is the first post in a 5-part series on data engineering fundamentals. We'll go from SQL, to Python, to ELT/ETL tools, to data warehousing with Snowflake, and finally to visualisation. Part 2 covers Python basics, link at the bottom.
Why SQL, even in 2026?
Every modern data platform, Snowflake, Databricks, Fabric, Matillion, dbt, still expects you to think in SQL underneath the interface. Cloud platforms change every few years. SQL has stayed the primary way to query and reason about structured data for decades. If you only master one skill in data engineering, make it this one.
Important concepts you actually need to know
Joins, properly understood. Not just INNER vs LEFT, but what happens to row counts when a join key isn't unique on one side, and why an unexpected LEFT JOIN can silently multiply your row count.
Window functions. ROW_NUMBER, RANK, DENSE_RANK, and aggregate functions used with OVER() let you calculate running totals, rankings, and comparisons across rows without collapsing your result set the way GROUP BY does. This is one of the biggest gaps between beginner and intermediate SQL users.
CTEs (Common Table Expressions). Writing a query as a series of named, readable steps using WITH is far easier to debug and maintain than nesting five subqueries inside each other.
Aggregations and GROUP BY logic. Understand exactly which columns must appear in GROUP BY, and how HAVING differs from WHERE, filtering after aggregation instead of before.
Query execution order. SQL is read top to bottom, but executed in a different order, FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY. Understanding this explains a lot of "why can't I reference this alias here" confusion.
Writing efficient queries
Filter as early as possible. Apply WHERE conditions before joining large tables where you can, rather than joining everything first and filtering last.
Avoid SELECT *. Pulling only the columns you need reduces I/O and makes downstream code more predictable when table schemas change.
Understand indexing, even in a columnar warehouse. In a warehouse like Snowflake, clustering keys serve a similar purpose to indexes, they help the engine prune data it doesn't need to scan. Know your platform's version of this concept.
Use EXPLAIN or query profiling. Every major platform provides a way to see the query execution plan. Get in the habit of checking it on slow queries instead of guessing what's expensive.
Prefer window functions over self-joins. If you're joining a table to itself to compare rows, a window function can often do the same thing with less code and better performance.
Common SQL interview questions with solutions
-Find the second highest salary in a table.
SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);
-Find duplicate records in a table.
SELECT email, COUNT(*)
FROM users
GROUP BY email
HAVING COUNT(*) > 1;
-Calculate a running total of sales by date.
SELECT sale_date, amount,
SUM(amount) OVER (ORDER BY sale_date) AS running_total
FROM sales;
-Find the top 3 highest paid employees per department.
SELECT * FROM (
SELECT employee_id, department_id, salary,
DENSE_RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rnk
FROM employees
) ranked
WHERE rnk <= 3;
-Find customers who placed an order every month this year.
SELECT customer_id
FROM orders
WHERE EXTRACT(YEAR FROM order_date) = 2026
GROUP BY customer_id
HAVING COUNT(DISTINCT EXTRACT(MONTH FROM order_date)) = 12;
These five patterns, ranking, running totals, duplicate detection, and grouped conditionals, cover the majority of what shows up in real interviews, because they cover the majority of what shows up in real data engineering work too.
Where to go from here
SQL is the foundation everything else in this series builds on. Once you're comfortable with the concepts above, Part 2 moves into Python, which is where you'll handle the logic SQL alone can't, automation, APIs, and custom transformations.
[Continue to Part 2: Python Basics Every Data Engineer Should Know]

Comments
Post a Comment