Twelve common vector database interview questions
- What is an embedding, and what does similarity between two embeddings mean?
- Cosine similarity, dot product or Euclidean distance — which and when?
- Why use approximate nearest neighbour search instead of exact search?
- How does HNSW work?
- How does an IVF index work?
- What is product quantisation?
- How do you trade off recall, latency and memory?
- How do you filter by metadata during vector search?
- What is hybrid search?
- How do you handle updates and deletes?
- What happens when you change embedding models?
- When is a Postgres extension enough versus a dedicated vector database?
Embeddings and metrics
An embedding is a vector produced by a model so that semantically similar items land near each other. Cosine similarity compares direction and ignores length; dot product includes magnitude; Euclidean distance measures straight-line distance. For normalised vectors, cosine and dot product rank results identically. Use the metric the embedding model was trained for — mixing them quietly hurts quality.
ANN indexes
| Index | How it works | Trade-offs |
|---|---|---|
| Flat (exact) | Compare the query with every vector | Perfect recall; slow at scale |
| HNSW | Multi-layer proximity graph searched greedily from coarse to fine | Fast, high recall; memory-hungry, slower inserts |
| IVF | Cluster vectors; search only the nearest clusters | Lower memory; recall depends on clusters probed |
| Product quantisation | Compress vectors into short codes | Much less memory; some accuracy loss |
| Disk-based graph indexes | Keep most data on SSD | Huge scale cheaply; higher latency |
Every index exposes knobs — HNSW's graph connectivity and search breadth, IVF's number of clusters probed — that trade recall for speed. A good answer describes measuring recall against exact search on a sample and tuning to a target, such as 95% recall at under 50 ms.
Filtering and hybrid search
Real queries combine similarity with constraints: this tenant, this language, documents after a date. Post-filtering — search, then drop results that fail the filter — can return too few results when filters are selective. Pre-filtering restricts the search to matching items but can break graph-index efficiency. Modern engines integrate filtering into the index traversal. Hybrid search combines vector results with keyword results, then fuses the rankings, often with reciprocal rank fusion, which helps with exact names and codes.
Operations
- Updates and deletes: many indexes mark deletions and rebuild or compact periodically; frequent updates can degrade graph quality.
- Re-embedding: a new embedding model makes old vectors incompatible; plan a full re-index, often run side by side before switching.
- Scaling: shard by tenant or hash; replicate for read throughput and availability.
- Multi-tenancy: isolate tenants by namespace or partition so filters stay efficient and data can't leak.
Measuring a vector search system
Interviewers like candidates who talk in numbers. Measure recall@k against exact search on a held-out sample, latency at p50 and p99 under realistic concurrency, queries per second per node, memory per million vectors, and index build time. Then measure what users feel: whether retrieval improvements actually move answer quality in the application. A change that raises recall from 0.95 to 0.99 but doubles latency may not be worth it.
Dedicated database or extension?
A vector extension on an existing relational database is often enough up to millions of vectors, keeps data in one place with transactions and joins, and simplifies operations. Dedicated vector databases earn their keep at larger scale, with heavy filtering, very low latency targets or advanced index types. Interviewers like candidates who start simple and name the point at which they'd switch. See PostgreSQL interview questions.
Practising
Reading answers is not the same as saying them. Pick ten of the questions above and answer them aloud against a timer; a free AI interview assistant like CoPilot Interview can ask vector search questions in a mock interview and flag answers that ran long or lacked an example. Pair this with RAG interview questions, since most vector database questions arrive inside a retrieval design.
Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly. Everything else on this page applies whichever tool you use, or none.
Frequently asked questions
What is a vector database?
A database optimised for storing embeddings and finding the most similar vectors to a query quickly, usually with approximate nearest neighbour indexes, metadata filtering and scaling features.
How does HNSW work?
HNSW builds a multi-layer graph where each vector links to near neighbours. Search starts at a sparse top layer and greedily moves closer to the query, descending through denser layers to find approximate nearest neighbours.
Cosine similarity or dot product?
Use whatever the embedding model was trained with. For normalised vectors they give the same ranking; dot product also accounts for vector magnitude.
Do I need a dedicated vector database?
Not always. A vector extension on an existing database is often enough for millions of vectors. Dedicated systems help at larger scale, with heavy filtering or strict latency targets.
Practise on real interview questions
Run 145 real interview questions across 10 tracks, answer out loud and see a structured answer to compare with yours. Free, no signup.
Try a practice question