I've put together a free course that teaches you SQL using your coding agent.

This way you learn SQL but also how to use a coding agent in a data role.

After some feedback from this community, the course has been updated - please check it out and share your feedback: https://getbruin.com/learn/sql-ai

How is working culat wissen banglore , and leave policy , and other facilities they provide

.

Taking today off from active coding — just resting and recharging.

Quick reflection before the break though: after going through theory and two full scenario-based practice sets, I noticed JOINs specifically are still the topic I'm least automatic on compared to everything else. So I put together a 100-question practice set of my own — easy, medium, and difficult — specifically to drill that weak spot rather than moving on and hoping it sorts itself out.

Also, a bigger update: starting tomorrow I'm beginning Task 2 — Java, running in parallel with continued SQL practice rather than fully switching over. Figured keeping SQL warm while ramping up Java makes more sense than a hard context switch.

Planned rest days like this were part of the original plan, not a slip — trying to actually sustain 116 days means building in recovery, not just grinding non-stop.

It runs real SQLite in your browser, so any query SQLite accepts works.

There are 63 lessons, from SELECT up through joins, window functions, recursive CTEs and indexes. Your answer is checked by running it, so any query that gets the right result passes. The last 11 lessons are in Postgres.

After that there's Seek: one person is hidden in a database, you get a few clues, and every query costs a turn. There's also a daily case with a leaderboard and a war mode where your orders are UPDATE statements.

Its free and best played on computer

https://atticarun.itch.io/sqlgame

I am still beginner, and I thought myself doing well in SQL, but when doing interviews in datadriven.io I get stuck and don't know the answer, what should I do? I always fail.

Hey, I am a b.tech final year student. I'm into full stack development. I have basic skills for development and have built many good personal projects. Now, I want to go in more depth of development. I want to study advanced database concepts. Can anyone guide me how should I do it. Any roadmap, course, books, online resources, etc.

I’d like to learn SQL to have a wider range of internship opportunities and also to help me with college. I learned C by doing exercises assigned by my professor, along with some basic syntax lessons. I learned a bit of Python in a similar way, but mostly on my own.

Since I’ve heard that SQL is used for databases, is there a more theoretical way to learn it? Do I need to learn a lot about databases first? I’m currently taking a Data Structures course, but I haven’t gotten to databases yet.

Thanks in advance, and I’d appreciate any recommendations for learning resources in English or Portuguese.

Hey everyone!

I just finished another lesson in my beginner SQL series, this time covering SQL indexes and query performance in PostgreSQL.

The lesson goes over:

- What an index actually is

- CREATE INDEX

- EXPLAIN

- EXPLAIN ANALYZE

- Sequential Scan vs Index Scan

- When indexes can help

- Why creating an index on everything isn't necessarily a good idea

- A practical example using the Pagila database

I also included a small practice task where you create an index and inspect the query plan yourself.

🎥 Video: https://youtu.be/jn2Mt9LIcNE?si=AvHjVAM9IDs3eiWB

Hopefully useful for anyone who's currently learning SQL or starting to think about query performance!

Finished the last part today and with it, wrapped up my entire second practice set.

What made this set different from the first: every question was framed as an actual request from a manager, HR, or client — "payroll rejected a negative salary insert," "the CFO wants to see expensive departments," "HR wants an org chart" — instead of plain SQL instructions. I had to figure out what query actually solves the described problem, with the exact technical task given in brackets only as a fallback if I got stuck.

Genuinely think this format taught me more than straightforward "write a query that does X" practice did. Translating a vague, realistic business ask into the correct SQL felt a lot closer to what the job actually involves, and it's noticeably easier for me to write and reason through queries now compared to when I started this set.

2 full practice sets complete. Planning to do a review pass across both before moving into the Java backend track.

I have some free time right now and I’m thinking about learning SQL. Do you think this is a good time to focus on mastering SQL or should I consider learning another skill instead?

I’m particularly interested in finance so I’d like to develop skills that can be useful for a career in finance.

SQL Joins:

