LEFT JOIN vs INNER JOIN
INNER JOIN only keeps rows with a match on both sides. LEFT JOIN keeps every row from the left table, filling in NULLs when there is no match on the right โ that gap is exactly what these 20 challenges are built around.
A real technical SQL interview built entirely around LEFT JOIN, IS NULL, missing-records analysis, and business reporting โ no basic syntax, no MCQs.
categories, users, products, orders, order_items, payments, calendar_months.You need to be logged in to take this challenge.
LEFT JOIN returns every row from the left (first) table, and the matching row from the right table when one exists โ or NULL in every right-table column when it doesn't. That single behavior is what makes LEFT JOIN the standard tool for "find what's missing": customers with no orders, products with no sales, orders with no payment, categories with no products.
This challenge uses a deliberately imperfect e-commerce dataset โ a few customers who never ordered, products that never sold, orders that were placed but never paid, even a product with a broken category reference โ because real production databases always have gaps like these, and interviewers know it.
An INNER JOIN silently drops any row without a match on both sides. Swap it in where a LEFT JOIN is required and rows quietly disappear โ a customer with zero orders vanishes from the result instead of showing up with NULL order data. This is one of the most common production bugs, and one of the most common interview traps.
INNER JOIN only keeps rows with a match on both sides. LEFT JOIN keeps every row from the left table, filling in NULLs when there is no match on the right โ that gap is exactly what these 20 challenges are built around.
After a LEFT JOIN, checking WHERE right_table.id IS NULL is the standard way to isolate rows that had no match โ customers with no orders, products with no sales, orders with no payment. Filtering on any other right-side column instead of the join key is a common bug, since a non-key column can be NULL for reasons unrelated to a missing match.
COUNT(right_table.id) after a LEFT JOIN correctly ignores unmatched rows, which is why COUNT(*) and COUNT(some_column) can disagree โ COUNT(*) counts the row itself even when every joined column is NULL.
Chaining LEFT JOIN users โ orders โ payments lets a single query answer "did they register, did they order, did they pay" without losing anyone at any stage โ the backbone of funnel and retention analysis.
Almost every "who churned," "what never sold," or "where did we lose revenue" business question is really a missing-records question in disguise โ and LEFT JOIN plus IS NULL is how you answer it without writing a NOT IN subquery or a separate anti-join. This challenge builds that instinct across 20 real scenarios: unpaid orders, dormant customers, broken category mappings, and a capstone executive audit that combines several LEFT JOINs into one dashboard query.
After a LEFT JOIN, every column from the right-hand table can be NULL โ including columns you might instinctively aggregate. SUM() and AVG() silently skip NULLs, but that means an unmatched row contributes nothing unless you wrap the result in COALESCE(..., 0) to make "no data" explicit as zero rather than leaving a blank cell in a report.
Revenue leakage investigations, customer retention gap analysis, churn candidate detection, marketing cohort conversion audits โ these are the exact questions data teams at e-commerce and fintech companies answer every week, and every one of them starts from a LEFT JOIN. Passing this challenge at 75/100 unlocks a shareable certificate and a spot on the LEFT JOIN Hard Challenge leaderboard.