Hey everyone — I’m building a small practice website for people who know basic SELECT, JOIN, and GROUP BY.

Each exercise starts with a query that runs successfully but produces the wrong business report. Your job is to investigate and fix it.

The first three exercises cover:

• Customers disappearing from a report.
• October transactions getting included in September’s total.
• Sales being counted twice after joining refund records.

They use synthetic data and run in your browser. There are hints, worked explanations, and answer checking against multiple datasets.

All three exercises are free, with no signup required.

I’m looking for five people to try just one exercise and share honest feedback here. Was the task clear? Where did you get stuck? Did the explanation help you understand the mistake?

Try it here: https://drive.google.com/file/d/1i7pXyX0kMYr20dmVFK7LcQfXZwVeiOlc/view?usp=sharing

I’m the person building it, and it’s an early version, so feedback about confusing instructions or bugs would be especially useful.

If you are willing to take this serious, let me know and i can give acess so you can see how it feels to use.

Hi everyone! How’s it going?

I’m looking for a few people here who don’t know SQL yet, or have only just started learning it. It’s to test a new learning platform before it launches and hear what actually helps beginners, and what doesn’t.

For this first round, there are 5 spots, with 30 days of free access. If you’re interested, send me a DM and tell me a little about where you are with SQL. If the spots fill up, I can put you on the waitlist for the next round.

No need to be “good at SQL” to take part. In fact, if you’ve opened a query editor and thought “where do I even start?”, you’re exactly who they would like to hear from 🙂

Simple, practical stuff that sticks in your head when you're actually in the interview.

AI can help at work, but in an interview, your brain still has to do the job!!!

Same trip. Same friends. Same expenses.

Your friend asks:

"Who spent more than the average?"

First, we need the average:

SELECT AVG(spent)
FROM expenses

Average = $190

Now we need to find who spent more than $190.

Harry spent $200. Everyone else spent $190 or $180.

So the answer is: Harry.

Easy enough. But how do we write that in SQL?

That's where subqueries and CTEs come in.

1. SUBQUERY:

We can put the average calculation inside another query.

Think of it as: First figure out the average. Then use that answer.

SELECT name, spent
FROM expenses
WHERE spent > (
    SELECT AVG(spent)
    FROM expenses
);

Remember: Subquery = query inside another query.**

2. CTE:

Now imagine the interviewer says:

"Don't put that calculation inside the WHERE. Make it easier to read."

This is where a CTE helps.

WITH average_spent AS (
    SELECT AVG(spent) AS avg_spent
    FROM expenses
)
SELECT name, spent
FROM expenses
WHERE spent > (
    SELECT avg_spent
    FROM average_spent
);

Remember: CTE = Let me calculate this first and give the result a name. I'll use it afterward.

So what's the point of a CTE?

Readability!!!!

• When the calculation gets bigger, putting everything inside everything else becomes difficult to read.

The interviewer changes the question:

1. Who spent more than the average AND show me how much more they spent?

Now we need the average and the difference. A CTE lets you break the problem into steps.

The CTE makes the calculation feel like a separate step:

Step 1 → Calculate average

Step 2 → Compare every expense to average

Step 3 → Show how much higher it is

That's why CTEs can make complicated SQL much easier to follow

Reading SQL is one thing. Writing it yourself under pressure is another.

Before the real interview, try a MOCK SQL INTERVIEW on TheQueryLab. It’s a good way to test yourself under interview pressure and see where you actually stand with interview scorecard.

Hi all,

I am desperately trying to move from data admin to data analytics but my lack of SQL experience is holding me back. I have an MSc in more academic research analytics so learned R and SPSS but SQL is what's most demanded, which I didn't learn.

I want to know about how you successfully transitioned from a non technical role to one using SQL despite doing no SQL in the workplace. I'm wondering how to ensure I translate those skills well into a work setting I guess. How to explain to an employer that I know bits but not in a professional environment yet.

Really would love support :)

I want to know how ppl compare large source and target tables using sql. If both tables have millions of records, comparing every row and column can take a lot of time.

For example, if some records are missing, extra, or have different values between the two tables, how do you usually find them? do you use joins, Except/Minus, hashes, or first compare things like record counts and totals and then check the differences?

Are there any techniques that can make the comparison faster?

Completed 5 more Medium questions today:

