You need less SQL than you think

Let's not overthink it

You watched the 4-hour SQL course. Then you did 150 problems on some practice site. You can write a self-join in your sleep. You memorized the difference between RANK, DENSE_RANK, and ROW_NUMBER. You have a Notion page full of window function syntax you review before bed.

You’re still not getting interviews. Or you’re getting them and freezing anyway.

So you go back and grind more SQL, because clearly the problem is you don’t know enough.

The problem is you’re studying the wrong 80%.

Here’s what an actual SQL screen looks like from the other side of the table. I’ve watched enough of these to know the pattern. Three questions. Two of them are a JOIN and a GROUP BY with a filter. The third is a slightly harder aggregation, maybe a window function if the company is fancy. That’s the whole test.

The candidate who spent two months on recursive CTEs and pivot logic sits down, gets asked “pull total revenue by month for customers who signed up in Q1,” and stares at it. Not because they can’t write a GROUP BY. Because nobody ever made them turn a sentence like that into a query. They practiced answering SQL questions. They never practiced answering business questions with SQL.

That gap is the entire job. The syntax is the easy part and everyone treats it like the hard part. Knowing SQL and using SQL to answer a question someone actually asked are two different skills, and only one of them shows up on your resume screen.

Let me break down how much you actually need.

1. The job runs on about six things, and you already half-know them.

SELECT. WHERE. JOIN, mostly LEFT and INNER. GROUP BY with aggregates like SUM, COUNT, and AVG. A couple of window functions, usually ROW_NUMBER and a running total. CTEs to keep long queries readable.

That’s the core. That combination handles the overwhelming majority of real analyst work. Not 60% of it. Closer to 90.

The stuff you’re intimidated by lives in the last 10% and you will Google it the two times a year it comes up, same as every senior analyst does.

2. Advanced SQL is a lookup, not a prerequisite.

Recursive queries. PIVOT and UNPIVOT. Correlated subqueries. Performance tuning. Every one of these is real, and every one of them is something you look up when a specific problem demands it.

You do not need to hold them in your head to get hired. No hiring manager is quizzing a junior candidate on query execution plans. If one does, that’s a signal about the company, not about you.

The senior people you’re trying to become do not have this memorized either. They have it bookmarked. The difference between them and you isn’t recall. It’s that they know a recursive CTE is the right tool for the org-chart problem in front of them, then they go look up the syntax.

Let’s take a real example and break it down: "Show me the top 5 customers by revenue in the last 90 days, excluding refunds."

The query to answer this is…

Seems a bit long for a simple questions but let’s do this together.

• “top 5” is answered by the ORDER BY total_revenue DESC + LIMIT 5

• “customers” is answered by the JOIN customers c ON … (the revenue lives in orders, the names live in customers, so you join!)

• “by revenue” is answered by SUM(o.amount) AS total_revenue + the GROUP BY c.customer_name

• “in the last 90 days” is answered by WHERE o.order_date >= CURRENT_DATE - INTERVAL '90 days'

• “excluding refunds” is answered by AND o.status != ‘refunded’

3. The actual test is translation, and almost nobody practices it.

Here is the skill that separates people who pass SQL screens from people who don’t: reading a vague, half-specified business question and knowing which tables, joins, and filters it maps to.

“Which products are underperforming this quarter” is not a SQL question. It’s a question you have to interrogate first. Underperforming compared to what. Which quarter. Do returns count. Is a product a SKU or a category. By the time you’ve answered those, the query writes itself. The SQL was never the hard part. The thinking in front of the SQL was.

You can drill this. Take a schema, generate business questions against it, and write the query for each one out loud before you touch the keyboard. Do that fifty times and interview questions stop feeling like traps.

This is literally what the SQL block of the 90-day sequence walks you through, one business question mapped to one query at a time, so translation becomes automatic instead of the thing you freeze on.

4. Depth on the core beats breadth across the syntax.

Knowing JOINs cold beats knowing forty functions at surface level.

Most people who “know SQL” fall apart the moment a query needs three joins and one of them is a LEFT JOIN where the null handling actually matters. They can name every join type. They can’t reason about what happens to their row count when the join fans out.

That’s the depth that shows. An interviewer can tell in one question whether you understand what a JOIN is doing to your data or whether you just memorized the keyword. Go deep on the six core things until you can predict the shape of the output before you run it. That’s worth more than another twenty functions you’ll never use.

5. On the job, you inherit SQL. You rarely write it from scratch.

This is the part no tutorial prepares you for. Day one at a real job, you’re handed a 200-line query someone wrote two years ago and told to figure out why the numbers look off.

You will spend more time reading other people’s SQL than writing your own. Messy SQL, undocumented SQL, SQL with a CTE named “temp2.” The skill is following someone else’s logic and spotting where it breaks, not composing an elegant query on a blank page.

• At the left join order_items oi line → “This is where the number breaks. Joining to order_items multiplies every order row by its number of line items. An order with 4 items now counts its revenue 4 times.”

• At sum(t.amount) → “So this SUM is inflated. It’s adding the same order amount once per line item, not once per order.”

• At the temp2 CTE → “temp2 does nothing. It’s a copy of temp1. Dead code you inherit and have to read past anyway.”

• At where order_date >= '2024-01-01' (optional) → “No upper bound. Is this supposed to be one year or everything since? Nobody documented it.”

Practice reading SQL, not just writing it. Pull real queries off GitHub or dbt project repos and trace what they do. It’s unglamorous and it’s exactly what the job is.

6. Knowing when your answer is wrong is the senior skill.

Anyone can write a query that returns a number. The number being right is a separate question.

A junior analyst runs the query, sees 4,812, and reports 4,812. A good analyst runs it and immediately asks whether 4,812 is even plausible. Should this be in the thousands or the millions. Did that LEFT JOIN just double my rows. Is this suspiciously round.

That instinct, sanity-checking your own output before anyone else has to, is what makes people trust your work. It is also completely absent from every SQL course, because courses give you problems with known answers. The job gives you problems where you’re the only check.

So how much SQL do you actually need? Enough to answer a real question and enough to know when your answer is lying to you. That’s a much smaller pile of syntax and a much bigger pile of judgment than the tutorials sold you.

The people getting hired aren’t the ones who know the most SQL. They’re the ones who can sit down in front of a messy schema and a vague question and produce a number they’d stake their name on.

If you want the version of this that’s already sequenced, Analyst Hive is a 90-day daily-task system that takes you from tutorial SQL to job-ready SQL, one task a day, built around exactly the translation and depth work above instead of another list of functions to memorize. It’s for people who are tired of grinding syntax and still freezing in interviews. If that’s you, start here:

What’s the SQL question that tripped you up in an interview or on the job? Reply with the actual prompt, I want to see which ones are still catching people.

P.S. If you’re currently three window functions deep into a course and quietly panicking that it’s not enough, close the tab. You’re past the point of diminishing returns. Go write ten queries against a real dataset instead.

Talk soon,
Ian