u/Advanced_Reindeer195

Kept running into the same problem when I was learning SQL — tutorials teach you one concept at a time but you never have everything in one place when you actually need it.

So I made a one-page reference. Here's a chunk of it:

**SELECT & Filter**

SELECT column1, column2 FROM table WHERE condition;

SELECT DISTINCT column FROM table;

SELECT * FROM table WHERE column LIKE '%pattern%';

SELECT * FROM table WHERE column IN ('val1', 'val2');

SELECT * FROM table WHERE column BETWEEN 10 AND 50;

**Aggregations**

SELECT COUNT(*), AVG(salary), SUM(revenue)

FROM table

GROUP BY department

HAVING COUNT(*) > 5;

**JOINs**

-- INNER: only matching rows

SELECT * FROM orders o INNER JOIN customers c ON o.customer_id = c.id;

-- LEFT: all from left table + matches from right

SELECT * FROM customers c LEFT JOIN orders o ON c.id = o.customer_id;

**CTEs**

WITH top_earners AS (

SELECT name, salary, RANK() OVER (ORDER BY salary DESC) as rnk

FROM employees

)

SELECT * FROM top_earners WHERE rnk <= 10;

The full version also covers window functions, CASE statements, date functions, string manipulation, and indexing tips — all on one printable page.

What else would you want on a SQL cheat sheet? Trying to make sure I'm not missing anything obvious.

---

Edit: Lot of people asking for the full version. DM me and I'll send you the link.

I've been helping career switchers prep for data analyst and junior dev interviews. After reviewing a bunch of interview rounds, I noticed the same questions recycled constantly — and self-taught people tend to bomb them because they studied syntax, not problem-solving.

Here are 5 that trip up almost everyone:

**1. What's the difference between WHERE and HAVING?**

"HAVING is for groups" is technically correct but won't impress anyone. They're testing if you understand SQL's execution order (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY). WHERE filters rows before grouping, HAVING filters after.

**2. Write a query to find the second-highest salary.**

Subquery approach works but feels junior:

SELECT MAX(salary) FROM employees WHERE salary < (SELECT MAX(salary) FROM employees)

Window function approach shows depth:

SELECT salary FROM (

SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) as rnk

FROM employees

) t WHERE rnk = 2

Know both. Explain the tradeoff.

**3. How do you find duplicate rows?**

GROUP BY + HAVING COUNT(*) > 1 is the baseline. Wrap it in a CTE for readability and mention that in the interview — it shows you write production-quality SQL, not just "correct" SQL.

**4. Explain INNER JOIN vs LEFT JOIN vs FULL OUTER JOIN.**

If you can explain this with a Venn diagram on a whiteboard in 30 seconds, you pass. Most people fumble because they memorized definitions instead of visualizing the data.

**5. A table has 1M rows and your query takes 45 seconds. How do you optimize it?**

This is where most self-taught people freeze. Framework:

- Check if there's an index on your WHERE/JOIN columns

- Run EXPLAIN/EXPLAIN ANALYZE to read the query plan

- Stop using SELECT * — only pull columns you need

- Check if you're doing unnecessary subqueries that could be JOINs

These 5 are the ones I see people get wrong most often. Happy to share more if this is useful.

---

I put together a full bank of 20 with detailed answers and what interviewers are actually testing for. DM me if you want it.

I've been helping career switchers prep for data analyst and junior dev interviews. After reviewing a bunch of interview rounds, I noticed the same questions recycled constantly — and self-taught people tend to bomb them because they studied syntax, not problem-solving.

Here are 5 that trip up almost everyone:

**1. What's the difference between WHERE and HAVING?**

"HAVING is for groups" is technically correct but won't impress anyone. They're testing if you understand SQL's execution order (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY). WHERE filters rows before grouping, HAVING filters after.

**2. Write a query to find the second-highest salary.**

Subquery approach works but feels junior:

SELECT MAX(salary) FROM employees WHERE salary < (SELECT MAX(salary) FROM employees)

Window function approach shows depth:

SELECT salary FROM (

SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) as rnk

FROM employees

) t WHERE rnk = 2

Know both. Explain the tradeoff.

**3. How do you find duplicate rows?**

GROUP BY + HAVING COUNT(*) > 1 is the baseline. Wrap it in a CTE for readability and mention that in the interview — it shows you write production-quality SQL, not just "correct" SQL.

**4. Explain INNER JOIN vs LEFT JOIN vs FULL OUTER JOIN.**

If you can explain this with a Venn diagram on a whiteboard in 30 seconds, you pass. Most people fumble because they memorized definitions instead of visualizing the data.

**5. A table has 1M rows and your query takes 45 seconds. How do you optimize it?**

This is where most self-taught people freeze. Framework:

- Check if there's an index on your WHERE/JOIN columns

- Run EXPLAIN/EXPLAIN ANALYZE to read the query plan

- Stop using SELECT * — only pull columns you need

- Check if you're doing unnecessary subqueries that could be JOINs

These 5 are the ones I see people get wrong most often. Happy to share more if this is useful.

---

I put together a full bank of 20 with detailed answers and what interviewers are actually testing for. DM me if you want it.