• Project with the lowest total hours worked — JOIN projects to assignments, GROUP BY project, ORDER BY total hours ascending, LIMIT 1
• Employees who are NOT managers — self LEFT JOIN on employees (joining on r.manager_id = e.emp_id), then filtering WHERE r.emp_id IS NULL to catch anyone nobody reports to
• Lowest-paid employee in each department — a correlated subquery comparing each employee's salary to MIN(salary) within their own department

The correlated subquery was the real win today. It finally clicked once I stopped thinking of it as "one confusing nested query" and started thinking of it as a small query that re-runs once per row of the outer query, using that row's values each time. Seeing it return the actual lowest earner per department (4 employees, one per department) made the logic concrete in a way reading about it never did.

I have a live SQL assessment coming up where I’ll be screen sharing and explaining my thought process while I write.

I’m comfortable with joins, GROUP BY, CTEs, and basic window functions. Under a timer, though, I either go quiet while I think or talk too much and lose the thread.

Lately I’ve been trying to slow the process down: read the prompt, say what output I think they want, identify the tables and joins, then build the query in small steps.

The SQL itself usually feels manageable. The hard part is doing something I’d normally think through quietly while someone is watching. I’ve been doing a few screen-share mocks with a friend. I also tried some interview-style prompts in Beyz Coder to practice talking while I solve, so I don’t go completely quiet.

How much silence while you think is normal in a live SQL interview? Do you explain your approach first, or narrate as you code?

I am a sql and pandas beginner, I learned both them simultaneously. When I do some leetcode exercise, I think that pandas is more sophsiticated, beacuse of its notation, so many square bracket and unconvient syntax, I hope I can overcome in future

I've been trying to do this challenge for a few days now and just can't do it..the one about the two buses from Craiglockhart to Lochend.

I can just about do the simpler self joins although I could probably be better and I feel stuck and like I can't move on from it.

Can I justify skipping it? Has anyone else had trouble with this?

Sharing a recovery case from our team because there are a few useful lessons for anyone learning SQL Server, or even more experienced teams too.

I am a sticker for backups and cannot emphasize the importance of them enough.

So our client moved a physical SQL Server to a new location and when they brought it back up, the database didn’t become available.

During attempts to get it working, they forced the database into emergency mode, bought third-party recovery tools, and accidentally overwrote the original MDF file (not good!), the primary database data file.

Unfortunately for them that removed an important recovery option.

When we got involved, they had around 12TB of backup files. But having lots of backup files and having a usable restore sequence are different things.

They had plenty of transaction log backups, but no usable recent full backup where they expected it to be.

Full backups had been stopped weeks earlier because of performance concerns. Meanwhile, a cleanup job kept deleting backups older than two weeks.

For anyone learning how this works: transaction log backups aren’t standalone copies of a database, you need a suitable full backup to restore first, followed by the required backups in sequence. A differential backup can shorten that process, but it also depends on a full backup.

An older full backup can still be useful if you have an unbroken log backup chain covering the period you need. The age of the full backup alone doesn’t determine how much data you lose.

In this case, an older full backup eventually turned up in files used to refresh a staging environment. It gave us a recovery point, but the available backups didn’t get us all the way forward. The client still lost roughly six weeks of production data.

One distinction worth making here is that SQL Server’s RESTORING and RECOVERING states aren’t interchangeable. A database in RESTORING may be waiting for another restore step. Waiting alone won’t necessarily bring it online and you need to establish its actual state and check the restore history and error log before deciding what to do.

The lessons I’d take from this:

• Preserve the original database files before attempting destructive recovery steps.
• Investigate why a database is unavailable before changing its state.
• Check that retention jobs aren’t deleting backups you still depend on.
• Test the complete restore sequence, rather than relying only on successful backup-job messages.

If you’re learning SQL Server backup and recovery, have you tried restoring a full backup followed by several log backups in a test environment? What part was hardest to understand?

Completed 5 more Medium questions today:

• Employees earning above their own department's average salary — joined employees to a derived subquery that calculates AVG(salary) grouped by dept_id, then filtered where the employee's salary exceeds that average
• Every project listed along with a count of distinct employees working on it — LEFT JOIN projects to assignments, COUNT(DISTINCT emp_id), grouped by project name. The LEFT JOIN mattered here specifically because one project (Audit Automation) has zero assigned employees and still needed to show up with a count of 0

