SQL for beginners: where to start

Why everyone needs this

Almost every program stores something. Developers, analysts, testers, product managers — all of them eventually hit the question of how to get the data out.

The good news: the basic level takes a week or two and covers most tasks and nearly every entry-level interview.

The order to learn it

1. Selecting. Fetch all rows, then only the columns you need.

SELECT title, created_at FROM notes;

2. Conditions. Filter by equality, comparison, membership, text matching, null checks.

SELECT * FROM notes WHERE created_at > '2026-01-01';

3. Sorting and limiting. Ascending and descending, taking the first few.

SELECT * FROM notes ORDER BY created_at DESC LIMIT 10;

4. Aggregates. Count, sum, average, minimum, maximum.

SELECT count(*) FROM notes;

5. Grouping. Computing per group rather than over the whole table — for example, how many notes are in each category.

SELECT category, count(*) FROM notes GROUP BY category;

The key thing here is the difference between filtering before grouping and filtering after: the first selects rows, the second selects already-computed groups.

6. Joins. The most important topic and the one people stumble on most.

SELECT notes.title, users.name
FROM notes
JOIN users ON users.id = notes.user_id;

Understand how an inner join differs from a left join: the first keeps only matched pairs, the second keeps every row of the left table even without a match. This gets asked almost every time.

7. Modifying data. Insert, update, delete. And caution: an update without a condition changes the entire table.

What can wait

More complex subqueries, window functions, stored procedures, execution-plan tuning. All useful, none of it at entry.

Where to practise

Create a database with two or three related tables: users, notes, categories. Fill it with a dozen rows by hand.

Then solve problems against your own data: how many notes each user has, who has none at all, which category is most common, who wrote in the last month.

Such exercises beat abstract problem sets because you hold the meaning of the data in your head.

Where interviews go wrong

• Joins. Asked to combine two tables and aggregate by group, people flounder.
• Left joins. "Find users with no notes" is solved with one, yet many try other routes.
• Grouping. Confusion about which conditions go before and which after.
• Not knowing what an index is. It's enough to understand: it speeds up lookups, slows down writes, and goes on what you search by often.