# Node Summary Per Region

> Every region has a node story.

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

Domain: SQL · Difficulty: easy · Seniority: L3

## Problem

The capacity planning team needs a region-level infrastructure summary. Show the total number of nodes and the number of unique node types per region, ranked by total nodes from highest to lowest.

## Worked solution and explanation

### Why this problem exists in real interviews

Extracting insights from infra_nodes.hostname grouped by region via grouping is the central task. It is used as a fundamentals check to test whether you pick the right aggregation function and partition boundary on the first attempt.

---

### Break down the requirements

#### Step 1: Group by region

`GROUP BY region` collapses all nodes into one row per region.

#### Step 2: Compute total nodes and distinct types

`COUNT(*)` for total nodes and `COUNT(DISTINCT node_type)` for unique types per region.

#### Step 3: Order by total descending

`ORDER BY COUNT(*) DESC` surfaces the densest regions first.

---

### The solution

**GROUP BY with COUNT and COUNT DISTINCT**

```sql
SELECT
    region,
    COUNT(*) AS total_nodes,
    COUNT(DISTINCT node_type) AS unique_types
FROM infra_nodes
GROUP BY region
ORDER BY total_nodes DESC
```

> **Cost Analysis**
>
> With `infra_nodes` (8,000 rows), this query scans a small dataset. No indexing is needed for this volume. At production scale, an index on the primary filter column would improve performance.

> **Interviewers Watch For**
>
> Interviewers evaluate whether you translate the English requirements into the correct SQL clauses on the first attempt. They watch for clean syntax, correct column references, and whether you verify edge cases before declaring the query complete.

> **Common Pitfall**
>
> The most common mistake is misreading the prompt's filtering or grouping requirements. Double-check which columns to group by, which to aggregate, and whether the output should be filtered with `WHERE` (before grouping) or `HAVING` (after grouping).

---

## Common follow-up questions

- If infra_nodes.node_id could contain unexpected NULL values, how would your query behave? _(Tests NULL awareness even when the schema does not currently allow NULLs in node_id.)_
- How would you verify that your aggregation on infra_nodes.node_id is not double-counting due to duplicate rows? _(Tests data quality awareness and deduplication strategies.)_
- What index would you add to infra_nodes to avoid a full table scan when filtering or sorting by node_id? _(Tests practical indexing decisions for numeric filter columns.)_

## Related

- [All practice problems](https://datadriven.io/problems)
- [Mock interview mode](https://datadriven.io/interview/node_summary_per_region)
- [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.