One place to prep for AI interviews and exams.

You upsert a document and query for it 200 milliseconds later, but it never appears. Pick the most likely cause.
Multiple ChoiceEasyAirbnbAnduril
Options
The write landed in a buffer or fresh segment that is not yet searchable; the index has a freshness lag between acknowledged write and queryable vector
The vector was silently rejected because its values were not normalized to unit length
ANN search is approximate, so a brand new vector has a permanently lower chance of being found
The query embedding model must be restarted before it can see new vectors
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you give the application read your own writes without forcing strong consistency on every query?
A
Keep the source of truth in a transactional database. For the just written document, return it directly to the user from the source. For semantic neighbours of older documents, use the vector index. Merge in the application layer.
1 more follow-up an interviewer would ask next. Sign in to reveal them.
Open full question
Fill in the missing term in this description of how HNSW handles deletes.
Fill in BlankEasyDatarobotHebbia
In HNSW, a delete does not physically remove the node from the graph. The vector is marked with a ___ and skipped at query time, until a rebuild or compaction reclaims the space.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does the tombstone pattern interact with strong-consistency reads in a replicated cluster?
A
Tombstones must propagate to all replicas before a deleted id is safe to consider dropped. Otherwise a read that hits a lagging replica still returns the dead id. Cassandra solves this with read repair and gc grace period; vector databases solve it via segment replication and consistency-level configuration.
1 more follow-up an interviewer would ask next. Sign in to reveal them.
Open full question
Select every symptom that points to tombstone bloat in a long running HNSW index.
Multi-selectMediumAdobeRobinhood
Options
Query latency creeping upward over weeks while the live vector count stays roughly flat
Memory footprint refusing to shrink even after large delete jobs complete
Recall dipping for queries that land in heavily churned regions of the corpus
Write throughput climbing steadily as more vectors are deleted
Cosine scores turning negative for normalized embeddings after deletes
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat is the relationship between tombstone ratio and recall, quantitatively?
A
Recall in HNSW depends on neighborhood saturation. If a fraction p of neighbors are tombstoned, effective M drops to M(1-p). Below the saturation threshold (engine-specific, typically M >= 8), recall drops sharply. Plotting recall vs tombstone ratio shows a knee around 30-40% for typical configs.
1 more follow-up an interviewer would ask next. Sign in to reveal them.
Open full question
Match each production search symptom to its most likely vector database root cause.
Match PairsMediumBcgDify
Left and right
Document upserted seconds ago is missing from results
Recall sagging after a bulk delete, latency unchanged
Identical query returns different results run to run
Similarity scores from two collections are not comparable
Filtered queries return fewer than k results despite many matches
Replicas or segments answering nondeterministically with different ANN candidate sets
Tombstones: deleted nodes still occupy and pollute graph traversal
Post-filtering pruning an already small ANN candidate list
Different distance metrics or normalization conventions per collection
Freshness lag: the write sits in a buffer or segment not yet searchable
What an interviewer would ask next. Try answering before peeking at the approach.
QTwo of these symptoms can interact: filtered queries returning below k just after a bulk delete. Diagnose.
A
Tombstones inflate the apparent candidate count during ANN walk, but the post-filter step still rejects them. Result: the engine looks like it searched a healthy candidate set, but most candidates were dead and the filter passed only a few live ones. Compact first, then re-measure.
1 more follow-up an interviewer would ask next. Sign in to reveal them.
Open full question
PremiumA news product ingests…
Multiple ChoiceMediumGoldman SachsJasper
Unlock with Pro to study this question. See Pro pricing.
Open full question
PremiumPick between int8 scalar…
Multiple ChoiceMediumAnyscalePersistent
Unlock with Pro to study this question. See Pro pricing.
Open full question
Pick the right billing model for a search feature that bursts to 2,000 QPS one hour per day.
Multiple ChoiceEasyComet MlGraphcore
Options
Serverless usage based pricing: pay per query and per GB stored, so the 23 idle hours cost almost nothing
Dedicated pods sized for 2,000 QPS, because peak capacity must be reserved around the clock
Self-hosted GPU cluster, since burst traffic always justifies GPU acceleration
Per seat licensing, because cost should track the number of engineers using the database
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would the answer change if the workload were 200 QPS sustained across 12 hours instead of 2,000 QPS for 1 hour?
A
Total queries are similar but duty cycle is 50%, not 4%. Dedicated capacity sized for 200 QPS is small and well utilized, so per-query cost is competitive with serverless. Compute both sides and pick on the lower number plus operational fit.
1 more follow-up an interviewer would ask next. Sign in to reveal them.
Open full question
One billion vectors must live mostly on cheap storage with a 200 ms budget. Decide between SPANN style and DiskANN style designs.
Multiple ChoiceHardAirbnbFlowise
Options
SPANN style: keep only centroids in RAM and fetch whole posting lists per query, a few large sequential reads that tolerate high latency storage well; graph designs like DiskANN need many dependent point reads, which object storage latency punishes
DiskANN style, because graph traversal minimizes total bytes read and byte count is all that matters on remote storage
Neither works: billion scale ANN fundamentally requires all vectors resident in RAM
Either works identically, since ANN algorithm choice is independent of the storage medium's access pattern
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you adapt DiskANN to object storage without rewriting the algorithm?
A
Walk through a hot-subgraph cache (RAM holds the entry points and dense neighborhoods), batching across queries, and locality-aware node packing so neighbor lists arrive in one S3 GET. Be explicit about the recall-vs-cost tradeoff when the cache misses on cold queries.
1 more follow-up an interviewer would ask next. Sign in to reveal them.
Open full question
Predict how often a 16 shard fan out query gets hit by at least one slow shard.
Predict OutputMediumFlowiseHebbia
A vector index is split across 16 shards. Every query fans out to all 16 and must wait for the slowest shard before merging results. Each shard independently exceeds 40 ms (its own p99) on 1% of requests. Predict what fraction of user queries wait longer than 40 ms, and state what this means for the fan out architecture's tail latency.
What an interviewer would ask next. Try answering before peeking at the approach.
QAt what shard count does a per-shard p99 of 1% become unacceptable for an interactive RAG path with a 100 ms user budget?
A
Solve 0.99^N <= target user p99. For a user p99 of 1% (the user wants 1% slow), N = 1. For 5%, N = 5. Push the math to show that interactive fan-out beyond a handful of shards forces hedging or replica racing.
1 more follow-up an interviewer would ask next. Sign in to reveal them.
Open full question
During a background reindex, p99 latency triples while p50 barely moves. Pick the explanation.
Multiple ChoiceMediumArize AiDatadog
Options
The rebuild competes for CPU, memory bandwidth, and page cache; queries that lose the contention race stall, which shows up in the tail while the median stays healthy
Reindexing temporarily converts the index to brute force, making every query proportionally slower
The new index has lower recall, and lower recall always manifests as higher latency
p99 metrics are unreliable during writes and should be ignored until the rebuild finishes
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you architect rebuilds so live serving nodes never see the load?
A
Build on a separate replica or a fresh node, then promote via alias or read-path switch. Qdrant aliases, Pinecone namespaces, and Elasticsearch index aliases all support this. The promotion is atomic and the live nodes never burned CPU on the build.
1 more follow-up an interviewer would ask next. Sign in to reveal them.
Open full question

Showing 1–10 of 2427

← PrevNext →

Follow ups