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.

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.

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

Tech stacks

Skill areas

Suggest an improvement