# Heavy Searchers in August

> August's power searchers.

Canonical URL: <https://datadriven.io/problems/heavy_searchers_in_august>

Domain: SQL · Difficulty: easy · Seniority: L3

## Problem

The search team defines a 'power searcher' as a user who ran more than 5 queries in a single month. How many power searchers were there in August 2026?

## Worked solution and explanation

### Why this problem exists in real interviews

The `search_queries` schema makes this a clean test of row numbering within partitions combined with nested subqueries. Columns like `search_term`, `results_count`, `clicked_result` introduce enough ambiguity that only candidates who clarify assumptions produce correct results.

---

### Break down the requirements

#### Step 1: Partition by `search_term`

`PARTITION BY search_term` creates groups. Within each group, `ORDER BY query_time DESC` determines the ranking.

#### Step 2: Filter to rank 1

`WHERE rnk = 1` in the outer query selects the target row per group.

---

### The solution

**Row-number for heavy searchers august**

```sql
SELECT *
FROM (
    SELECT *,
           ROW_NUMBER() OVER (PARTITION BY search_term ORDER BY query_time DESC) AS rnk
    FROM search_queries
) ranked
WHERE rnk = 1
ORDER BY search_term
```

> **Cost Analysis**
>
> Window function sorts within each `search_term` partition. An index on `(search_term, query_time)` avoids a full sort.

> **Interviewers Watch For**
>
> The interviewer checks whether you use ROW_NUMBER (one row) vs. RANK/DENSE_RANK (ties) based on the prompt requirements.

> **Common Pitfall**
>
> Using GROUP BY with MIN(query_time) gives the value but not the other columns. ROW_NUMBER gives the full row.

---

## Common follow-up questions

- What happens to your results if `search_term` in `search_queries` contains trailing whitespace or mixed casing? _(Tests awareness of text normalization issues that silently fragment GROUP BY results.)_
- Your window function uses a default frame. What is the implicit frame, and would switching to ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW change anything? _(Tests knowledge of default window frames (RANGE vs ROWS) and when the distinction matters.)_
- `query_id` in `search_queries` has ~60M distinct values. What index strategy keeps your query from doing a full table scan? _(Tests whether the candidate can design indexes for high-cardinality columns and understands selectivity.)_
- Could you express this same logic as a single query without CTEs or subqueries? What readability trade-off does that introduce? _(Tests whether the candidate can flatten nested logic and understands when decomposition aids maintainability.)_

## Related

- [All practice problems](https://datadriven.io/problems)
- [Mock interview mode](https://datadriven.io/interview/heavy_searchers_in_august)
- [SQL Interview Questions](https://datadriven.io/sql-interview-questions)
- [Data Engineering Interview Prep Guide](https://datadriven.io/data-engineer-interview-prep)
- [Daily Challenge](https://datadriven.io/daily)

---

Source: DataDriven (https://datadriven.io). 100% free data engineering interview prep. Live code execution against Postgres 16, Python 3.11, and Spark sandboxes. No paywall, no premium tier, no signup gate.