Super Reviewers
A medium SQL interview practice problem on DataDriven. Write the query and run it against a real database, with instant feedback.
- Domain
- SQL
- Difficulty
- medium
- Seniority
- L3
- Asked in
- Walmart
Problem
We're spotlighting the super reviewers whose work actually ships: the people carrying a heavy load of reviews on pull requests that made it to merge. Find every reviewer credited with at least 25 of those reviews, heaviest first.
The most prolific code reviewers.
Tables
code_reviews
Columns: review_id INTEGER, repo_name TEXT, author TEXT, reviewer TEXT, status TEXT, comments INTEGER, opened_at TEXT, merged TEXT
| review_id | repo_name | author | reviewer | status | comments | opened_at | merged |
|---|---|---|---|---|---|---|---|
| 1053 | backend-api | bob | eve | changes_requested | 3 | 2026-02-02 | 2026-02-05 |
| 1106 | infra | charlie | frank | pending | 6 | 2026-03-03 | 2026-03-06 |
| 1159 | ml-pipeline | dana | grace | Approved | 9 | 2026-04-04 | 2026-04-07 |
| 1212 | mobile-app | eve | hank | PENDING | 12 | 2026-05-05 | NULL |
| 1265 | data-platform | frank | alice | merged | 15 | 2026-06-06 | 2026-06-09 |
| 1318 | frontend | grace | bob | approved | 18 | 2026-07-07 | 2026-07-10 |
| 1371 | backend-api | hank | charlie | changes_requested | 21 | 2026-08-08 | 2026-08-11 |
| 1424 | infra | alice | NULL | pending | 24 | 2026-09-09 | NULL |
| 1477 | ml-pipeline | bob | eve | Approved | 27 | 2026-01-10 | 2026-01-13 |
| 1530 | mobile-app | charlie | frank | PENDING | 30 | 2026-02-11 | 2026-02-14 |
Expected output
| reviewer | review_count |
|---|---|
| eve | 26 |
| frank | 26 |
| grace | 26 |
Worked solution and explanation
What this really is
Walking through it
Step 1: Scope to merged pull requests
A review counts only when its pull request reached merge, and in this table that shows up as a non-empty merged date. WHERE merged IS NOT NULL drops every review on a pull request that never shipped. This is exactly where 'hank' falls out: all 26 of his reviews sit on unmerged pull requests, so none of them count. Skip this and you are measuring noise, not impact.
Step 2: Group by reviewer and count
GROUP BY reviewer collapses the table to one row per person, and COUNT(*) counts every qualifying review they touched. Do not reach for COUNT(DISTINCT author): a super reviewer earns the title by raw shipped volume, and repeat reviews for the same author still count.
Step 3: Filter the groups with HAVING
The at-least-25 cutoff tests the aggregate you just computed, so it goes in HAVING, which runs after grouping. WHERE cannot see COUNT(*) because it is evaluated before the groups exist. Here the cutoff separates the three reviewers sitting at 26 from the pack at 24.
Step 4: Sort heaviest first
ORDER BY review_count DESC puts the heaviest load on top, which is how the manager reads the list. The qualifiers are tied at 26, so add reviewer as a tiebreaker to keep the order stable and predictable.
The solution
SELECT reviewer, COUNT(*) AS review_count
FROM code_reviews
WHERE merged IS NOT NULL
GROUP BY reviewer
HAVING COUNT(*) >= 25
ORDER BY review_count DESC, reviewerCommon follow-up questions
- If a super reviewer were defined relative to the team, say everyone above the average merged-review load, how would the `HAVING` clause change? (Tests replacing a literal threshold with a scalar subquery for the mean.)
- How would you also show each super reviewer's average number of comments per review? (Tests adding a second aggregate, `AVG(comments)`, to the same grouped query.)
- If leadership instead wanted reviewers whose pull requests mostly never merge flagged, how would you invert the filter, and what breaks? (Tests reasoning about the null merge date and counting the complementary set.)