# Non-Bot Acknowledged Alerts

> Human-acknowledged alerts only.

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

Domain: SQL · Difficulty: easy · Seniority: L3

## Problem

During on-call incident review, pull all alerts that were not acknowledged by 'alice', including alerts that were never acknowledged at all. Show all fields, by the time the alert was fired.

## Worked solution and explanation

### Why this problem exists in real interviews

This focuses on query construction within alert_events, specifically around the svc_name column. Interviewers present it as a fundamentals check because the edge cases around NULL values and boundary conditions reveal depth of understanding.

> **Trick to Solving**
>
> The phrase "not acknowledged by X, including never acknowledged" is a NULL trap. `ack_by != 'alice'` silently drops NULLs.
> 
> 1. Spot the inclusive language about missing values
> 2. Use `WHERE ack_by != 'alice' OR ack_by IS NULL`
> 3. Alternatively: `WHERE COALESCE(ack_by, ") != 'alice'`

---

### Break down the requirements

#### Step 1: Apply the NOT-alice filter with NULL awareness

`WHERE ack_by != 'alice' OR ack_by IS NULL` ensures both non-alice and never-acknowledged alerts are included.

#### Step 2: Order by fired_at

`ORDER BY fired_at` sorts results chronologically as requested.

#### Step 3: Return all fields

`SELECT *` returns the complete alert record.

---

### The solution

**NULL-aware inequality filter**

```sql
SELECT *
FROM alert_events
WHERE ack_by != 'alice' OR ack_by IS NULL
ORDER BY fired_at
```

> **Cost Analysis**
>
> With `alert_events` (12,000,000 rows), the full scan reads significant data. A composite index on the filter columns pushes the predicate into the index layer. Pre-aggregation in a materialized view is worth considering at this scale.

> **Interviewers Watch For**
>
> Interviewers specifically check whether you handle `NULL` in the inequality filter. Candidates who write `WHERE ack_by != 'alice'` without the `OR ack_by IS NULL` clause fail silently on unacknowledged alerts.

> **Common Pitfall**
>
> Writing `WHERE ack_by != 'alice'` alone silently drops all rows where `ack_by IS NULL`, which are exactly the "never acknowledged" alerts the prompt requires.

---

## Common follow-up questions

- What happens to your result if alert_events.severity contains NULLs for some rows? _(Tests whether the candidate accounts for NULL behavior in aggregates and comparisons on severity.)_
- How would you verify that your aggregation on alert_events.alert_id is not double-counting due to duplicate rows? _(Tests data quality awareness and deduplication strategies.)_
- With millions of distinct values in alert_events.alert_id, what index strategy would you use to keep this query performant? _(Tests indexing knowledge specific to high-cardinality columns like alert_id.)_

## Related

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