Interview questions

Interview questions (with the counter-questions you'll get)

Q1. How would you implement search for a product catalogue?

They're testing: the end-to-end picture.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Keep the database as the source of truth and feed a search engine like Elasticsearch through change data capture or an outbox. Define a mapping with analyzers per field; rank with BM25 plus field boosts and business signals like popularity and stock. The app sends queries to search, gets IDs back, and fetches details from the database or cache.
3
4**Counter-questions:**
5- *"Why not just use the database?"* → `LIKE '%word%'` scans every row and doesn't rank; built-in full-text search works for smaller cases, but a search engine scales and ranks better.
6
7**Trap:** making the search engine the primary store.

Q2. What is an inverted index?

They're testing: the core data structure.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A map from each term to the list of documents containing it, usually with positions and term frequencies. Single-term queries are one lookup; AND queries intersect lists starting from the rarest term; phrases check positions. Lists are sorted and compressed, and stored in immutable segments merged in the background.
3
4**Counter-questions:**
5- *"How are updates handled if segments are immutable?"* → New versions go into new segments, the old version is marked deleted, and merges clean up.
6
7**Trap:** describing it as just "a hash map of words".

Q3. How does ranking work?

They're testing: relevance basics.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** TF-IDF rewards terms that appear often in a document but rarely across the collection. BM25 improves it with saturation, so repeated terms stop adding much, and length normalisation, so matches in short fields count more. Real systems add field boosts and business signals, and increasingly combine keyword and vector scores.
3
4**Counter-questions:**
5- *"How do you know your ranking is good?"* → Offline judgements on a test set of queries, plus online metrics like click-through, add-to-cart and A/B tests.
6
7**Trap:** stopping at TF-IDF.

Q4. How would you design autocomplete?

They're testing: a classic sub-problem.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A trie (or edge n-grams in a search engine) built offline from popular queries and titles, with the top-K suggestions stored at each node so each keystroke is a short walk. Rebuild periodically, cache hot prefixes, debounce in the client, and personalize lightly if needed.
3
4**Counter-questions:**
5- *"How do you handle trending queries?"* → Count recent queries in a stream (Chapter 20's count-min sketch and top-K help) and merge them into suggestions more often.
6
7**Trap:** querying the database with `LIKE 'prefix%'` on every keystroke at scale.

Q5. How do you keep the search index consistent with the database?

They're testing: data sync and failure thinking.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Avoid dual writes. Use CDC or the outbox pattern so every committed change becomes an event; the indexer applies events with version checks so out-of-order or duplicate events don't regress data, handles deletes, and supports full reindexing to repair drift. Accept that search is eventually consistent, typically by a second or a few.
3
4**Counter-questions:**
5- *"A user edits a title and immediately searches for it. It's not there. What do you do?"* → Read-your-writes in the UI: show the edited item from the database, or wait for refresh for that one write if it really matters.
6
7**Trap:** "write to both" without discussing failures.

Q6. How do you scale a search cluster?

They're testing: shards vs replicas.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Shard by document so the index fits and indexing is spread out; each query scatters to all shards and the coordinator merges top results. Add replicas to increase query throughput and survive node failures. Choose the primary shard count up front, because changing it requires a split or reindex.
3
4**Counter-questions:**
5- *"Why not thousands of shards to be safe?"* → Each shard has overhead, and every query touches every shard, so too many shards slows queries down.
6
7**Trap:** confusing shards (capacity) with replicas (throughput and availability).

Q7. How would you handle typos in search?

They're testing: practical relevance.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Fuzzy matching at query time, allowing one or two edits (Levenshtein distance), usually limited to longer words and with a required matching prefix to stay fast. Add "did you mean" suggestions from query logs, and synonyms for common variants.
3
4**Counter-questions:**
5- *"Cost?"* → Fuzzy queries expand into many candidate terms, so they're slower; limit edits and use them as a fallback when exact search finds little.
6
7**Trap:** no mention of performance.

Q8. What's the difference between keyword search and vector search?

They're testing: modern awareness.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Keyword search matches terms through an inverted index and ranks with BM25; it's precise for exact words, names and codes. Vector search embeds queries and documents as vectors and finds nearest neighbours by meaning, so "car" can find "automobile", using approximate nearest-neighbour indexes. Hybrid search combines both scores.
3
4**Counter-questions:**
5- *"When would keyword search beat vectors?"* → ISBNs, product codes, exact titles and rare names.
6
7**Trap:** saying vectors replace inverted indexes entirely.

Q9. Why is deep pagination slow in a sharded search engine?

They're testing: understanding scatter-gather costs.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** To return results 10,000 to 10,010, every shard must find and send its top 10,010, and the coordinator sorts them all. Cost grows with depth times shard count. Limit page depth, or use cursor-based pagination like search-after.
3
4**Counter-questions:**
5- *"How do you let users export all results?"* → A scroll or point-in-time snapshot API built for bulk reading, not page-by-page queries.
6
7**Trap:** assuming offset pagination is free.

Q10. The search cluster is down. What should the site do?

They're testing: graceful degradation.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Search is a derived copy, so the rest of the site should keep working. Show a degraded search: cached results for popular queries, a simple database prefix search on titles with a strict timeout, or a clear message. Protect the database from a flood of fallback queries with rate limits and circuit breakers (Chapter 29), and rebuild or recover the cluster from the source of truth.
3
4**Counter-questions:**
5- *"What if an index is corrupted?"* → Reindex from the database into a new index, then switch an alias to point at it.
6
7**Trap:** sending all search traffic to the primary database with `LIKE '%word%'`.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 19.1 `LIKE '%word%'` | Level 1A.1, Level 2.1, Q1 |
18| 19.2 Analyzers | Level 1A.2, Level 1B.1, Level 3.1, Level 4, Q7 |
19| 19.3 Inverted index | Level 1A.3, Level 2.2, Level 2.3, Level 3.2, Q2 |
20| 19.4 Ranking | Level 1A.4, Level 1B.4, Level 3.3, Level 5.2, Q3, Q8 |
21| 19.5 Prefix search and tries | Level 1B.5, Level 3.4, Level 5.3, Q4 |
22| 19.6 Index sync | Level 1B.2, Level 3.5, Level 5.1, Q5 |
23| 19.7 Elasticsearch | Level 1A.5, Level 5.5, Q1, Q10 |
24| 19.8 Sharding search | Level 1B.3, Level 2.4, Level 5.4, Q6, Q9 |
25
26---

19. Search and Inverted Indexes