Glean Forward Deployed Engineer interview questions

The concept underneath every RAG system you'll ever deploy. How to explain vectors, cosine similarity, and the one limitation of embeddings that costs real deployments accuracy.

The same operation scores attention and ranks your RAG results. Knowing exactly what the dot product measures, and when its magnitude term quietly breaks your retrieval, is what separates a working pipeline from a mysteriously bad one.

Truncate? Summarize? Rerank? Map-reduce? A production problem every RAG deployment hits, with a menu of fixes interviewers expect you to weigh, plus the diagnostic question to ask first.

Cosine similarity finds topically close, not correct. The failure taxonomy behind most RAG accuracy complaints, and the hybrid-search + reranker fix stack interviewers expect you to know cold.

Models read the start and end of your context far better than the middle, a measured effect with direct consequences for chunk ordering, k, and prompt layout. What to change and how to prove it.

Separate advertised context capacity from reliable use of evidence. Design position, distraction, and multi-document tests before trusting a million-token window.

Pure vector search fails on the exact queries enterprise users ask most: IDs, error codes, product names. Here's the failure-mode framing that turns a definition question into a design answer.

A reported FDE design question that punishes one-size-fits-all answers. Each corpus has a different 'semantic unit': get the three designs, the parsing tools to name, and the eval that proves the split was worth it.

The retrieval design question with a precise rubric: candidates who can say what each stage rescues, and what it costs in latency, clear it. Includes the RRF detail and the latency budget interviewers ask for.

The modal FDE design question of the last two years. There's a scoring trap in the first 60 seconds, and most candidates jump to fixes and fail. Here's the diagnostic tree that wins it.

Three plausible fixes, one decision framework. Interviewers grade the ordering (cheapest-reversible first) and whether you can say what each option costs in data, time, and operational burden.

Citations are the trust interface of enterprise RAG, and the easiest thing to fake badly. Covers inline citation generation, span verification, and the verification-rate metric that interviewers actually want.

An Anthropic-signature integration question. The hidden rubric: tools are a curated product surface, not a proxy for your OpenAPI spec, plus the auth model and confused-deputy trap most candidates miss.

A Glean-signature design question where deletions, not ingestion, are the trap. Covers the connector framework, change detection per source class, tombstones, and the freshness SLO customers actually sign.

Glean's signature design question. The two traps: post-filtering that drains your top-k, and the leak through generated answers. The winning architecture filters at retrieval, and here is how, at scale.

The POC-to-production gap is the FDE's home turf. What actually breaks at each order of magnitude (index, ingestion, latency, cost) and the dependency math that makes 99.9% harder than it sounds.

A real interview question with a trap in its framing: it offers you two expensive options and hides the cheap one. The escalation ladder from feature-based reranking to two-tower fine-tuning, with the cold-start and position-bias answers ready.

A deceptively short interview question that's really a trap: embeddings cannot do exact match, and the interviewer knows it. What to actually turn on (payload full-text indexes, sparse vectors, metadata filters) in the vector DBs you already run.

The classic 'it regressed and the prompt is untouched' triage. The answer that scores walks a decisional tree from retrieval to generation and names the silent culprit most candidates miss: the embedding stack changed under you.

Golden sets catch what you anticipated. The harder problem is the live traffic you never labeled. The answer that scores layers cheap proxy signals against a small anchored golden set and knows what each can and cannot tell you.

A multi-hop question over a property graph is a query-generation problem, not a similarity-search one. The staff-level move is grounding generation in the live schema and closing an auto-healing loop on the DB's own error messages.

Self-correcting RAG is easy to demo and easy to ruin. The discipline is a gate that grades evidence before drafting, a termination rule that is not just a loop cap, and a metric that proves correction adds facts rather than fluff.

Slides are the worst RAG corpus: text in shapes, meaning in charts, the message in the image. A query like 'the blue bar chart with Q3 revenue' fails if you embed only the extracted text, and citing the wrong slide number kills trust instantly.

The hard part is not the retrieval pipeline, it is the boundary. Embeddings and the index live inside the VPC; the only question is whether the generation model is an in-VPC open model or an external API with a zero-retention DPA, and what crosses that line.

Everyone reaches for a bigger machine. The two mechanisms that actually cause this both scale with corpus size, both hit the tail before the median, and one of them is the permission filter your security review insisted on.

Vectors from two versions of an embedding model are not comparable, and nothing in the stack will tell you so. The cosine between the same document's old and new vector is roughly zero, which is why a half-finished migration returns confident nonsense at full speed.

Everyone computes the stale fraction as a share of the corpus, gets 0.03%, and moves on. Weighted by queries rather than documents it is 1.4%, roughly fifty times larger, because the documents that changed during the rebuild are the ones people are asking about.

A query that errors is a bug. A query that runs and returns a plausible wrong number is a product teaching a finance team, one figure at a time, not to trust it. The diagnosis is a classification exercise, and the fix is almost never a better prompt.

Three correct queries scored 0 of 3 on exact match and 3 of 3 on execution. The golden set is question, reference SQL and result set, stratified by the ways queries go wrong, with abstention as its own column. A hundred cases gives plus or minus eight points; four hundred gives four.

