Choosing INNER vs LEFT JOIN

Context

You’re working on the analytics platform for a large e-commerce marketplace (~10M orders/day, millions of monthly active buyers). Multiple teams consume curated datasets: Finance needs revenue reporting that must not undercount orders; Growth needs funnel metrics that must include users who didn’t convert; and Trust & Safety needs to find sellers with missing compliance documents. In this environment, choosing the wrong join type can silently drop rows, leading to incorrect KPIs, misallocated marketing spend, or even regulatory reporting errors.

Core Question

Explain the difference between an INNER JOIN and a LEFT JOIN in SQL, and when you would use each.

In your answer, address:

1. Result set semantics: Which rows are kept vs removed when there is no match on the join key?
2. NULL behavior: What values appear for columns from the right-hand table when there is no match?
3. Business scenarios: Give at least two realistic examples from analytics/engineering work:
   • One where INNER JOIN is the correct choice (e.g., only orders with valid payments).
   • One where LEFT JOIN is the correct choice (e.g., all users with optional orders).
4. Common pitfall: Explain how a WHERE clause on the right table can accidentally turn a LEFT JOIN into an INNER JOIN, and how to avoid it.
5. Validation approach: Describe how you would sanity-check row counts to ensure you didn’t unintentionally drop data.

Scope Guidance (What a strong interview answer includes)

• Use precise language: “preserves all rows from the left table” vs “filters to matches only.”
• Include short SQL snippets demonstrating both joins.
• Mention how join choice impacts downstream aggregations (conversion rate, revenue, “missing” entity detection).
• Briefly touch on performance only if relevant (e.g., join order, filtering early), but focus primarily on correctness.

INNER JOIN (match-only join)

An INNER JOIN returns only rows where the join condition matches in both tables. Any left-table row without a corresponding right-table match is excluded, which is ideal when unmatched entities are irrelevant or invalid for the metric.

SELECT o.order_id, p.payment_id
FROM orders o
INNER JOIN payments p
  ON p.order_id = o.order_id;

LEFT JOIN (left-preserving join)

A LEFT JOIN returns all rows from the left table and brings in matching rows from the right table when they exist. If there is no match, right-table columns are returned as NULL—useful for retaining the full population and identifying missing relationships.

SELECT u.user_id, o.order_id
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.user_id;

Anti-join pattern (finding missing matches)

A common use of LEFT JOIN is to find records in the left table that have no match in the right table by filtering for NULLs on a right-table key. This is frequently used for compliance gaps, users with no purchases, or products with no inventory.

SELECT u.user_id
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.user_id
WHERE o.order_id IS NULL;

LEFT JOIN pitfall: filters in WHERE clause

If you LEFT JOIN and then put a condition on a right-table column in the WHERE clause (e.g., WHERE o.status = 'PAID'), you remove the NULL-extended rows and effectively convert the query to an INNER JOIN. To preserve left rows, move such filters into the ON clause or use conditional aggregation.

SELECT u.user_id, o.order_id
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.user_id
 AND o.status = 'PAID';

Impact on aggregations and KPIs

Join choice changes denominators. INNER JOIN tends to measure only the converted/linked subset, while LEFT JOIN preserves the full cohort and is necessary for accurate funnel metrics (e.g., conversion rate) and for counting zero-activity entities.

SELECT
  COUNT(DISTINCT u.user_id) AS users,
  COUNT(DISTINCT o.order_id) AS orders,
  1.0 * COUNT(DISTINCT o.order_id) / NULLIF(COUNT(DISTINCT u.user_id), 0) AS conversion_rate
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.user_id;