# Hottest Regions by CPU

> Where the fleet runs warmest.

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

Domain: SQL · Difficulty: medium · Seniority: L4

## Problem

Capacity planning wants the three regions running hottest on average. For each region, compute the average CPU percentage across its nodes, and return the top 3 regions by that average, highest first.

## Worked solution and explanation

### Why this problem exists in real interviews

This appears on interview slates because row numbering within partitions combined with nested subqueries on `infra_nodes` exposes whether a candidate thinks about edge cases in `hostname`, `region`, `node_type` or just writes mechanical queries.

---

### Break down the requirements

#### Step 1: Partition by `hostname`

Group infra_nodes by region.

#### Step 2: Filter to rank 1

Compute AVG(cpu_pct) per region.

---

### The solution

**Row-number for highest node density regions**

```sql
SELECT region, ROUND(AVG(cpu_pct),2) AS avg_cpu FROM infra_nodes GROUP BY region ORDER BY avg_cpu DESC LIMIT 3
```

> **Cost Analysis**
>
> Window function sorts within each `hostname` partition. An index on `(hostname, node_id)` 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(node_id) gives the value but not the other columns. ROW_NUMBER gives the full row.

---

## Common follow-up questions

- What happens to your results if `hostname` in `infra_nodes` 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.)_
- The `region` column in `infra_nodes` has a zipf distribution, meaning a few values dominate. How does that skew affect your query plan and parallelism? _(Tests understanding of data skew: the optimizer may choose a bad plan when histogram statistics are stale.)_
- 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/hottest_regions_by_cpu)
- [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). DataDriven is the data engineering interview community. Live code execution in SQL, Python, and Spark sandboxes. Every feature is open to every member.