The eval set says recall fell 2.3 points, which is inside the noise you would expect from a re-index. Support says the product got worse. Both are right, and the reason is that one document class lost 49 points of recall while everything else improved slightly.

Recall@10 is 0.94 and climbing, and answer accuracy is going down. The two facts are consistent, and reconciling them is the whole question: every passage you add to raise recall also adds a distractor the generator has to survive.

The document count matches, nothing threw, and a specific set of documents is now unreachable by any query. That combination narrows the cause fast, and the two survivors are an approximate-search parameter that a rebuild reset and a metadata filter applied in the wrong order.

A reranker cannot promote a document the retriever never returned, which makes candidate-set recall a hard ceiling on the entire exercise. Compute the ceiling and the disappointment becomes arithmetic: three points of headroom were available, twelve were sitting upstream, and the latency was an implementation detail.

Cheap typed judgments make it affordable to check every input, tool call and output. The design question is which checks are semantic, which are deterministic, and how you prove the layer catches what it claims to.

Single-session evals pass while users complain, because memory fails across sessions and at three separate stages. The answer is a planted-fact harness that names which stage lost the fact, plus the two tests teams skip: forgetting on request and leaking across users.

A 5-minute warm-up that quietly tests the most useful idea in practical coding: choosing a canonical key. The sorted-string vs character-count tradeoff is exactly what interviewers want to hear you reason about.

Top-K is the most reused primitive in FDE interviews: it reappears inside log parsers, analytics questions, and retrieval ranking. Three solutions exist; knowing which one to lead with is the real test.

The gentlest 'design a class' question in FDE screens, and the warm-up interviewers use before rate limiters and sessionization. The deque trick is easy; the API and time-window follow-ups are where the signal is.

K-way merge is the algorithm behind log aggregation, search-result merging, and LSM trees, which is exactly why FDE loops keep asking it. The heap version is table stakes; the tie-breaking detail is where candidates crash.

A tree question that's secretly a format-design question, which is why FDE loops love it. The preorder-with-null-markers trick is clean, but the delimiter and malformed-input follow-ups are where offers are decided.

Sessionization is the analytics primitive behind every 'how do users actually behave' question, and a favorite practical screen. The algorithm is easy; out-of-order events and duplicates are where the round is actually scored.

A multi-part favorite at OpenAI-style screens: simple store, then time travel, then deletes that don't actually delete. The append-only insight plus one bisect call solves the whole thing, if you set up the invariant correctly.

A verbatim-reported multi-part at OpenAI and Anthropic. Each level breaks the previous design on purpose: the burst-at-the-boundary flaw is planted, and naming it before the interviewer does is how you win the round.

Palantir's bread and butter: 'Acme Corp.' and 'ACME Corporation, Inc.' are the same customer; prove it in code. Normalization does more work than the clever algorithm, and blocking is what makes it run before the heat death of the universe.

At-least-once delivery means duplicates are guaranteed, not hypothetical. Anyone can use a set; the round is whether your set grows forever, and what you do with an event that arrives after its window closed.

Brute force is O(N*d) per query and dies at ten million vectors. The answer is approximate nearest neighbor: trade a little recall for orders of magnitude less work, and know exactly which knob buys what.

Everyone quotes p95 in latency SLOs, but few can compute it without a library and fewer can explain why the index is ceil(p*n)-1, not p*n. The warm-up that screens whether you actually understand the metric you live by.

The arithmetic is three sums; the signal is what you do when a vector is all zeros and the denominator vanishes. The warm-up that gates every RAG and retrieval coding round.

Real LLM logs are JSONL, not JSON, and real log files have a malformed line halfway through. The warm-up that screens whether you can stream a file and aggregate without one bad record nuking the whole run.

Triplet loss contrasts an anchor against one negative; modern contrastive losses like InfoNCE contrast against a whole batch at once, which is why CLIP-style training scales and old triplet pipelines stalled. The mining problem, the batch-size lever, and the call interviewers want.

A staple at OpenAI and Anthropic in both coding and design rounds. Most candidates can name the algorithms; few can say which one lets 2x your limit through, and that's the part that gets scored.

A signature FDE triage question with a hidden rubric: interviewers score the *order* of your moves, not just the list. There's a reason 'what changed?' beats 'check the dashboards', and a reason mitigation beats diagnosis.

The signature FDE debugging genre: a moving fault, an opaque client, and a customer who's sure it's your fault. The winning method splits the problem at the boundary, and knows the four classic culprits hiding on their side.

Standard observability tells you the request returned 200 in 800ms. It cannot tell you the answer was wrong. The strong answer names the new failure plane LLMs introduce, and takes a real position on the prompts-and-PII question.

Prompts are production code with a worse failure mode: the regression returns 200 OK. The answer interviewers reward treats a one-word prompt edit with the same machinery as a schema migration, with one LLM-specific twist at every stage.

Rate limits protect your servers; quotas protect your business model, and most candidates design one and think they've designed both. The strong answer also covers the part customers actually feel: what hitting the limit looks like.