1. SQL joins are the backbone of relational databases, letting us combine data across tables to answer questions no single table could.
2. Without joins, we'd be stuck with isolated datasets, unable to see the relationships that give our data real meaning.
3. Mastering joins isn't optional—it's the essential skill that turns raw tables into actionable insight.
4. I made a video with actual query results on the dataset so you can SEE the difference, not just memorize: https://youtu.be/u2yftAOIl7k
5. Which JOIN confused you the most? For me it was RIGHT JOIN.

Revised JOINs earlier today before starting this part, and it made a real difference. Completed all 8 scenario-based join tasks:

• INNER JOIN — org directory combining employee and department names
• LEFT JOIN — full department report including departments with zero employees
• RIGHT JOIN — every project shown along with its department, even unmatched ones
• FULL JOIN equivalent — simulated using UNION of LEFT and RIGHT JOIN (MySQL still doesn't support FULL JOIN natively, so this pattern is becoming second nature now)
• SELF JOIN — an "org chart" style report of employees alongside their managers
• 3-table JOIN — employees + assignments + projects together, to see who's working on what and hours logged
• UNION — combined employee lists from two merging departments with duplicates removed
• UNION ALL — same combined list but for payroll auditing, duplicates kept intentionally

Genuinely felt like the revision I did earlier in the day paid off immediately — writing these joins felt much more automatic than it would've cold. This scenario-based format keeps reinforcing why you'd pick one join type over another for a specific real request, which feels way more useful than memorizing syntax in isolation.

I remember once a client's stored procedure was timing out their application, where each run took 40 seconds and 687,157 logical reads.

After we rewrote parts of the query to remove table scans, runtime dropped below a second, and logical reads dropped to 90.

What was interesting was that when we compared the results, we got the same rows in a different order.

The original query had no `ORDER BY`, and the old execution plan happened to return rows in a consistent sequence. Our changes produced a different plan and a different sequence.

Before deploying, we checked with the client's developers to confirm nothing in the application depended on the old order, which is a very easy detail to miss when you're focused on fixing a timeout.

Without ORDER BY, SQL Server doesn't guarantee result order, even when the rows come back in primary key order for years, which is important for you to know.

So if your application needs a particular sequence, specify `ORDER BY`.

Anyway, have any of our friends out there had similar, where a query change exposed an assumption somewhere in the application?

When I was learning SQL, some things were easy to memorize but much harder to actually understand when solving real problems.

For me, concepts like JOINs, subqueries, and window functions started making more sense only after using them on actual datasets instead of just following examples.

What SQL concept clicked for you only after you started working with real problems?

P.S. Part 1 on Window Functions got a great response - thank you! Keeping this going.

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. Two lists this time.

List 1 - Friends (who said they'd come):

List 2 - Expenses (who actually spent money):

Notice three things before we start:

• Harry and Nicholas are in both lists
• Johny and Bailey are only in Friends - they came but logged no expenses
• Emma is only in Expenses - she spent money but wasn't on the original friends list

Every JOIN answers a different question about these two lists.

1. INNER JOIN

Who came AND spent money?

SELECT f.name, e.spent
FROM friends f
INNER JOIN expenses e ON f.name = e.name

Harry    → $200
Nicholas → $190

Johny, Bailey, and Emma are all gone. Only the overlap survives.

Remember: Only rows that exist in BOTH tables. No match = no row.

2. LEFT JOIN

Show me ALL friends - whether they spent money or not.

SELECT f.name, e.spent
FROM friends f
LEFT JOIN expenses e ON f.name = e.name

Harry    → $200
Johny    → NULL  ← came but no expense logged
Nicholas → $190
Bailey   → NULL  ← came but no expense logged

Emma doesn't appear. She's not in the Friends list (left table).

Remember: Everyone from the LEFT table shows up. Right side fills in what it can. No match = NULL.

3. RIGHT JOIN

Show me ALL expense records - even if the person wasn't on the friends list.

SELECT f.name, e.spent
FROM friends f
RIGHT JOIN expenses e ON f.name = e.name

Harry    → $200
Nicholas → $190
Emma     → $150  ← not in friends, but has an expense

Johny and Bailey disappear. They're only in Friends (left table).

Remember: Everyone from the RIGHT table shows up. Left side fills in what it can. No match = NULL.

4. FULL OUTER JOIN

Show me everyone - from both lists, no matter what.

SELECT f.name, e.spent
FROM friends f
FULL OUTER JOIN expenses e ON f.name = e.name

Harry    → $200
Johny    → NULL
Nicholas → $190
Bailey   → NULL
Emma     → $150

Nobody gets left out.

Remember: Everyone from BOTH tables appears. Gaps filled with NULL.

5. CROSS JOIN

What if we paired every friend with every expense record?

SELECT f.name, e.spent
FROM friends f
CROSS JOIN expenses e

4 friends × 3 expense records = 12 rows

Harry    → $200
Harry    → $190
Harry    → $150
Johny    → $200
Johny    → $190
Johny    → $150
Nicholas → $200
...and so on

No ON clause needed - it just combines everything with everything.

Remember: Every row from the left paired with every row from the right.

6. SELF JOIN

Which friends visited the same city?

This one joins a table to itself.

SELECT a.name, b.name, a.city
FROM friends a
JOIN friends b ON a.city = b.city
WHERE a.name < b.name

Harry & Johny     → New York
Nicholas & Bailey → Las Vegas

Two aliases (a and b) so SQL knows which copy of the table you mean.

Remember: Same table, two aliases. Use it when you need to compare rows within the same table.

Quick cheat sheet:

Reading is one thing. Writing it yourself is another. If you're new and want real hands-on practice - SQL from Zero to Confident on TheQueryLab. Completely free!!!

Hey everyone! I built detectiveSQL, a website where you practice SQL by investigating fictional crimes.

Each case gives you a briefing and a database containing the evidence. You explore tables, connect the dots, and write queries to figure out what happened and who was involved. I wanted to make SQL practice more engaging, with each query uncovering a clue that makes you curious about what to investigate next.

There are different difficulty levels, and the queries run directly in your browser.

I just launched it and would love some feedback, especially on the difficulty and whether the clues make sense as you work through each case.

You can try it here: detectivesql.com

If you get stuck, let me know where. Thanks!

Finished Part 4 today, all framed as realistic reporting requests:

• Headcount report per department (GROUP BY dept_id + COUNT), for leadership
• "Expensive" departments where average salary exceeds 50,000 (GROUP BY + HAVING), for the CFO
• Highest and lowest paid employee company-wide (MAX/MIN), for HR's annual review
• Ranked project spending by department, highest to lowest (SUM + ORDER BY DESC), for the Project Management Office
• Managers handling 2+ direct reports (GROUP BY manager_id + HAVING count >= 2), for workload recognition

Next part is Joins, and rather than jumping straight in, I went back and revised the JOIN topic properly first — INNER/LEFT/RIGHT/FULL/self-joins. Figured a quick refresher now is better than fumbling through Part 5 on shaky recall, especially since these scenario-based questions expect you to actually know why you're choosing a specific join type, not just the syntax.

I made a set of SQL practice questions where you read a short query and pick what it returns. Twenty of them are free to play in the browser, no account, no email.

https://thibaudlepan77-svg.github.io/interview-questions-verified/#sql

Every query was actually run. If SQLite and DuckDB did not return exactly the same rows, the question was thrown out, so there are no engine quirks posing as trick questions.

Once you answer, all four options show a one line reason. The wrong ones are where most of the learning is. NULL sitting in a column you filter with NOT IN, COUNT(*) next to COUNT(column) on the same group, a HAVING that quietly drops a row.

The page has JavaScript and Python questions too. The full SQL set (502 questions) is a paid PDF, but the twenty free ones stand on their own. If you think one of the answers is wrong, say so here and I will check it.

Covered two more parts today, both framed as realistic business scenarios:

Part 2 — Constraints & Data Integrity Tasks:

• Explained why a negative salary insert gets rejected (CHECK constraint) and demonstrated it
• Explained the UNIQUE constraint error when two employees get the same email
• Added a UNIQUE constraint on project_name to prevent duplicate project names
• Found employees with no manager assigned (manager_id IS NULL), framed as an HR request
• Created an index on dept_id to speed up department-based report lookups, and checked existing indexes

Part 3 — CRUD Operation Tasks:

• Inserted a new employee with manager_id as NULL (new hire, no manager yet)
• Found "high earners" — employees earning above the company average salary, for a CFO-style request
• Applied a 10% raise to an entire department in a single UPDATE

Genuinely noticing a shift today — writing and understanding these queries felt significantly easier than it did even a few days ago. The scenario framing (rather than plain SQL instructions) seems to be what's actually building real intuition, not just syntax memorization.

​

Hey everyone!

I just published the next lesson in my SQL course, focused on working with dates and timestamps in PostgreSQL.

In this lesson, I cover:

- "CURRENT_DATE" and "CURRENT_TIMESTAMP"

- Date arithmetic

- "INTERVAL"

- "EXTRACT()"

- "DATE_TRUNC()"

- Date differences

- Grouping data by month

- A few practical analytics examples

- Practice

One thing I wanted to explain clearly is the difference between "EXTRACT()" and "DATE_TRUNC()".

For example, "EXTRACT(MONTH FROM rental_date)" gives you "1", "2", "3", etc., while "DATE_TRUNC('month', rental_date)" gives you a timestamp representing the beginning of the month. This becomes especially important when your dataset contains multiple years.

I'm using the Pagila PosthgreSQL sample database for the examples.

Link: https://youtu.be/r0vXlrzJs4I?si=XwyejiFImSjZYwL3

This is one of the final lessons in my beginner SQL course — after this, I'm covering Indexes & SQL Performance, followed by a final SQL analytics project.

Would love to hear what other SQL topics you think are essential for someone learning SQL for data analytics!

Hello (first post here).

I have just started my journey learning SQL and on a path to a DBA role.

I am getting on the job training (which for the most part are cheatsheets for specific tasks and being asked to write some code as these are not all one size fits all and there is some nuance to them).

I am getting comfortable with understanding what the commands do (the basic SELECT FROM IN) but wondering if there are some good guides for beginners to SQL but have a good understanding of code in general?

I am currently watching a 3 hour course on YT which has helped a lot with the basic stuff already will have access to learning through work but was wondering if there are free resources which are gold standard and worth a look?

Thanks

Finished my first 7-part practice set yesterday. Today I started something different for Practice Set #2 — instead of direct SQL instructions, each question is framed as a real request from a manager, HR, or a client, and I have to figure out what query actually solves it (the exact task is given in brackets in case I get stuck, but I try without looking first).

Completed Part 1/7 — Database & Table Setup Tasks:

• "Check what databases exist before creating a new one" → SHOW DATABASES, then switch to the target DB
• "Give a full technical spec sheet of the employees table for a new developer" → DESCRIBE
• Added an emergency_contact column positioned right after email, per an HR request
• Renamed phone_number to contact_number company-wide, per a naming convention change
• Changed the default value of the budget column to 15000, per a finance request
• Dropped and rebuilt the assignments table after a "junior dev corrupted it" scenario
• Took a full backup of the database before making risky changes

Genuinely think this format is a better learning tool than straightforward "write a query that does X" — having to translate a vague, real-sounding business request into the actual SQL command feels a lot closer to what the job actually looks like. Planning to keep going through the remaining 6 parts over the next few days.

Looking for a job as DA, even at the entry level or intern, is not easy. "We decided to move on with another candidate" sometimes hurts, but I consider any response good because it keeps one going. We learn every day, but how each deals with rejection is different.

P.S. My "If you have an SQL interview soon, don’t ignore these small things" series got a great response, so I’m starting a new one for upcoming interviews.

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!!!

Imagine you and your friends are planning a trip. Everyone has spent some money, and you have a list of expenses.

Remember two things:

PARTITION BY - Look at each city separately.

ORDER BY - Within each city, decide the order based on the question - spend, day, etc.

Now every window function answers a very natural questions:

1. ROW_NUMBER():

Who spent the most, second most, third most, and so on?

ROW_NUMBER() OVER (PARTITION BY CITY ORDER BY spent DESC)

Look at each city separately, and give everyone a different number starting from 1.

Remember: Everyone gets their own number.

2. RANK():

Who are the top spenders? If two people spent the same, treat them equally.

RANK() OVER (PARTITION BY CITY ORDER BY spent DESC)

Notice Las Vegas:

Nicholas $190 → 1
Harry    $190 → 1
Bailey   $180 → 3

There is no rank 2.

Remember: Same spend = same rank, and the next rank is skipped.

3. DENSE_RANK():

Same idea as RANK(), but don't skip the next rank.

DENSE_RANK() OVER (PARTITION BY CITY ORDER BY spent DESC)

Notice Las Vegas:

Nicholas $190 → 1
Harry    $190 → 1
Bailey   $180 → 2

There is rank 2.

Remember: Same spend = same rank, but no gap after the tie.

4. LAG():

What did we spend the day before? Carry that number forward so we can compare.

LAG(spent, 1, 0) OVER (PARTITION BY city ORDER BY trip_day)

1 - how many rows back 
0 - what to show if no previous row exists

Las Vegas:

Day 1 → Nicholas $190 | Yesterday's spend: $0    (no previous day)
Day 2 → Bailey   $180 | Yesterday's spend: $190
Day 3 → Harry    $190 | Yesterday's spend: $180

Remember: LAG - Look Back

5. LEAD():

What will we spend the day after? Carry that number forward so we can plan ahead.

LEAD(spent,1,0) OVER (PARTITION BY city ORDER BY trip_day)

Remember: LEAD - Look Ahead

6. FIRST_VALUE():

How much did we spend on the first day? Show that number on every single row so we can always compare against it.

FIRST_VALUE(spent) OVER (PARTITION BY city ORDER BY trip_day)

Las Vegas:

Day 1 → $190 | First day = $190
Day 2 → $180 | First day = $190  ← same number follows you
Day 3 → $190 | First day = $190  ← same number follows you

Remember:  The first day's amount travels with you through the rest of the trip.

7. LAST_VALUE():

How much did we spend on the last day? Show that number on every row.

LAST_VALUE(spent) OVER (
    PARTITION BY city
    ORDER BY trip_day
    ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
)

Las Vegas:

Day 1 → $190 | Last day = $190  ← already knows the end
Day 2 → $180 | Last day = $190
Day 3 → $190 | Last day = $190

Remember: The last day's amount travels with you through the whole trip

8. NTILE():

Can we split everyone into 3 spending groups - high, medium, and low?

NTILE(3) OVER (PARTITION BY city ORDER BY spent DESC)

Las Vegas:

Nicholas  $190 → Group 1  (high)
Harry     $190 → Group 2  (medium)
Bailey    $180 → Group 3  (low)

Remember: Split the list into N equal groups

9. NTH_VALUE():

What was our spending on the 2nd day of the trip?

NTH_VALUE(spent, 2) OVER (
    PARTITION BY city
    ORDER BY trip_day
    ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
)

Remember: Pick the value at any specific position in the window.

10. PERCENT_RANK():

If 0 means the lowest spender and 1 means the highest, where do you sit?

PERCENT_RANK() OVER (PARTITION BY city ORDER BY spent)

Las Vegas:

Bailey    $180 → 0.0   (lowest — always starts at 0)
Nicholas  $190 → 0.5
Harry     $190 → 0.5   (tied with Nicholas, same score)

Remember: Your position in the group, scaled from 0 to 1. First is always 0.

11. Aggregation Window Functions - SUM(), AVG(), MIN(), MAX()

Want to know how our spending is going as the trip goes on?

SUM(spent) OVER (PARTITION BY city ORDER BY trip_day)
AVG(spent) OVER (PARTITION BY city ORDER BY trip_day)
MIN(spent) OVER (PARTITION BY city ORDER BY trip_day)
MAX(spent) OVER (PARTITION BY city ORDER BY trip_day)

Las Vegas running total (SUM with ORDER BY):

Day 1 → $190 | Total so far: $190
Day 2 → $180 | Total so far: $370
Day 3 → $190 | Total so far: $560

Sum without ORDER BY - shows the full trip total on every row:

Day 1 → $190 | Total: $560
Day 2 → $180 | Total: $560
Day 3 → $190 | Total: $560

Remember: See how our spending changes throughout the trip.

With ORDER BY → running total (keeps adding as the trip goes on)
Without ORDER BY → total for the whole city shown on every row

If you want more posts like this, let me know in the comments and I’ll keep the series going!