Why Practicing SQL Still Matters When AI Writes It for You

People keep asking me some version of the same question. ChatGPT writes SQL in two seconds, so why would anyone still grind practice problems like it's 2015?

Fair question. I'm a data analyst, I use AI to write SQL every single day, and my answer is the opposite of what you might expect. Practice matters more now, not less. The argument has three parts, and the second one includes a query you can run yourself.

Key takeaways

• Live interview rounds still test unassisted SQL, and they are where the hiring decision gets made.
• AI-generated SQL often runs cleanly and still returns wrong numbers. The join-fanout example below shows exactly how.
• The skills worth training now are architecture intuition and the ability to read code you didn't write.

The interview hasn't gotten the memo

Whatever AI is doing to the day-to-day job, the hiring process still tests you live. A data-analyst interview in 2026 usually includes some mix of these:

• A shared editor, an interviewer watching you type, and a question like "top 3 products per region by revenue". No copilot, no tab-complete.
• "Walk me through why you used a LEFT JOIN here." They don't care about the query. They care whether you understand it.
• A take-home where AI is allowed, followed by a review call where they change one requirement and watch you modify your own submission without starting a new chat.

Interviewers adapted to AI faster than candidates did. Once everyone can hand in a perfect take-home, the live round is where the decision gets made. And the live round is the one thing you can't prompt your way through. Nobody can generate your half of a conversation about NULL semantics, or about why your numbers doubled.

AI writes SQL that runs, looks right, and is wrong

This is the part that "AI will replace analysts" takes keep missing. The dangerous AI query is not the one that throws an error. You'd catch that. The dangerous one executes cleanly and returns plausible numbers that happen to be wrong.

A small, real example. Two tables: orders, and payments. An order can have several partial payments. Every query and output table in this section is an unedited SQLite result; nothing is mocked.

CREATE TABLE orders   (order_id INTEGER PRIMARY KEY, customer TEXT, amount REAL);
CREATE TABLE payments (payment_id INTEGER PRIMARY KEY, order_id INTEGER, paid REAL);

INSERT INTO orders   VALUES (1,'Dana',100),(2,'Avi',200),(3,'Dana',50);
INSERT INTO payments VALUES (10,1,50),(11,1,50),(12,2,200),(13,3,50);

Ask an AI assistant for "total order amount and total paid per customer" and you will very often get exactly this, a clean and professional-looking join:

SELECT o.customer,
       SUM(o.amount) AS total_ordered,
       SUM(p.paid)   AS total_paid
FROM orders o
JOIN payments p ON p.order_id = o.order_id
GROUP BY o.customer;

It runs. This is the actual output:

Dana never ordered 250. She ordered 150. Her first order has two payment rows, so the join duplicated that order before the SUM. This is the classic join-fanout trap. The paid column happens to be correct, the ordered column is inflated by 66%, and nothing anywhere warns you. Put this in a report and your manager will be asking why the numbers don't match the dashboard.

The fix is a question of grain: collapse payments to one row per order before joining.

SELECT o.customer,
       SUM(o.amount) AS total_ordered,
       SUM(pp.paid)  AS total_paid
FROM orders o
JOIN (SELECT order_id, SUM(paid) AS paid
      FROM payments GROUP BY order_id) pp
  ON pp.order_id = o.order_id
GROUP BY o.customer;

Now the honest question. If the first query landed in your editor, would you have caught it? Catching it has nothing to do with memorized syntax. It's pattern recognition: two tables, one-to-many, an aggregate after a join, so check the grain. That reflex doesn't come from reading blog posts, including this one. It comes from getting burned by this exact trap in practice, where being wrong costs nothing.

Your real job now is code review, and the AI is the junior

The realistic future of the analyst role is not "no SQL". It's that AI writes the first draft in seconds and you become its reviewer. Good review rests on two skills, and both are trainable.

