Vector databases interview questions
6 questions across 2 sections, in the order you would learn them. Every answer here is one that works — but an answer you have read is not an answer you can give, so use Test yourself and say it out loud first.
Storing and searching vectors
Read the section that teaches thisIf this comes up in an interview
When do you actually need a vector database?
When exact search stops being fast enough, which is usually well past a hundred thousand chunks, or when you need operational features like filtering, replication and incremental updates. Below that, an array and a matrix multiply, or a vector extension on a database you already run, is simpler.
Then they push further
You have 20,000 chunks. What would you use?
Probably the database you already run, such as Postgres with pgvector, or even an in-memory index. At that size exact search is fast enough, and one fewer system to operate matters more.
What would change your mind?
Tens of millions of vectors, strict latency targets under heavy load, filtering or hybrid search the current store handles badly, or a team that already runs a dedicated store well.
What gets marked up. Marked up for starting from existing infrastructure and real numbers. Reaching for a dedicated vector database by default is marked down.
What does approximate nearest neighbour trade away?
Recall. It searches a promising subset rather than everything, so it can miss a vector exact search would have found. Both HNSW and IVF expose a knob trading accuracy against speed.
What matters most when choosing a vector store?
How well it filters alongside similarity search, because real queries are scoped by tenant, date and permissions. That, plus incremental update and delete, matters far more in practice than benchmark query speed.
Running vector search in Postgres
Read the section that teaches thisIf this comes up in an interview
How do you know your vector index is returning the right results?
Measure recall against exact search on a sample of real queries: run each with and without the index and see what fraction of the true top results the index returns. Then tune the search settings until recall is acceptable at your latency target.
Then they push further
Recall is high but retrieval quality is still poor. Why?
Index recall only says the index agrees with exact search. If exact search itself returns the wrong chunks, the problem is the embeddings, chunking or query, and needs a retrieval eval with labelled relevant chunks.
What gets marked up. Strong answers separate index recall from retrieval quality. Candidates who conflate them are marked down.
You filter by tenant and sometimes get fewer results than you asked for. Why?
The approximate index picks candidates before the filter is applied, and most of them belong to other tenants. Use iterative scanning if your version supports it, partial indexes for large tenants, or exact search within small tenants.
How would you switch to a new embedding model?
Treat it as a migration. Store new vectors alongside the old, backfill, compare on the retrieval eval, switch reads if the new model wins, and keep the old vectors until you are sure.
These are the questions for one topic. The whole question bank covers every topic on the site.