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

Popular posts from this blog

How to fetch data from SnowFlake using Excel VBA?

How to clear Tableau Desktop Qualified Associate Exam (TDQA 10).

All you need to know about the Google Data Studio