# Green Lights on the Order Line

> How often did the orders API just... work?

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

Domain: SQL · Difficulty: easy · Seniority: L3

## Problem

Reliability is auditing the orders service. How many API calls to the '/api/v1/orders' endpoint returned a successful 200 status? Return the count as success_count.

## Worked solution and explanation

### Why this problem exists in real interviews

This tests whether a candidate can demonstrate writing clean, correct queries under time pressure. This is a foundational check that interviewers use early in a round to verify baseline proficiency.

---

### Break down the requirements

#### Step 1: Select the target columns

The SELECT clause picks exactly the column the prompt asks for: a single count aliased success_count. Returning extra columns or missing the required alias would fail the grading check.

#### Step 2: Verify the output shape

Confirm the result has the expected column, ordering, and no duplicate rows. A quick sanity check that the count is a single scalar catches logic errors before submission.

---

### The solution

**Count api_calls matching endpoint and status predicates**

```sql
SELECT COUNT(*) AS success_count
FROM api_calls
WHERE status = 200 AND endpoint = '/api/v1/orders'
```

> **Cost Analysis**
>
> With ~100M rows, the query performs a single sequential scan. An index on the filter columns (status, endpoint) would reduce the scan to a seek.

> **Interviewers Watch For**
>
> Interviewers watch for whether the query returns exactly the column and alias the prompt specifies; how quickly you identify the core operation and write clean, minimal code.

> **Common Pitfall**
>
> Returning extra columns that the prompt did not ask for, or using the wrong column alias instead of success_count, causes a grading mismatch even when the logic is correct.

---

## Common follow-up questions

- If status is stored as TEXT ('200') rather than INTEGER, what subtle bug could arise in your equality check against the orders endpoint? _(Tests type-awareness; comparing integer literal 200 to text may silently cast or fail depending on the engine.)_
- Would COUNT(*) and COUNT(call_id) produce different results here, and when would they diverge? _(Tests understanding of COUNT behavior with NULLs vs. row presence.)_
- How would you extend this to also show the average latency of those successful '/api/v1/orders' calls in the same query? _(Tests ability to add an aggregate without restructuring the query.)_

## Related

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