Embeddings are vectors produced by a model so that semantically similar texts map to nearby points, which is what makes meaning-based search possible.
If you have thirty seconds to answer
An embedding is a fixed-length vector of floats representing a piece of text, an image or a user, positioned so that semantically similar items sit close together. That geometry is what makes similarity search, recommendation and retrieval possible — you compare meaning by comparing vectors, usually with cosine similarity. The operational details that matter in interviews are that dimensionality is a cost paid on every query and every byte stored, and that embeddings are only comparable within the model that produced them.
Definition
Embeddings are dense numeric vectors produced by a model trained so that semantically similar inputs land close together in the vector space — by cosine similarity or dot product — even with zero word overlap. "How do I reset my password?" sits near "account recovery steps". That property is the foundation of semantic search, RAG retrieval, recommendation, clustering, and deduplication.
Embeddings are lossy and not reversible — they are not compression, and individual dimensions have no human-readable meaning. Two practical consequences follow: vectors from different embedding models (or versions) are incompatible, so changing models means re-embedding the whole corpus; and comparing millions of vectors needs an approximate nearest neighbor index rather than a linear scan.
How it comes up in interviews
The probe is usually indirect: "how does your search find documents that share no keywords with the query?" Interviewers also like the operational trap — an embedding-model upgrade silently invalidating an index — as a follow-up in RAG designs.
What separates a strong answer
Common answer
"Embeddings capture semantic meaning", restated a few different ways.
What lands
Naming the operational consequence: "the embedding model is part of the index contract — changing it means re-embedding the whole corpus, so I'd dual-write into a second index and cut over once recall matches."
Embeddings interview questions
The forms this comes up in, and what a complete answer covers.
Why cosine similarity rather than Euclidean distance?
Cosine compares direction and ignores magnitude, which suits text embeddings where vector length often reflects document length rather than meaning. Euclidean distance takes magnitude into account, so a long document can look far from a short one that says the same thing. The detail worth knowing is that on L2-normalised vectors the two produce the same ranking — Euclidean distance becomes a monotonic function of cosine similarity — which is why many systems normalise once at write time and then use whichever the index supports.
You want to switch to a better embedding model. What breaks?
Everything already in the index. Vectors from different models occupy different spaces and are not comparable, so a query embedded with the new model and compared against old vectors returns nonsense — and it fails silently, with plausible but wrong neighbours rather than an error. The migration is to re-embed the entire corpus into a second index, evaluate recall against the old one on a fixed query set, then cut over. Budget for it: at large corpus sizes this is a real cost in both compute and time.
How do you choose the number of dimensions?
It is a cost-quality trade, not a quality ceiling. More dimensions can capture more nuance but increase storage, memory and per-query compute linearly, and index build time as well. The right approach is empirical: evaluate retrieval quality on your own data at several sizes and take the smallest that meets the target, since gains flatten quickly. Some models support truncating dimensions with graceful degradation, which lets you trade quality for cost after the fact without re-embedding.
How do embeddings go stale?
The vectors do not change, but the world does. New products, new terminology and shifting user language mean the corpus and the queries drift away from the distribution the model was trained on, and retrieval quality decays without anything breaking. You detect it by tracking retrieval metrics on a refreshed query set over time rather than trusting a one-off evaluation. The response is periodic re-embedding with a newer model, treated as the planned migration above rather than an emergency.