Candidate telemetry diagnostic, error autopsy, and step-by-step query construction walkthrough.
Live aggregated metrics across candidate sandbox attempts
37 solved
First attempt fail
Evaluated submissions
Median time to solve
Unlocked answer
Pricing wants a per-genre breakdown of how many tracks are sold at the standard $0.99 rate versus the premium rate (UnitPrice above $0.99). For every genre, produce one row with a count for each price tier, using conditional aggregation.
Return GenreId, Name, StandardPriceCount (tracks priced at exactly $0.99), and PremiumPriceCount (tracks priced above $0.99), ordered by GenreId ascending.
Note: in this catalog, pricing splits cleanly by genre -- music genres are entirely standard-priced, while video/TV genres (Science Fiction, TV Shows, etc.) are entirely premium-priced. Seeing an all-zero column for a given genre is expected, not a bug.
| Column | Type |
|---|---|
| GenreId | INTEGER (Primary Key) |
| Name | TEXT |
| Column | Type |
|---|---|
| TrackId | INTEGER (Primary Key) |
| GenreId | INTEGER (Foreign Key -> Genre.GenreId) |
| UnitPrice | NUMERIC(10,2) |
Your result should show one row per genre: | GenreId | Name | StandardPriceCount | PremiumPriceCount | |---------|---------|---------------------|---------------------| | 1 | Rock | 1297 | 0 | | 2 | Jazz | 130 | 0 | | 18 | Science Fiction | 0 | 13 | | ... | ... | ... | ... |
Double-counting metrics by using COUNT(*) after joining parent and child tables. When joining an invoice table with an invoice lines table, a single invoice multiplies across all its line items, causing COUNT(invoice_id) to return line counts instead of unique invoice counts.
Interviewers check whether you notice 1-to-many cardinality multiplication and use COUNT(DISTINCT col) or pre-aggregate child records before joining.
Construct the solution logically from first principles to avoid typical edge case pitfalls.
Identify the base table and apply preliminary WHERE filters.
FROM TableName WHERE is_active = true
Group by primary business keys and compute aggregate expressions.
SELECT category, COUNT(DISTINCT item_id) AS total_items, SUM(amount) AS revenue GROUP BY category
Order by specified metrics descending and apply limit clauses.
ORDER BY revenue DESC LIMIT 10;
SELECT g.GenreId, g.Name,
COUNT(*) FILTER (WHERE t.UnitPrice = 0.99) AS StandardPriceCount,
COUNT(*) FILTER (WHERE t.UnitPrice > 0.99) AS PremiumPriceCount
FROM Genre g
LEFT JOIN Track t ON t.GenreId = g.GenreId
GROUP BY g.GenreId, g.Name
ORDER BY g.GenreId ASC;Real code patterns candidates submit that fail the grading suite.
SELECT a.Name, COUNT(t.TrackId) FROM Artist a JOIN Album al ON a.ArtistId = al.ArtistId JOIN Track t ON al.AlbumId = t.AlbumId GROUP BY a.Name;
Three recurring syntax and semantic traps relevant to this problem domain.
Joining a fact table with child lines multiplies fact table rows, distorting sums and counts.
SELECT c.id, SUM(i.total) FROM customer c JOIN invoice i ON c.id = i.customer_id JOIN invoice_line il ON i.id = il.invoice_id -- ❌ Inflated SUM
SELECT c.id, SUM(i.total) FROM customer c JOIN invoice i ON c.id = i.customer_id GROUP BY c.id; -- ✅ Avoids line multiplication
Using COUNT(*) when duplicate rows exist due to joins counts duplicate records.
SELECT artist_id, COUNT(album_id) ... -- ❌ Counts duplicate occurrences
SELECT artist_id, COUNT(DISTINCT album_id) ... -- ✅ Distinct unique entities
In SQL, dividing integers like 5 / 10 results in 0. Cast at least one operand to FLOAT or NUMERIC.
SELECT solved_count / total_count AS rate ... -- ❌ Returns 0
SELECT CAST(solved_count AS FLOAT) / total_count AS rate ... -- ✅ Returns 0.5
Launch our in-browser coding environment. Run queries, view execution plans, and get instant comparative diff grading with no setup.