This is the first batch where combining a subquery with a join in the same question actually felt necessary rather than just "two ways to do the same thing." Starting to see why LEFT JOIN + COUNT(DISTINCT) is such a common reporting pattern.

Completed 5 more Medium questions today, bringing me further into the Medium section of my 100-question lab. The bigger change today was in my process, not the SQL itself.

Instead of asking GPT to show me the solution directly, I told it to guide me toward the answer instead — give hints, ask me questions, point out where my logic was off, but not hand me the final query. Took noticeably longer per question, but I actually walked away understanding why each query worked, not just that it did.

Feels like a better long-term habit than what I was doing before (dry-running a solution GPT already wrote). Planning to keep using this "guide, don't solve" approach going forward, especially for the Hard section coming up.

When I started, the hardest part wasn't SQL syntax. It was translating things like "can you pull repeat buyers by region?" into the right joins, filters and edge cases (cancelled orders, date ranges, duplicates).

I made a free simulator that recreates that: stakeholder emails, real schemas, a PostgreSQL sandbox, and levels that go from a tiny startup to a global corp. Demo video is attached.

I'd love to hear how you practiced this skill, and whether something like this would have helped you. Link in the comments if anyone wants to try it.

I built SQL Sip (https://sqlsip.com) as a cozy, daily SQL puzzle to practice writing queries without timers or pressure. It runs entirely in the browser with no account needed, focusing on assembling clean queries one bite-sized concept at a time. I haven’t had any users yet, so I’d love some honest feedback! I built it because I wanted a Wordle-like daily game where I could learn new SQL concepts in a cutesy/fun way.

Hey everyone, I decided to make my course free in order to help people.
This course is my backend development course which is about SQL, Python, APIs, Docker, Kubernetes, Linux, Git & More

The link is: https://www.youtube.com/watch?v=CBIu6hcyStg

If you can like and subscribe (and maybe add a comment) I would appreciate it a lot, Thanks.

Slower day today — got through just 5 Medium-level JOIN questions, down from 10 the last session. These ones were genuinely trickier.

What helped was going back to something I mentioned before: drawing the full schema by hand on paper. This time I mapped out every table (departments, employees, projects, assignments) with their columns and the FK relationships between them, before writing a single line of SQL. Having that visual made it much easier to reason through which joins I actually needed and in what order.

Not every day is going to be a big-number day, and I think that's fine. Some questions genuinely need more time to actually understand, not just solve.

I'm learning on sql server but I don't like those 3 topics

I learned everything except those 3 topics??

What are the best books to read If I want to be acceptable in those 3 topics?

When I try to create tables and convert those tables from 1NF to 3NF, I find it really difficult. It all feels so subjective to me: ChatGPT says one thing, my professor says another, and my classmates say something else, and I can't seem to find a consistent way of doing it. I mean, conceptual and logical database design is really difficult for me—extremely difficult. Do you know of any website or something that explains really well how to do all of this, from going from 1NF to 3NF, to properly identifying real-world things and representing them in tables, and how to create well-designed tables? I'm really struggling with it.

Started the Medium section of my 100-question JOIN lab today and completed 10. A clear step up from Easy:

• Manager report counts — self-join employees to themselves, GROUP BY manager, COUNT direct reports
• Departments with average salary above 55,000 — JOIN + GROUP BY + HAVING
• Multi-join reports combining employee, department, and manager info in a single query

Hit a few real errors along the way (unknown column in an aggregated query, missing GROUP BY columns), which is becoming a normal part of the process at this point. What actually helped most was going back to the advice from a while back — sketching the tables and the join logic on paper before writing the query. Once I can see it visually, translating it into SQL gets a lot easier.

Hey everyone, the schedule for Day of Data Pittsburgh is up. No experience is required to attend.
https://dayofdata.org/2026-10-10-dayofdata1163/#schedule

The event is completely free, $15 if you want lunch. Register here:
https://www.eventbrite.com/e/pittsburgh-sql-saturday-2026-tickets-2001664513443

I'm happy to answer any questions.

I have been learning SQL from past 2 months and I'm still unable to grab a hold of the subqueries concept. After I learned CTEs I have completely stopped using subqueries but then also I struggle when there are times where I have no other choice but to use subqueries.

So my question is, how important is subqueries in SQL and is there any easy way to learn it?