Concept questionEasy~5 min

Interview question

How would you explain GROUP BY and HAVING using a practical reporting query?

Use GROUP BY and HAVING for business counts

Explains aggregate queries, grouping keys, filters before and after aggregation, and business-count correctness.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would use GROUP BY when I need one result row per category, customer, day, status, or other grouping key. WHERE filters rows before aggregation, while HAVING filters groups after aggregation. For example, to find customers with more than five paid orders this month, I would filter paid orders in WHERE, group by customer id, then use HAVING COUNT(*) > 5. That keeps row filtering and group filtering separate.

Full answer below

Practice focus

Aggregation, grouping keys, WHERE versus HAVING, null handling, counting, and report correctness.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Aggregate questions are common because many backend features need counts, totals, and summaries. The important part is not the syntax alone, but whether the candidate can protect business meaning.
I would use GROUP BY when I need one result row per category, customer, day, status, or other grouping key. WHERE filters rows before aggregation, while HAVING filters groups after aggregation. For example, to find customers with more than five paid orders this month, I would filter paid orders in WHERE, group by customer id, then use HAVING COUNT(*) > 5. That keeps row filtering and group filtering separate.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would be precise about the grouping key and the counting rule. COUNT(*) counts rows, COUNT(column) skips nulls, and COUNT(DISTINCT column) answers a different question. If a join multiplies rows, aggregates can become wrong unless the query groups at the right level first. For reports, I would define whether the count means orders, customers, line items, paid orders, or unique products before writing the query.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For production reporting I would also think about performance, freshness, and repeatability. A dashboard aggregate over a large OLTP table may need a covering index, a precomputed read model, or a scheduled summary table. I would include deterministic date boundaries and time zone rules so numbers do not change mysteriously. If the metric matters to the business, I would write tests or reconciliation queries around the definition, not only the SQL syntax.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using HAVING when a simple WHERE filter belongs before aggregation.
Counting rows after a join without checking row multiplication.
Confusing COUNT(*) with COUNT(column).
Grouping by too many columns and accidentally changing the metric.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain WHERE versus HAVING.
Does not define what the business count means.
Ignores duplicate rows introduced by joins.
Has no performance plan for large reporting tables.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When would you use COUNT(DISTINCT)?
How would you validate a dashboard count?
How would you make the query faster on a large table?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Avoid Fanout TotalsCoding problem / Medium / ~25 minContinue Daily Order KPIsCoding problem / Medium / ~25 minContinue Running BalanceCoding problem / Medium / ~25 minContinue

Opening drill

Concept questionEasy~5 min

Interview question

How would you explain GROUP BY and HAVING using a practical reporting query?

Use GROUP BY and HAVING for business counts

Explains aggregate queries, grouping keys, filters before and after aggregation, and business-count correctness.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Aggregation, grouping keys, WHERE versus HAVING, null handling, counting, and report correctness.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Aggregate questions are common because many backend features need counts, totals, and summaries. The important part is not the syntax alone, but whether the candidate can protect business meaning.
I would use GROUP BY when I need one result row per category, customer, day, status, or other grouping key. WHERE filters rows before aggregation, while HAVING filters groups after aggregation. For example, to find customers with more than five paid orders this month, I would filter paid orders in WHERE, group by customer id, then use HAVING COUNT(*) > 5. That keeps row filtering and group filtering separate.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would be precise about the grouping key and the counting rule. COUNT(*) counts rows, COUNT(column) skips nulls, and COUNT(DISTINCT column) answers a different question. If a join multiplies rows, aggregates can become wrong unless the query groups at the right level first. For reports, I would define whether the count means orders, customers, line items, paid orders, or unique products before writing the query.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For production reporting I would also think about performance, freshness, and repeatability. A dashboard aggregate over a large OLTP table may need a covering index, a precomputed read model, or a scheduled summary table. I would include deterministic date boundaries and time zone rules so numbers do not change mysteriously. If the metric matters to the business, I would write tests or reconciliation queries around the definition, not only the SQL syntax.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using HAVING when a simple WHERE filter belongs before aggregation.
Counting rows after a join without checking row multiplication.
Confusing COUNT(*) with COUNT(column).
Grouping by too many columns and accidentally changing the metric.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain WHERE versus HAVING.
Does not define what the business count means.
Ignores duplicate rows introduced by joins.
Has no performance plan for large reporting tables.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When would you use COUNT(DISTINCT)?
How would you validate a dashboard count?
How would you make the query faster on a large table?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Avoid Fanout TotalsCoding problem / Medium / ~25 minContinue Daily Order KPIsCoding problem / Medium / ~25 minContinue Running BalanceCoding problem / Medium / ~25 minContinue

How would you explain GROUP BY and HAVING using a practical reporting query?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

How would you explain GROUP BY and HAVING using a practical reporting query?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice