Vector Database Interview Questions: HNSW, IVF, Filtering, and Recall vs Latency

Your HNSW index returns 50 neighbors in 18 ms with 96% recall. Add a tenant, category, and inventory filter, and the same query returns 11 results in 140 ms. The vectors did not change. What failed?

That is the kind of production reasoning behind strong vector database interview questions. Interviewers may ask what HNSW or IVF stands for, but senior candidates are expected to connect index mechanics to filters, memory, freshness, tail latency, and measurable retrieval quality.

Start with PracHub's real enterprise RAG system question, then practice designing a semantic search API with metadata filters. Use the broader interview question bank with written solutions to rehearse the follow-ups an interviewer can add.

Quick Answer: Choose the Index From the Workload

Exact search is the quality baseline; HNSW, IVF, and quantization are ways to spend less compute or memory by accepting controlled approximation. A good answer starts with corpus size, query volume, write rate, filters, hardware, latency SLO, and a recall target. It then proposes an index and explains how that choice will be tested.

Flat: Best for small or highly selective sets and quality ground truth. Distance work grows with vectors searched, so optimize batching, hardware, or candidate reduction.

HNSW: Strong for read-heavy, low-latency search when memory is available. Pay for graph memory, build, and update behavior; tune efSearch, then validate M and efConstruction.

IVF: Useful for large corpora suited to trained clustering. Neighbors outside probed lists can be missed, so tune nprobe against the chosen nlist.

IVF-PQ: Fits memory-constrained or very large collections. Compression adds quantization error; tune code size, probes, candidate count, and reranking.

Filtered search: Required for tenant, ACL, inventory, or date predicates. Selectivity and correlation drive filter placement, candidate budget, and partitioning.

How to Structure a Vector Search Interview Answer

Use this sequence: workload, metric, exact baseline, candidate index, filtering, lifecycle, measurement. Clarify the number and dimension of vectors, top-k, QPS, write rate, hardware, freshness, tenant distribution, common filters, and latency percentile before naming a technology.

Then define what “good” means. For ANN quality, recall@k is commonly measured as the fraction of the exact top-k neighbors that appear in the approximate top-k. Pair it with application metrics, enough-results rate, p50/p95/p99 latency, throughput, memory, build time, and cost. One average latency and one global recall number are not enough.

Core Vector Database Interview Questions

1. When should you use exact search instead of ANN?

Use exact search when the candidate set is small enough, traffic is modest, or correctness matters more than the saved compute. Exact search is also how you build ground truth for evaluating an approximate index. Faiss's official index-selection guide identifies Flat indexes as the option that guarantees exact results.

ANN becomes attractive when exhaustive distance calculations cannot meet the latency, throughput, or cost target. The answer is not “large data means HNSW.” A selective tenant filter may reduce 100 million global vectors to 8,000 eligible rows, making an exact filtered scan entirely reasonable.

2. How do cosine similarity, dot product, and L2 distance differ?

The metric must match how the embedding model was trained and how vectors are normalized. Dot product preserves both direction and magnitude. Cosine compares direction by dividing by vector norms. L2 measures Euclidean distance.

For unit-normalized vectors, maximizing dot product and cosine gives the same ranking; squared L2 is also a monotonic transformation of that dot product. Faiss therefore supports cosine search by normalizing vectors before inner-product search. State the normalization policy at both indexing and query time, because a mismatch silently changes ranking.

3. How would you measure recall versus latency?

Create an exact top-k result for a representative query set, then run the ANN index across a parameter sweep. Plot recall@k against p50, p95, and p99 latency, while holding hardware, concurrency, cache state, and filtering conditions constant.

Slice results by tenant size, filter selectivity, query type, embedding version, and shard. Also report how often the system returns fewer than k eligible results. The chosen operating point should satisfy a product target, not simply maximize an offline benchmark.

HNSW Interview Questions

4. How does HNSW search work?

HNSW builds a hierarchy of proximity graphs. Sparse upper layers provide long-range navigation; denser lower layers refine the search near the query. Search starts near the top, follows promising neighbors, and descends until it explores candidates in the base layer.

The original HNSW paper by Malkov and Yashunin describes this multi-layer graph and its probabilistic layer assignment. In an interview, explain the intuition first. Reproducing pseudocode is less valuable than identifying how search breadth, graph connectivity, and memory affect the operating point.

5. What do M, efConstruction, and efSearch control?

M controls graph connectivity and therefore influences memory, build work, and search quality. efConstruction controls how broadly the index explores while inserting nodes; a larger value can build a better graph but costs more time. efSearch controls query-time candidate breadth; increasing it usually improves recall while increasing latency.

These are tuning levers, not universal presets. Benchmark them on the real vector distribution and filtered query mix. If the candidate claims one magic value works across models, tenants, and hardware, the answer is incomplete.

6. Where does HNSW become difficult?

HNSW can consume substantial memory because it stores both vectors and graph links. Build time, deletes, frequent updates, cold storage, and filtered traversal also require implementation-specific planning. For example, Faiss's HNSW implementation does not support removing vectors directly, while database products may add tombstones, compaction, or rebuild workflows.

Separate the algorithm from the product. “HNSW supports X” is often really a statement about one implementation's update, persistence, or filtering behavior.

IVF and Product Quantization Interview Questions

7. How does an inverted file index work?

IVF trains a coarse quantizer that assigns database vectors to clusters, often called inverted lists. At query time, the system finds nearby centroids and searches vectors in only a subset of those lists. The speedup comes from avoiding most of the corpus; the recall loss occurs when a true neighbor sits in an unvisited list.

Training data must represent the production vector distribution. Poor sampling, distribution shift, and severely imbalanced lists can produce uneven work and weak recall even when the nominal parameter values look reasonable.

8. What is the nlist versus nprobe trade-off?

nlist is the number of inverted lists. nprobe is how many lists a query searches. More probes generally increase recall and distance computations. Too many lists can also make training and assignment more expensive, while too few create large candidate buckets.

Faiss's IVF documentation emphasizes that list lengths are uneven and that the searched fraction is only approximately nprobe / nlist. Tune from measured recall-latency curves instead of treating that ratio as a guarantee.

9. When would you add product quantization?

Product quantization splits a vector into subspaces and represents each with a compact code. This reduces memory traffic and storage, enabling a much larger corpus per machine, but approximate distances introduce additional error. The original Product Quantization paper describes this compressed-distance approach.

A common design retrieves a wider candidate set with IVF-PQ and reranks a smaller shortlist using full-precision vectors or a stronger model. The interviewer wants to hear what memory constraint justified compression and how much retrieval quality the team is willing to trade.

Filtering Is Where Vector Search Answers Get Real

10. What is the difference between pre-filtering, post-filtering, and inline filtering?

Pre-filtering reduces the eligible set before vector search. Post-filtering runs ANN first and removes ineligible results afterward. Inline filtering applies predicates during ANN traversal or candidate expansion. Each can be appropriate depending on selectivity, cardinality, correlation, index support, and the cost of an exact filtered scan.

Google Research's filtered vector search overview frames these strategies and explains why filters change both the effective dataset and search effort. There is no universally best order.

11. Why can post-filtering return fewer than k results?

Suppose the ANN stage examines 50 candidates and only 10% pass the filter. It may leave roughly five eligible results even though thousands of valid vectors exist elsewhere. Increasing k or overfetching can help, but the required factor depends on selectivity and whether the predicate is correlated with vector neighborhoods.

The pgvector filtering documentation gives a concrete implementation example: approximate-index filtering occurs after the index scan, and iterative scans can expand the search until enough rows are found or a limit is reached. That behavior is useful evidence, not a rule for every vector database.

12. How would you fix filtered recall without destroying latency?

First measure by filter selectivity. For very small eligible sets, use a scalar index plus exact vector scoring. For broad filters, ANN plus normal filtering may work. For the difficult middle, test iterative search, larger candidate budgets, filter-aware traversal, selective partitioning, or two-stage retrieval.

Index frequently filtered fields when the product supports it. Qdrant, for example, documents payload indexes and a filterable HNSW design that can add filter-aware graph edges. Treat that as one implementation strategy, then explain how you would benchmark it against alternatives.

13. How should multi-tenancy change the design?

Compare a shared index with tenant predicates, per-tenant namespaces or partitions, and dedicated indexes for large or regulated tenants. The decision depends on tenant count, size skew, isolation, noisy-neighbor risk, update lifecycle, and operational cost.

Tenant and permission predicates are correctness constraints, not relevance preferences. Never relax an authorization filter just to fill the top-k. Track eligible-corpus size and enough-results rate separately so a genuine shortage is not confused with ANN failure.

Production Vector Search Interview Questions

14. How do you handle fresh writes, updates, and deletes?

Version the embedding model, preprocessing, distance metric, and index together. New writes can enter a small mutable or exact-search delta index while a larger optimized index is rebuilt or merged. Deletes may require tombstones and compaction, depending on the product.

Use blue-green index builds for major embedding changes, verify coverage and recall before traffic shifts, and keep rollback possible. A query embedding produced by version B should not silently search an index built with incompatible version A vectors.

15. What changes when the index is sharded?

Each shard returns local candidates, and a coordinator merges them into a global top-k. The system may need to overfetch from each shard because a small local k can miss globally competitive results. The slowest shard, fan-out, network time, and merge work all affect tail latency.

Discuss routing by tenant or region when it reduces fan-out without harming balance. Also account for replicas, hot tenants, shard skew, resharding, and index build placement rather than treating sharding as a free horizontal scale switch.

16. Offline recall is good, but online search quality is bad. What do you check?

Verify embedding and normalization versions first. Then compare live queries with the benchmark distribution and inspect filter selectivity, index freshness, deleted data, shard routing, cache state, candidate limits, and reranking. Replay the same query against exact search and the production ANN path.

Slice the gap by tenant, query type, language, vector norm, index age, and result count. If ANN recall remains strong but users still fail, the problem may be the embedding model, relevance labels, hybrid retrieval, or downstream reranker rather than the index.

A Complete Filtered-Search Incident Walkthrough

Return to the opening incident. Unfiltered HNSW is healthy, but tenant, category, and inventory predicates produce 11 of 50 requested results and increase p95 latency. Do not begin by doubling efSearch. First reproduce the query against the exact eligible set and verify that 50 valid items actually exist.

Next, record eligible-set size, filter selectivity, candidate count before and after each predicate, shard, and index version. The exact search proves the relevant items exist. The ANN stage is post-filtered, tenant membership is correlated with graph neighborhoods, and repeated retries expand the candidate budget, explaining both low result count and high latency.

A defensible experiment might look like this:

experiment:
  ground_truth: exact_top_50_with_all_filters
  slices: [tenant_size, filter_selectivity, category, shard]
  variants:
    - hnsw_post_filter: {ef_search: [64, 128, 256], overfetch: [2, 5, 10]}
    - iterative_filtered_scan: {max_candidates: [500, 2000]}
    - tenant_partition_plus_hnsw: {large_tenants_only: true}
  report:
    - recall_at_50
    - enough_results_rate
    - p50_p95_p99_latency
    - qps_cpu_memory
  decision: meet_quality_and_latency_slos_by_slice

The likely solution is not one global setting. Small tenant sets may use exact filtered search, large tenants may receive dedicated partitions, and the shared middle may use iterative or filter-aware ANN. The interview signal is the measurement-driven routing policy.

How Interviewers Score Vector Database Answers

Framing: Clarifies scale, filters, writes, hardware, SLO, and top-k before choosing a vendor.

Index mechanics: Connects HNSW and IVF parameters to costs and failure modes instead of repeating acronyms.

Filtering: Reasons about selectivity, correlation, and enough-results rate instead of saying “just post-filter.”

Evaluation: Uses exact ground truth, representative slices, recall, and tail latency rather than one global benchmark.

Operations: Covers freshness, versions, deletes, shards, and rollback instead of treating the index as static.

Judgment: Proposes an experiment and decision rule without claiming one index is always best.

A Focused 5-Day Preparation Plan

For the full mock, answer PracHub's RAG system with evaluation question. Force yourself to name the exact baseline, filtered-search strategy, recall slices, freshness path, and release criteria instead of stopping at “use a vector database.”

Frequently Asked Questions

Is HNSW always better than IVF?

No. HNSW often offers a strong recall-latency trade-off when memory is available, while IVF can fit trained, clustered, or compressed search at very large scale. Build time, writes, memory, filtering, hardware, and target recall determine the better choice.

What is a good recall@k target?

There is no universal target. Choose it from downstream quality, failure cost, latency, and budget. Evaluate against exact neighbors on representative queries, then verify whether changes in ANN recall actually affect search, recommendation, or RAG outcomes.

Why do metadata filters hurt vector search?

Filters change which vectors are eligible and may break the assumptions of an ANN candidate search. Post-filtering can discard most candidates; pre-filtering may leave a small or fragmented set; inline filtering requires index support. Selectivity and correlation determine the best execution strategy.

Should FAISS be called a vector database?

Faiss is primarily a similarity-search and clustering library, not a complete database service. A production database may add persistence, replication, filtering, access control, APIs, and lifecycle management around an ANN index. Clarifying that boundary is a positive interview signal.

Practice the Trade-Off, Not the Acronym

A strong candidate can explain why a relevant vector was missed, how much extra search would recover it, what that recovery costs at p99, and whether an exact or partitioned path would be safer. That is more valuable than memorizing that HNSW is a graph and IVF uses clusters.

Use PracHub for real interview questions with written solutions, then add company-specific interview prep for your target loop. Senior candidates should also turn the opening incident into a story for behavioral and leadership interview practice: how you isolated the failure, protected tenant correctness, and changed the team's release test.

Sources

• Malkov and Yashunin: Efficient and Robust Approximate Nearest Neighbor Search Using HNSW
• Faiss: Guidelines to Choose an Index
• Faiss: Index Types and IVF Search Parameters
• pgvector: Filtering and Iterative Index Scans
• Google Research: Filtered Vector Search
• Qdrant: Vector, Payload, and Filterable HNSW Indexing
• Jégou, Douze, and Schmid: Product Quantization for Nearest Neighbor Search