# Resolved vs Unresolved Alerts

> Resolved versus open. By severity.

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

Domain: SQL · Difficulty: hard · Seniority: L3

## Problem

For each alert severity level, show how many alerts are resolved versus unresolved as separate columns. Treat missing resolution status as unresolved.

## Worked solution and explanation

### Why this problem exists in real interviews

Interviewers use this alerting scenario to test conditional aggregation via CASE against the `alert_events` table. The focus is on how you handle the `severity` column when building the result. It also requires COALESCE for NULL fallback.

> **Trick to Solving**
>
> When the prompt asks for multiple metrics split by a condition (e.g., resolved vs. unresolved), conditional aggregation avoids multiple passes.
> 
> 1. Spot the split: two or more categories in one output row
> 2. Use `SUM(CASE WHEN condition THEN 1 ELSE 0 END)` for each bucket
> 3. Group by the common dimension

---

### Break down the requirements

#### Step 1: Use conditional aggregation with CASE

A `CASE` expression inside the aggregate function splits rows into buckets without multiple passes over the data. Each condition maps to one output column.

#### Step 2: Aggregate by `severity`

`GROUP BY severity` collapses rows to one per group. The aggregate functions (`SUM`, `COUNT`, `AVG`, etc.) compute the metric for each group.

---

### The solution

**Case pivot for resolved vs unresolved alerts**

```sql
SELECT severity, SUM(CASE WHEN COALESCE(resolved, '0') != '0' THEN 1 ELSE 0 END) AS resolved_count, SUM(CASE WHEN COALESCE(resolved, '0') = '0' THEN 1 ELSE 0 END) AS unresolved_count
FROM alert_events
GROUP BY severity
```

> **Cost Analysis**
>
> With ~25M rows, the GROUP BY reduces the working set before any downstream operations. An index on the filter/join columns would reduce the scan to a seek.

> **Interviewers Watch For**
>
> Interviewers watch for how you handle NULL values and whether you account for them in filters and aggregations; whether you can pivot data with conditional aggregation in a single pass instead of multiple queries.

> **Common Pitfall**
>
> Aggregating nullable columns without `COALESCE` can yield NULL instead of zero. Wrap the expression to make the default explicit.

---

## Common follow-up questions

- If `ack_by` in `alert_events` is NULL for some rows, how would your aggregation or join logic be affected? _(Probes understanding of NULL propagation through joins and aggregate functions on `alert_events.ack_by`.)_
- With 20,000,000 distinct values in `alert_events.fired_at`, how would a composite index on the GROUP BY columns change the execution plan? _(Probes understanding of how cardinality in `fired_at` affects grouping and sort operations.)_
- Your COALESCE provides a fallback value. If `alert_id` in `alert_events` is never NULL in practice, does the COALESCE add overhead or get optimized away? _(Tests understanding of COALESCE cost and optimizer behavior.)_

## Related

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