technical · standard
Explain embeddings to a non-technical executive
How would you explain embeddings to a non-technical executive?
This question tests two things at once: whether you have a correct mental model of the technology, and whether you can translate it into language that helps an executive make a decision. The interviewer is not checking if you can recite a definition. They are checking if you can bridge the gap without talking down or over-engineering.
Structure a strong answer
strong
"When users search our product, they use their words, not ours. A customer types 'stop billing me' but our help article says 'cancel subscription.' Keyword search returns nothing. Embeddings solve this.
An embedding model reads a piece of text and converts it into a long list of numbers. Think of it as assigning each sentence a coordinate on a massive map of meaning. Sentences that mean similar things end up close together on that map, even if they share no words.
So 'stop billing me,' 'cancel my account,' and 'I want my money back' all cluster in the same neighborhood. When someone types any of those, we find the nearest help article on the map and surface it, even though the article never used those words.
This is what powers semantic search, the AI assistant pulling relevant context before it answers, and recommendations surfacing similar content. All three rely on the same underlying capability. In our agent features, we also store past user interactions as embeddings so the agent can recall relevant history without stuffing the entire conversation into every prompt. That keeps costs down and responses sharp.
The tradeoff worth knowing: embeddings are fuzzy by design. They struggle with negation ('I do NOT want X' can land near 'I want X') and with exact identifiers like order numbers or SKUs. For those cases, we run keyword search alongside semantic search. The infrastructure decision for leadership is really two questions: what data do we embed, and how fresh does it need to be? That determines our update latency and whether the feature feels smart or stale."
weak
"Embeddings convert words into vectors, where similar words are close together in vector space. This enables semantic search so users find what they mean, not just what they typed." Technically accurate, memorized, and useless to an exec. It does not connect to a product decision, a tradeoff, or a business outcome.
The 2026 version of the weak answer is worse: candidates who can narrate the full RAG pipeline (chunk documents, embed each chunk, store in a vector DB, embed the query at runtime, nearest-neighbor lookup, pass top-k to the LLM) demonstrate pipeline knowledge but cannot say why any of it matters for the product. Interviewers at Glean and Cohere have flagged this as a tell: the candidate read the docs but never shipped.
What the interviewer is actually grading
At AI-first companies the rubric typically has three parts: correct mental model, product grounding (what decisions does this understanding change), and communication (could you say this to a VP without losing them). You need all three. Most candidates clear the first, skip the second, and fail the third.
The follow-up trap
Expect escalation: “What embedding model would you choose and why?” This separates surface-level knowers from decision-makers. The right answer is not a model name. It is a framework: general-purpose models (OpenAI text-embedding-3-large, Cohere embed-v4) cover most cases; code-specialized models (voyage-code-2) outperform on developer tools; domain-fine-tuned models win when your vocabulary is proprietary and training data exists. Wrong model choice degrades retrieval regardless of infrastructure spend.
A second follow-up: “Why can’t we just use keyword search?” The direct answer: keyword search matches tokens, not intent. The moment user vocabulary diverges from your content vocabulary, precision collapses. For high-volume query surfaces with open-ended input, semantic search recovers recall that keyword search cannot. For exact-match lookups (order IDs, product codes), keyword search is faster, cheaper, and more accurate. The strong PM knows both halves.
The 2026 reframe
Feasibility is no longer the question. You can embed and retrieve almost anything cheaply. So the question shifts: does semantic understanding actually make this product more viable or more lovable, or is it infrastructure added because it is fashionable? Embeddings are table stakes at AI-first companies. Knowing what they are is not impressive. Knowing when they earn their place in the product is.
Execs in 2026 have been burned by AI hype cycles. The PM who shows them the real tradeoffs (negation failures, freshness requirements, hybrid search for edge cases) earns more trust than the one who sells only the upside.