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
Real world examples
Real products, models, and research that use this idea.
- Pinecone serverless documents a freshness layer with second scale staleness for the most recent writes before they merge into the main index
- Elasticsearch and OpenSearch ship with a one second default refresh interval; per request refresh exists for tests but is the wrong default for production
Sign in to see more production examples.
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.
Real world examples
Real products, models, and research that use this idea.
- Cassandra writes tombstone cells for deletes; the same term and pattern are inherited by Milvus and Qdrant for vector deletions
- RocksDB merges tombstones during compaction; vector engines that wrap RocksDB inherit the behavior for delete reclamation
Sign in to see more production examples.
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
Real world examples
Real products, models, and research that use this idea.
- Weaviate emits a tombstone-count metric per shard and triggers cleanup based on a configurable threshold so operators can monitor proactively
- Vespa's content nodes run continuous compaction on attribute and document stores with explicit tombstone-aware logic for write-heavy feeds
Sign in to see more production examples.
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
Real world examples
Real products, models, and research that use this idea.
- Pinecone serverless documents eventual consistency and provides freshness latency metrics so teams can debug missing-write symptoms without guessing
- Qdrant exposes payload pre-filtering as a first-class feature precisely so users avoid the post-filter pruning trap on selective filters
Sign in to see more production examples.
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
Real world examples
Real products, models, and research that use this idea.
- Pinecone serverless prices reads per million queries and storage per GB-month, optimized for low-duty-cycle workloads like consumer search bursts
- Turbopuffer markets itself on object-storage-native economics where storage is the dominant cost and queries pay only when fired
Sign in to see more production examples.
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
Real world examples
Real products, models, and research that use this idea.
- Turbopuffer's object-storage-native vector engine implements a SPANN-style posting-list layout because per-request S3 latency makes graph traversal nonviable
- Pinecone serverless keeps centroids and metadata in a hot tier while posting lists live on S3, the same separation SPANN proposed
Sign in to see more production examples.
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.
Real world examples
Real products, models, and research that use this idea.
- Pinecone serverless query planner spreads each query across many partitions and uses internal timeouts to cap the slowest-shard wait rather than blocking on it
- Turbopuffer pulls posting lists in parallel from object storage and caps total fan-out latency with a deadline, accepting partial results when a fetch overruns
Sign in to see more production examples.
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
Real world examples
Real products, models, and research that use this idea.
- Qdrant supports aliases so a rebuilt collection on a sidecar node can be promoted atomically, avoiding in-place rebuild on the serving node
- pgvector HNSW build is single-threaded by default and saturates one CPU and the page cache; teams run it on a maintenance replica before promoting
Sign in to see more production examples.
Open full question
Production recall dropped overnight with no deploy. Order the investigation from cheapest check to most invasive.
Order StepsHardBraintrustCognizant
Items to order
Verify the alarm itself: rerun the recall eval and check whether the ground truth set or eval corpus snapshot went stale
Inspect index health stats: tombstone ratio, segment counts, and any large bulk delete or ingest jobs that ran overnight
Audit config drift: did a managed service or library auto upgrade silently change default ef_search, nprobe, or quantization settings
Probe the embedding provider: re-embed a fixed sentence set and diff against stored vectors to detect a silent model version change behind the same API name
Rebuild or compact the index in staging from source data and compare recall to production to isolate index corruption or accumulated degradation
Real world examples
Real products, models, and research that use this idea.
- Pinecone serverless reshards data plane segments on its own schedule; teams have caught recall dips traced to mid-reshard ef_search defaults.
- Voyage AI voyage-3 and OpenAI text-embedding-3-large have both had stable API names while internal versions changed, exactly the case the canonical-sentence probe catches.
Sign in to see more production examples.
Open full question
Your nightly index rebuild takes 14 hours on CPU and the maintenance window is 2 hours. Pick the most direct fix.
Multiple ChoiceEasyDoordashPatronus
Options
Build the index on GPU with CAGRA (cuVS), which cuts graph construction from hours to minutes, then serve it from CPU memory
Raise ef_search so queries compensate for the unfinished index
Switch the distance metric from cosine to dot product to speed up construction
Shrink the dataset by deleting the oldest half of the vectors before each rebuild
Real world examples
Real products, models, and research that use this idea.
- NVIDIA cuVS ships CAGRA as the build path used by Milvus, FAISS, and Weaviate for GPU-accelerated index construction in 2026
- Pinecone's serverless tier rebuilds indexes on GPU-backed build pools and serves queries from CPU-backed read pools, decoupling the two cost curves
Sign in to see more production examples.
Open full question
Estimate the raw vector storage for 10 million 768-dim float32 embeddings before any index overhead.
Predict OutputEasyAmdHugging Face
Your team is sizing a new vector database deployment. The corpus is 10,000,000 documents, each embedded once with a 768 dimension model stored as float32 (4 bytes per dimension). Ignoring graph or index overhead, metadata, and replication, estimate the raw storage for the vectors alone.
Real world examples
Real products, models, and research that use this idea.
- Pinecone capacity calculators expose exactly this formula in their UI; users enter dim, count, and quantization to get sizing.
- Pgvector documentation walks through the same calculation when advising on `shared_buffers` and instance sizing.
Sign in to see more production examples.
Open full question
Order the migration steps for moving 8M vectors from Pinecone to pgvector with zero query downtime.
Order StepsMediumCredFreshworks
Items to order
Provision Postgres with pgvector, create the table, choose the distance operator, and plan HNSW parameters to match production recall needs
Enable dual writes so every new upsert and delete is applied to both Pinecone and Postgres
Bulk export historical vectors plus metadata from Pinecone and COPY them into Postgres, then build the HNSW index
Shadow query both systems with mirrored production traffic and compare recall, latency, and result overlap
Shift read traffic to Postgres gradually behind a flag, watching error rates and tail latency
After a stable soak period, stop dual writes and decommission the Pinecone index
Real world examples
Real products, models, and research that use this idea.
- Supabase has documented Pinecone-to-pgvector migrations for cost-driven moves; their template follows the dual-write plus bulk-load shape.
- Neon and Crunchy Data publish similar migration playbooks for managed Postgres with pgvector targeting Pinecone customers.
Sign in to see more production examples.
Open full question
Pick the workload where an object storage backed serverless vector database beats a RAM resident cluster on cost.
Multiple ChoiceMediumFireworks AiKpmg
Options
Thousands of mostly cold tenant indexes (agent memory, per customer document stores) queried sporadically, where paying RAM prices for idle vectors dominates the bill
A single hot index serving 20,000 QPS at a strict 10 ms p99, where every query must hit warm memory
A high frequency trading signal store where microseconds of latency decide profitability
A 50k-vector prototype, where infrastructure cost is irrelevant either way
Real world examples
Real products, models, and research that use this idea.
- Turbopuffer is built explicitly on object storage with a cache tier; pricing materials show roughly 10-100x cost reduction on long-tail multi-tenant workloads.
- Pinecone Serverless decouples storage from compute and bills storage at object-storage rates plus a separate query unit; their launch post highlighted thousands of small tenant indexes as the killer use case.
Sign in to see more production examples.
Open full question
Predict the storage blowup when moving from single vector embeddings to ColBERT style multi-vector retrieval.
Predict OutputHardDroomH2o Ai
A search team wants to upgrade from single vector retrieval (one 1024-dim float32 embedding per document) to ColBERT style late interaction, which stores one 128-dim float32 vector per token. Documents average 100 tokens after truncation. Predict the per document storage multiplier for the vector data, and name the standard mitigation that makes multi-vector deployable at scale.
Real world examples
Real products, models, and research that use this idea.
- ColBERTv2 / PLAID published by the Stanford Stanford-FutureData group quantizes residuals to about 2 bits per dimension to bring storage close to single-vector parity.
- Vespa supports multi-vector documents natively and pairs them with HNSW per token plus aggressive ranking-stage pruning.
Sign in to see more production examples.
Open full question
Order the zero downtime cutover sequence for swapping embedding models under live traffic with rollback safety.
Order StepsHardHugging FaceMckinsey
Items to order
Create a new collection for the new model's vectors, with its own dimension, metric, and index parameters
Start dual writes: every new and updated document is embedded with both models and written to both collections
Backfill the historical corpus into the new collection in rate limited, checkpointed batches
Shadow read: mirror a slice of live queries to the new collection and compare retrieval quality offline
Flip read traffic to the new collection behind a feature flag, keeping dual writes running so rollback is instant
After a stable soak period, stop dual writes, archive or drop the old collection, and retire the old model
Real world examples
Real products, models, and research that use this idea.
- Pinecone documents the dual-collection migration pattern explicitly: create a second index, dual write, backfill, flip, retire.
- Notion AI's switch from one embedding model family to another used a multi-week dual-write window so any single query could be served by either index during the cutover.
Sign in to see more production examples.
Open full question
Design the retrieval architecture when 95% of queries carry five or more metadata predicates of wildly varying selectivity.
Short AnswerHardAmazonDify
An enterprise document platform runs vector search where 95% of queries combine semantic similarity with five or more metadata predicates (department, ACL groups, date ranges, doc type, region), and predicate selectivity swings from 0.01% to 80% depending on the query. Design the architecture: how metadata is indexed, how the engine chooses a filtering strategy per query, and what you partition versus filter.
Real world examples
Real products, models, and research that use this idea.
- Qdrant ships payload indexes plus ACORN-style filtered HNSW so the engine can pre, post, or filter-traverse per query without app-level glue.
- pgvector with HNSW relies on Postgres B-tree and GIN indexes for predicates; the query planner uses statistics to choose between pre-filter and post-filter paths.
Sign in to see more production examples.
Open full question
Estimate the compression from truncating 3072-dim Matryoshka embeddings to 1024 dims and then binary quantizing.
Predict OutputMediumCloudflareDeepseek
Your embeddings are 3072 dimension float32 vectors from a Matryoshka trained model. To cut index memory you stack two techniques: first truncate each vector to its leading 1024 dimensions (safe because Matryoshka training front loads information), then binary quantize the truncated vector to 1 bit per dimension. Full precision vectors stay on disk for rescoring. Estimate the in memory compression factor versus the original float32 vector, showing bytes before and after.
Real world examples
Real products, models, and research that use this idea.
- OpenAI text-embedding-3-large supports Matryoshka truncation from 3072 down to 256 dims directly via API; the leading dims are the highest-information
- Cohere embed-v3 ships with binary quantization built into the SDK and recommends rescoring against the original vectors stored separately
Sign in to see more production examples.
Open full question
A filter matches 0.1% of 100M vectors. Predict whether pre-filter brute force or post-filter ANN serves it faster.
Predict OutputMediumLlamaIndexObserve Ai
A query carries a metadata filter matching just 100,000 of 100M vectors (0.1% selectivity). Option A: pre-filter, then brute force exact search over only the matching vectors (1024-dim float32, SIMD distance kernels available). Option B: run HNSW over the whole index and post-filter the candidates, oversampling until k=20 filtered results survive. Predict which option wins and roughly what each costs per query.
Real world examples
Real products, models, and research that use this idea.
- Qdrant has an explicit query planner that estimates filter cardinality and switches between pre-filter exact scan and filtered HNSW traversal automatically
- pgvector with HNSW now supports iterative scans that traverse the index while applying filters, with planner hints when statistics are wrong
Sign in to see more production examples.
Open full question

Showing 1–20 of 2427

← PrevNext →

Real world examples