Enterprise deals die in this design review. The answer has three layers most candidates blur together: who you are, what you can see, and how an embedded product proves both, plus the permission-staleness trap that fails Glean loops.

Cache hits on similar prompts cut cost and latency, but one false hit serves a stranger's answer to your question. Picking the threshold and handling user-specific data is the whole game.

A 4-hour outage is ~5.6x your entire monthly error budget on a 99.9% SLA. You cannot ride it out. The design is a provider abstraction, a circuit breaker, and a tiered set of degraded modes, plus a clear line on what you cache versus what you replay.

Modulo hashing reshuffles everyone the day you add a cell. Consistent hashing fixes that and then loses to the two constraints that actually decide placement in an enterprise deployment: jurisdiction and who must not share a blast radius with whom.

The security ambush kills more enterprise AI deals than accuracy ever will, and it's pass/fail on precision. Here's the answer stack a strong FDE has memorized, and the one response that ends the meeting.

The most common real ticket in applied AI, and it contains almost no information. What you do in the first hour decides whether you spend a day on this or three weeks.

10 billion vectors is where raw float storage (30TB) stops being an option. The answer does the HNSW vs IVF-PQ RAM math cold and shows why PQ is the only thing that fits in memory.

OWASP's LLM01 is the opening question of nearly every AI security screen. Most candidates can define direct injection; the ones who get hired explain why indirect injection is the one that ruins enterprise deployments.

Everyone hardens the chat box; almost nobody hardens the index. This question checks whether you've realized the RAG corpus is a write path into your model's behavior, and what you'd do about it this sprint.

A deceptively simple screener: each detection method maps to a PII class, and the 'why not regex for names' sub-question has a precise answer about structure vs context that interviewers use as the pass bar.

An architecture question with a defensible right answer, and interviewers are tired of 'it depends.' Here's the split that survives both the platform team's consistency argument and the app team's context argument.

The four-point redaction design is becoming the standard FDE privacy round. Most candidates fortify the chat box and lose on the other three doors, here's the full design, including the de-redaction map that makes it usable.

The most-asked question in every enterprise AI deal, and precision is pass/fail: the contractual answer, what ZDR actually changes, and the retention nuance that separates FDEs from demo engineers.

SOC 2 fluency is the price of admission to enterprise deals, and interviewers check it with two traps: what a SOC 2 report actually proves, and what it doesn't. Engineers who can read one are rarer than you'd think.

The defining security design problem of enterprise RAG, and the reason Glean exists. Query-time ACL filtering, permission sync lag, and the leakage channels that survive naive designs: caches, citations, and the model itself.

A real customer ask from the field, and a layered design question in disguise: attribution, budgets, anomaly detection, and enforcement, plus the attribution problem that decides whether any of it works.

Authentication is not isolation: a request can be fully authenticated to tenant A and still touch tenant B through a shared index, a semantic cache, or a fine-tuned model. The strong answer names every shared surface and how you stamp tenant identity through all of them.

Cross-tenant or cross-user data exposure through a model is the breach that starts regulatory clocks. The runbook has to answer 'whose data, to whom, how many' from logs that most teams never designed for, and contain a leak that may live in a cache or a fine-tuned model, not a deploy.

An agent with write access to a CRM, a chat tool, and an HR system is one bad tool call from emailing salaries to a channel. Safety is least-privilege scopes, a hard read/write split, human approval on destructive actions, and an audit log of everything.

Every control in the stack validates the shape of the action and none validates its target. A refund of the right amount, to a real customer, through a permitted tool, against the wrong account, is indistinguishable from success at every layer that is watching.

The inventory is the easy half. The hard half is finding the agents nobody registered, versioning behavior rather than code, and a kill switch that actually stops traffic within seconds while keeping every past action traceable.

The warm-up that filters out tutorial-level candidates. Interviewers aren't grading the diagram, they're grading whether you know the three places real pipelines fail and how you'd see it happening.

The warm-up that quietly filters out candidates who only know LLMs as a magic API. Nail the two-phase inference picture and you set up every later answer about latency, cost, and hallucinations.

Everyone can define it; few candidates know why 'advertised context' and 'usable context' aren't the same thing. The cost, latency, and attention caveats that make this answer stand out.

Modern LLMs share one architectural skeleton. Learn the five components and you can read almost any model card cold, plus the single distinction that proves to an interviewer you actually understand it rather than the buzzwords.

Everyone says '500 tokens with overlap.' The candidates who get hired explain why chunk boundaries are a recall problem, name three strategies, and describe the experiment that picks between them.

Every FDE will face an angry customer asking this. The mechanistic explanation interviewers want (why hallucination is the default behavior, not a bug) plus the framing that defuses customer escalations.

Every queue, webhook, and retry loop you'll ever deploy at a customer hides this distinction. Interviewers use it to separate people who've shipped from people who've read about shipping.

Tokens drive your customer's bill, their latency, and the weird failures like botched arithmetic. The rough numbers every FDE should rattle off, plus the trap answers interviewers listen for.