SQL Practice
JOINs are the second most-tested SQL category after aggregation. INNER JOIN is the most common join type by far, with LEFT JOIN close behind. Practice every join type against a real database with instant output comparison.
Sample problems from each join type, ordered by interview frequency. INNER and LEFT joins cover most real questions. Start there, then move to self-joins and inequality joins when those feel automatic.
Returns only rows that match in both tables. The default join type and the one most candidates reach for first. Interviewers test whether you understand that unmatched rows are silently dropped.
Returns all rows from the left table, with NULLs where the right table has no match. The most interview-relevant join type. Interviewers use it to test your understanding of NULLs, missing data, and the difference between filtering in ON vs WHERE.
A table joined to itself. Used for hierarchical data, finding pairs, and comparing rows within the same table. Self-joins feel unnatural at first, but they solve a specific class of problems that no other join can.
A join where the condition uses <, >, <=, >=, or BETWEEN instead of =. Less common but shows up in date range problems, event attribution, and interval matching. Many candidates have never written one.
Produces the Cartesian product of two tables. Every row in table A paired with every row in table B. Useful for generating combinations, date spines, and filling gaps. Small tables only, or your query will run forever.
These are not obscure edge cases. They come up regularly, and getting them wrong usually costs the round.
Adding WHERE right_table.column = 'value' after a LEFT JOIN converts it into an INNER JOIN. The NULLs from unmatched rows fail the WHERE check and get dropped. Move the filter into the ON clause to keep it a true LEFT JOIN. This is one of the most common interview traps.
If your join key is not unique on one side, each row on the unique side gets duplicated for every match. Joining orders to order_items gives you one row per item, not one row per order. Interviewers ask you to count orders after a join to see if you catch the fan-out.
Joining on a nullable column drops rows where either side is NULL, because NULL = NULL evaluates to NULL (falsy). If you need to match NULLs, use COALESCE or IS NOT DISTINCT FROM.
When you join three or more tables, always alias your tables and qualify every column. Interviewers watch for ambiguous references. If two tables both have an 'id' column and you write SELECT id, the query fails.
Given an orders table and a customers table, find each customer's name, total number of orders, and total spend. Include customers who have never ordered.
SELECT
c.name,
COUNT(o.order_id) AS order_count,
COALESCE(SUM(o.amount), 0) AS total_spend
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.customer_id
GROUP BY c.customer_id, c.name
ORDER BY total_spend DESC;LEFT JOIN keeps every customer even if they have zero orders. Without COALESCE, customers with no orders would show NULL for total_spend instead of 0. Grouping by customer_id (not just name) avoids merging two customers who happen to share a name.
Expected output
name | order_count | total_spend
-------------+-------------+------------
Alice Chen | 5 | 1240.00
Bob Park | 3 | 870.50
Carol Jones | 0 | 0.00Knowing the syntax is step one. Writing a four-table join under interview pressure is something else entirely. Multiple challenge formats, all targeting the join patterns that appear most in real interviews.