The first is knowing the right architecture before you read a single line. Every data question has a correct shape: which table is the base, what grain the output needs, whether you filter before or after aggregating, where a one-to-many join can inflate the numbers. When you know what the solution should look like structurally, you can judge an AI draft in seconds ("it joined the payments before aggregating them, wrong shape") instead of staring at syntax and hoping the bug jumps out. That is how an experienced reviewer catches the Dana query: not by reading harder, but by noticing that the architecture called for a pre-aggregation that isn't there. Architecture also makes your prompts better. A precise prompt is just a well-designed solution described in words.

The second is reading code you didn't write. Writing SQL and reading SQL are different muscles, and reading is the one almost nobody trains. Most candidates have spent years writing their own queries and almost no time deliberately reading someone else's, reconstructing what it actually does, and looking for the place where it lies. That is the whole job of reviewing AI output: read it cold, figure out what it really does rather than what the prompt asked for, check the grain and the NULLs and the join logic, and only then approve. You can't review what you couldn't have written yourself. A reviewer who can't code isn't a reviewer, just a rubber stamp.

Interviews increasingly test these two skills directly. "Here is a query, what's wrong with it?" and "talk me through your approach before you type" are both asking the same thing: can you think in architecture, and can you read?

How to practice in the AI era

Grinding syntax flashcards like it's 2015 really is obsolete. What works now looks different:

1. Sketch the architecture before you type. Thirty seconds, in plain words: base table, output grain, aggregate then join or join then aggregate. This is the same skill that lets you judge an AI draft at a glance, and it's the "talk me through your approach" part of the interview.
2. Solve under interview conditions. No AI, a bit of time pressure, a real schema, real grading. This builds the recall you'll need live.
3. Ask AI for its solution afterwards, and review it like a pull request. Read it cold before running it. Check it against the architecture you sketched. Look for the quiet traps: grain, NULLs, fanout. Half the time you'll pick up a cleaner idiom. The other half you'll catch its bug, which is the exact muscle the AI era pays for.
4. Explain your query out loud. Why this join type, what the output grain is, which rows disappear. This is literally the interview.
5. Practice on edge-case data. Duplicates, NULLs, one-to-many relationships. That's where AI queries quietly fail, and where interviewers hide their twists.

That loop of solve, compare, explain is what AnalystPath's practice flow is built around. Questions run and grade in your browser against real schemas with edge-case rows, so the fanout traps bite you here, where it's free, instead of in an interview or a production dashboard.

Common questions

Is SQL still worth learning in 2026?

Yes, and the bar moved up rather than down. Writing trivial queries is now cheap, so the market pays for the deeper layer: knowing what a correct solution looks like and catching the incorrect one. Job posts for data analysts still list SQL first, and interviews still test it live.

Will AI replace data analysts?

It replaces the typing, not the judgment. Someone still has to frame the question, know the data well enough to smell a wrong number, and review the query before it reaches a dashboard. Analysts who can't do that review are the ones at risk, not the role itself.

Should I use AI while preparing for interviews?

Yes, but in the right order. Solve on your own first, under mild time pressure, then ask AI for its solution and review it like a pull request. Using AI as the first step trains prompting; using it as the second step trains the reviewing skill interviews actually measure.

What SQL topics do interviews focus on now?

The same families as always, with more weight on the traps: joins and grain (the fanout above), window functions for rankings and period comparisons, GROUP BY with edge cases, NULL handling, and date logic. Interviewers increasingly hand you a flawed query and ask what's wrong with it.

The bottom line

AI didn't make SQL skills worthless. It made shallow SQL skills worthless, and it made the deep ones more valuable: architecture intuition, and the ability to read code you didn't write. Someone has to be the human who reviews the query that runs, looks right, and is wrong. In an interview, that someone is you, alone, with an editor open and an interviewer watching.

Try being that person for ten minutes: solve a question free, no signup, or start with the SQL questions, where the join traps live.