# Search Terms Starting With G

> Queries starting with 'g'.

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

Domain: SQL · Difficulty: easy · Seniority: L3

## Problem

The search relevance team is debugging why queries starting with 'g' return fewer results than expected. Pull all such search terms alongside their results count.

## Worked solution and explanation

### Why this problem exists in real interviews

Drawn from a search behavior domain, this question centers on pattern matching with LIKE over the `search_queries` table. The tricky part is handling the `search_term` column correctly under the given constraints.

---

### Break down the requirements

#### Step 1: Filter with pattern matching on `search_term`

The `LIKE 'g%'` pattern narrows the result to matching rows. The `%` wildcard matches any sequence of characters.

#### Step 2: Select the target columns

The SELECT clause picks exactly the columns the prompt asks for. Returning extra columns or missing a required alias would fail the grading check.

---

### The solution

**Pattern-match for search terms starting with g**

```sql
SELECT search_term, results_count
FROM search_queries
WHERE search_term LIKE 'g%'
```

> **Cost Analysis**
>
> With ~30M rows, the query performs a single sequential scan. An index on the filter/join columns would reduce the scan to a seek.

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

> **Common Pitfall**
>
> Forgetting the `%` wildcard or placing it on the wrong side changes the match semantics entirely. `LIKE 'x%'` matches prefixes; `LIKE '%x'` matches suffixes.

---

## Common follow-up questions

- What would happen to your result if `search_queries.results_count` contained duplicate values that you did not expect? _(Tests whether the candidate considers data quality issues in `results_count` and uses DISTINCT or deduplication where needed.)_
- `search_queries.query_time` has roughly 30,000,000 distinct values. What index strategy would you use to avoid a full scan on `search_queries`? _(Tests indexing knowledge specific to the high-cardinality `query_time` column in `search_queries`.)_
- Your LIKE pattern may prevent index usage on `search_queries`. How would you restructure the filter to be index-friendly? _(Tests understanding of leading-wildcard LIKE and its impact on index scans.)_

## Related

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