# The Scorched Earth Reviews > Someone left a trail of one-star wreckage. Round up every product they burned. Canonical URL: Domain: SQL · Difficulty: easy · Seniority: L3 ## Problem The quality assurance team is pulling all products that received the lowest possible rating (1) to investigate whether there's a common defect. Show each product's name and rating. ## Worked solution and explanation ### What this is really testing This is a one-line equality filter wearing a data-quality costume. The whole skill being probed: read 'the lowest possible rating (1)' and write `rating = 1`, resisting every urge to reach for something fancier. The trap is the float. `rating` is a REAL column, so a candidate who reads 'lowest' as 'low' and writes `rating <= 2`, or who builds a `MIN()` subquery to 'find the floor first', pulls back 1.5s and 2.0s the QA team never asked for. Get it wrong and you hand quality assurance a defect list that is half noise. --- ### Break down the requirements #### Step 1: Filter to exactly rating = 1 'The lowest possible rating (1)' is an exact value, not a band. `WHERE rating = 1` matches only the rock-bottom score. Because the column is a REAL, the literal `1` compares equal to the stored `1.0`, so no cast is needed. #### Step 2: Return product name and rating `SELECT product_name, rating` returns the two fields the prompt asks for and nothing else. There is nothing to group or aggregate here: every qualifying row is its own answer. --- ### The solution **Exact equality filter on rating** ```sql SELECT product_name, rating FROM products WHERE rating = 1 ``` > **Common Pitfall** > > The tempting wrong answer is `WHERE rating <= 2` (or `< 2`), which reads 'lowest' as 'low' and drags in 1.5s and 2.0s. The QA team wants the exact floor, not everything near it. The second miss is treating `rating` as an integer or over-engineering with a `MIN()` subquery when a plain equality literal already does the job. > **Interviewers Watch For** > > On easy filters like this, the tell is restraint. A strong candidate writes the equality and stops; a weaker one reaches for GROUP BY, HAVING, or a subquery that the problem never needed and then has to defend the extra machinery. Interviewers also watch whether you notice `rating` is a float before assuming an integer comparison. > **Cost Analysis** > > With `products` at 12,000 rows this is a trivial full scan. At production scale, a B-tree index on `rating` turns the equality filter into a cheap index seek, since `rating` has low cardinality but the target value (1) is rare. --- ## Common follow-up questions - Some rows have a NULL rating. Are they included or excluded by your filter, and is that what you want? _(Tests NULL-comparison awareness: rating carries a 6% null fraction, and NULL = 1 is never true.)_ - How would you verify there are no duplicate product rows inflating this result? _(Tests data-quality awareness without assuming any aggregation exists.)_ - If this ran against billions of product rows, what index would keep the rating = 1 lookup cheap? _(Tests practical indexing decisions for a low-cardinality numeric filter at scale.)_ ## Related - [All practice problems](https://datadriven.io/problems) - [Mock interview mode](https://datadriven.io/interview/the_scorched_earth_reviews) - [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.