Candidate telemetry diagnostic, error autopsy, and step-by-step query construction walkthrough.
Live aggregated metrics across candidate sandbox attempts
55 solved
First attempt fail
Evaluated submissions
Median time to solve
Unlocked answer
The customer service team needs to see purchase history. They want to see each invoice along with the customer's name who made the purchase.
Write a SQL query that joins Customer and Invoice to show customer names with their invoice totals.
| Column | Type |
|---|---|
| CustomerId | INTEGER (Primary Key) |
| FirstName | TEXT |
| LastName | TEXT |
| Company | TEXT |
| Address | TEXT |
| City | TEXT |
| State | TEXT |
| Country | TEXT |
| PostalCode | TEXT |
| Phone | TEXT |
| Fax | TEXT |
| TEXT | |
| SupportRepId | INTEGER (Foreign Key → Employee.EmployeeId) |
| Column | Type |
|---|---|
| InvoiceId | INTEGER (Primary Key) |
| CustomerId | INTEGER (Foreign Key → Customer.CustomerId) |
| InvoiceDate | TIMESTAMP |
| BillingAddress | TEXT |
| BillingCity | TEXT |
| BillingState | TEXT |
| BillingCountry | TEXT |
| BillingPostalCode | TEXT |
| Total | NUMERIC(10,2) |
Your result should have 412 rows with 3 columns: | FirstName | LastName | Total | |-----------|----------|-------| | Leonie | Köhler | 1.98 | | Bjørn | Hansen | 3.96 | | Daan | Peeters | 5.94 | | Mark | Philips | 8.91 | | John | Gordon | 13.86 | | ... | ... | ... |
Using INNER JOIN instead of LEFT JOIN when joining primary records to optional child tables. If an entity has zero associated transactions or invoices, an INNER JOIN silently purges that row from the report, resulting in understated counts and skewed analytical aggregates.
Interviewers test whether you can recognize cardinality relationships (1:1, 1:N, N:M), understand table key constraints, and avoid unintentional data loss or cartesian explosion.
Construct the solution logically from first principles to avoid typical edge case pitfalls.
Establish which table defines the primary grain of the query (e.g. Customers, Invoices, or Artists).
FROM PrimaryTable pt
Attach related tables using clear join conditions on primary and foreign key pairs.
LEFT JOIN ForeignTable ft ON pt.id = ft.foreign_key
Filter required subsets and qualify column names with unambiguous table aliases.
WHERE pt.is_active = true ORDER BY pt.name ASC;
SELECT Customer.FirstName, Customer.LastName, Invoice.Total FROM Customer JOIN Invoice ON Customer.CustomerId = Invoice.CustomerId;
Real code patterns candidates submit that fail the grading suite.
SELECT Name, InvoiceId, Total FROM Customer JOIN Invoice ON CustomerId = CustomerId;
Three recurring syntax and semantic traps relevant to this problem domain.
INNER JOIN drops rows from the left table if there is no matching foreign key in the right table. For inclusive reports, use LEFT JOIN.
SELECT c.name, COUNT(o.id) FROM customers c JOIN orders o ON c.id = o.customer_id GROUP BY c.name; -- ❌ Drops customers with 0 orders
SELECT c.name, COUNT(o.id) FROM customers c LEFT JOIN orders o ON c.id = o.customer_id GROUP BY c.name; -- ✅ Includes all customers
Adding a WHERE filter on a column from the right table of a LEFT JOIN converts it into an INNER JOIN because NULL rows fail the WHERE predicate.
FROM customers c LEFT JOIN orders o ON c.id = o.customer_id WHERE o.status = 'active'; -- ❌ Discards NULLs, acting like INNER JOIN
FROM customers c LEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'active'; -- ✅ Preserves all customers
Joining two tables on non-unique keys without sufficient composite constraints multiplies rows exponentially, inflating SUM and COUNT results.
FROM users u JOIN user_tags t ON u.id = t.user_id JOIN user_roles r ON u.id = r.user_id -- ❌ M*N row explosion
Aggregate child tables in separate CTEs before joining to the parent entity.
Launch our in-browser coding environment. Run queries, view execution plans, and get instant comparative diff grading with no setup.