Start here.

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.

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.

The single most-reported FDE conceptual question across every AI lab. Interviewers don't want definitions; they want the decision framework, the cost math, and the recommendation order that reads senior.

Anyone can list mitigations; the question is really about costs: latency, dollars, and lost recall. The three-layer answer with honest price tags that AI-lab interviewers score highest.

JSON mode, strict schemas, constrained decoding, validate-and-retry: the escalation ladder for structured output, plus the catch nobody mentions: schema-valid can still be factually wrong.

TTFT vs tokens-per-second, the output-length lever everyone forgets, and why streaming is the highest-ROI fix that changes no latency at all. The five-lever answer with real numbers.

The GPU-utilization math that decides this argument, the hidden line items (ops headcount, quality gap, model churn), and the hybrid recommendation that wins both the analysis and the customer.

Two compression levers with very different bills. The arithmetic that decides between them, when to stack both, and the eval discipline that keeps a 'cheaper' model from quietly tanking your hardest 10% of queries.

Million-token windows didn't kill RAG; they changed when you reach for it. The decision rule that holds up in production, and the silent failure each option hides behind a confident answer.

Without a KV cache, generating token N re-attends over all N-1 prior tokens from scratch every step, turning decoding quadratic. The cache stores each layer's past keys and values so each new token costs one forward step, and its size is what caps your batch and context.

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.

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.

'Evals first' is the #1 hiring signal in FDE design rounds. This is the foundational version: what a 50-case golden set looks like, which metrics split retrieval from generation, and the launch gate that convinces interviewers.

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.

Sierra's signature design exercise. The grading hinges on three things most candidates underweight: tool API shape, the read/write trust boundary, and eval cases written before the agent. Walkthrough inside.

A Sierra-signature scenario where 'put it in the system prompt' scores zero. The winning answer is defense-in-depth with a measured catch-rate per layer, plus an honest number for what still gets through.

The staff-level version of 'evals first.' Four layers, each with a job, a cost, and a blind spot, plus judge calibration numbers and the data flywheel that ties production failures back into CI.

Most candidates reach for a smaller model first. The staff answer builds an explicit per-stage latency budget, parallelizes independent tool calls, and spends the time budget where the user actually feels it.

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.

A 500-page doc is well over 200k tokens, and even if it fit, stuffing it in would rot the context. The real design is a working set in context plus an external memory the agent retrieves from and compacts into as it goes.

The most common screen opener, and interviewers use it to check whether hashmap thinking is reflexive. Here's the one-pass answer, the narration that earns points, and the duplicate-handling edge case most candidates fumble.

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 single most-asked design-a-data-structure question in FDE loops. There's an interview-legal Python shortcut and a from-scratch version, and knowing when to offer which is half the grade.

The canonical grid question, and the template for every flood-fill, shortest-path, and region-labeling variant FDE loops throw at you. BFS vs DFS vs union-find: here's which to write and which to merely mention.

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.

Every classifier and every LLM-as-judge eval reduces to a confusion matrix, but the screen is whether you handle the zero-denominator cases without crashing and can say which metric matters for the problem at hand.

The assign-then-update loop is ten lines; the signal is whether you handle the three things that bite in production: initialization, an empty cluster, and a real convergence test instead of a fixed iteration count.

A DP classic that screens for one thing: can you define the right subproblem and fill the table without fumbling the indices. The strong version adds the O(min(m,n)) space trick and reconstructs the actual edits when the follow-up lands.

A sliding window with a last-seen index map, O(n) in one pass. The whole interview turns on one subtlety: when you hit a repeat, the window's left edge must jump forward and never slide backward, which is exactly the bug most candidates ship.

Almost everyone writes the version that only compares each node to its immediate children, and almost every interviewer has a counterexample ready. The fix is to carry a valid (low, high) range down the recursion, or to check that an inorder traversal is strictly increasing.

The round that punishes fluency. Candidates who can draw a class diagram in ninety seconds usually score worst, because they modeled the nouns in the prompt instead of the operations the system has to support.

Every FDE loop opens with this, but the definitions are table stakes. What gets scored is whether you can map each metric to a dollar cost the customer recognizes, here's the framing that does it.

The textbook answer gets a polite nod. The version that names which side of the tradeoff a 6-week customer pilot usually dies on gets the hire signal, here's that version.

"Use regularization" is the answer everyone gives. The ordered toolbox, and which tool to reach for first when a customer's pilot model collapses in week two, is what actually gets scored.

This exact gap kills more customer pilots than any modeling choice. There's a ranked list of culprits, and one of them hides inside innocent-looking feature pipelines at almost every enterprise.

A two-minute explanation, then the real test: learning-rate pathologies, why we use mini-batches, and the one practical diagnosis, reading a loss curve, that customer-facing engineers actually need.

The empirical answer for tabular data hasn't changed in a decade, but interviewers want the why, and the two situations where the default is wrong. A decision table you can defend under panel Q&A.

The 2026 FDE differentiator: customers ask for LLMs by name, and the engineer who knows when a $0 logistic regression beats a $40k/month LLM pipeline, with the cost math, wins the room.

"Run it two weeks and see" fails this question. Strong answers work the power calculation backwards from a minimum detectable effect, and know the duration rules that protect against lying-by-novelty.

The most expensive bug class in production ML: two implementations of 'the same' feature that quietly disagree. The diagnostic that finds it in an afternoon, and the architecture that makes it impossible.

Backprop is just the chain rule run efficiently in reverse, but the question that separates levels is why a hundred-layer network trains when a naive one wouldn't. The credit-assignment intuition plus the three tricks that keep gradients alive.

Accuracy is meaningless for ranking, the whole point is the order. The real question behind the question is whether your relevance is graded or binary and whether one good result is enough, because that picks the metric. Then the trap: your offline NDCG can climb while online engagement falls.

The classic SQL screener at Snowflake and Meta. Everyone can recite the definitions, interviewers are listening for the one scenario where picking the wrong function silently corrupts your results.

The single most-reported live-SQL question in data-platform FDE screens. The pattern is standard, the points are in tie handling, the QUALIFY shortcut, and one aggregation trap most candidates miss.

The hardest 'standard' SQL interview pattern, asked everywhere from Meta to Palantir. There's a three-line trick that turns consecutive runs into a GROUP BY key, once you've seen it, you can't unsee it.

Join fan-out is the bug behind half of all 'the dashboard numbers are wrong' escalations an FDE will ever field. The mechanism, the 30-second detection query, and the three legitimate fixes.

The Databricks signature triage question. Strong candidates don't list optimizations, they run a diagnostic decision tree: plan first, then scan, shuffle, join strategy, files. Here's the tree.

The architecture question both Databricks and Snowflake ask, for opposite reasons. A vendor-neutral framework, what the Delta transaction log really does, and the honest convergence story that scores with both panels.

Sounds like a definition question; it's actually a judgment question. The economics that flipped the industry to ELT, and the four cases (starting with PII) where transforming before load is still non-negotiable.

The pipeline-design question that exposes whether you've ever been paged. One property, idempotency, solves reruns, late data, and backfills at once, and there are exactly three patterns that deliver it.

Four lines of SQL, and one of the three obvious ways to write it returns an empty result set instead of an answer. Not wrong rows. Zero rows, silently, on production data that looks fine.

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 Fermi estimate with a paycheck attached. The interviewers' favorite filter: candidates who jump to a dollar figure miss the two numbers that actually break deployments, peak QPS and tokens-per-minute limits.

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.

The bug only appears under load, the code 'hasn't changed,' and the customer just got charged twice. There's one root-cause pattern behind almost every version of this incident, and a fix with a subtle race most candidates miss.

The Palantir decomposition round has no right answer, it has a right METHOD, and it's the most-failed interview in the FDE loop. Here is the four-move rubric interviewers actually score: clarify, model, spine, iterate.

The defining Palantir-style deployment question. Everything your laptop did silently (package pulls, API calls, telemetry, auth callbacks, clock sync you never thought about) becomes a named workstream. Strong answers produce the checklist by category, not by anecdote.

The CFO sees API invoices; nobody sees the cost of the inference team they're about to hire. The strong answer models utilization, the variable that decides this question, and names the break-even honestly enough to be trusted.

Two questions disguised as one: classic multi-region (where the hard part is data, not compute) and dependency failover (where the hard part is that your fallback model gives different answers). Degraded modes are designed, not improvised.

The capstone FDE question, where every topic in this category shows up as one workstream. The rubric isn't the target architecture; it's whether you can sequence the gap-closing while the customer keeps using the pilot.

The customer's team has to live with this API for years, on a schedule you don't control. The interview is about how you ship changes without a 2 a.m. page on their side.

The most-reported decomposition prompt in the FDE canon. Almost every candidate builds a routing model, and almost every candidate is optimizing the wrong term of the equation.

The single most common FDE behavioral question, and the 'week one' follow-up is where most candidates collapse. Here's the structure that signals you can be dropped into chaos and produce order.

This is a flight-risk filter, not small talk, FDE teams lose hires back to pure SWE roles constantly. The answer that passes is built on evidence, not enthusiasm. Here's what it sounds like.

The 'thanked you later' clause is the trap, it rules out both the pushover story and the stubborn-engineer story. What's left is a specific skill, and interviewers know exactly what it sounds like.

'The customer was dumb' is an instant fail, but so is theatrical self-flagellation. There's a narrow honest lane between the two, and this is what driving down it sounds like.

Every deployment has a skeptic, and 'I showed them data and they came around' is the answer everyone gives. The scored version starts with why they were right to be skeptical.

The modal opener for FDE customer rounds, and most engineers fail it in the first 90 seconds by pitching architecture. Here's the question sequence that scores, and the trap hidden in the word 'chatbot.'

Undefined success is how pilots die in 'one more month' purgatory. Here's the facilitation script that converts 'it should just be good' into numbers, baselines, and a decision date the customer owns.

Interviewers sometimes sabotage demos on purpose to ask exactly this. The recovery has a 60-second protocol, and done well, a broken demo can close harder than a perfect one.

Anthropic's signature values filter, and it screens out two groups: candidates with no real views, and candidates performing views they clearly downloaded last night. Here's what an authentic, FDE-grade answer contains.

Everyone has a model that looked great offline and tanked online. The screen is whether you can tell the root cause from the symptom, and whether your fix was a patch or a guardrail that survives the next model.

The deployment worked. The software runs, the data flows, the demo landed. Nobody is using it. Two of the three research sets we vetted surfaced this from different angles, and it is the failure mode that ends renewals.

An experience probe that sinks more candidates than any design question, because a vague answer ends the interview early. The four-plane structure that proves you're an operator, not a data scientist with MLOps on the resume.

Candidates describe a feature store as 'a database for features' and fail, it's a consistency machine with two faces. The online/offline split, the latency numbers each side must hit, and when you shouldn't build one.

'Retrain weekly' is the answer interviewers let you finish before dismantling it. The four trigger types, how to stop a drift alarm from causing a retraining storm, and why the trigger question is really a cost-and-staleness trade.

Everyone names PSI and KS; almost nobody knows why the KS p-value betrays you at production scale. The thresholds that are actually industry convention, the response ladder behind them, and the trap answer interviewers bait on purpose.

Reported from Capital One ML loops, and the symmetric 'both have pros and cons' answer fails it. Why model failures being statistical makes canary the default, the two cases where blue-green wins, and the entity-randomization detail that survives follow-ups.

CPU-based HPA on GPU inference never fires, the trap half of all candidates fall into within a minute. The signals that actually track load, the anatomy of a five-minute cold start, and which mitigations are worth their cost at each layer.

The experience probe where tool soup fails and one well-told pipeline wins. The context-stack-hardest-problem-outcome structure, the two challenges every real implementation hits, and the before/after numbers that make the story land.

The backbone question of every frontier-lab infra loop. The answer that scores is organized around what each strategy communicates and how often, not just what it splits.

One formula, 2 × layers × KV heads × head_dim × bytes, unlocks every LLM serving capacity question. Worked through for Llama-70B, plus the mitigation stack from GQA to paging.

Why the batch is a pool of decode slots, not a bus that waits until it's full. The mental-model shift behind every modern serving stack, and the scheduling tradeoffs interviewers push on next.

Bits buy bandwidth, bandwidth buys tokens, until quality quietly craters on code and math. A decision framework with the numbers, what GPTQ and AWQ actually do differently, and the eval discipline that keeps you out of trouble.

TP=2, 4, or 8, the answer is a memory budget, a latency target, and one rule: smallest TP that fits, scale with replicas. The worked arithmetic that turns this from vibes into a defensible call.

The back-of-envelope chain every inference-platform round expects: traffic → tokens/sec → per-GPU throughput from bandwidth math → fleet size → dollars. With the headroom factors candidates forget.

Three serving runtimes that look interchangeable on a benchmark slide and aren't. The axes that actually separate them (scheduler, kernels, operability) and the one-line rule for which to reach for.

Do the weight math first, then choose your poison: shrink the weights, split them across GPUs, or spill to host memory. Each buys you the fit at a different cost, and one of them is almost always wrong for production.

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.

Reciting all ten gets you a pass on memory and a fail on judgment. The question is really a prioritization exercise, here's the two-risk answer that maps to how agents actually get breached, and the trap hiding in 'walk me through.'

A verbatim AI-security interview question with a built-in trap: candidates who promise to stop extraction fail, and candidates who shrug 'it's unpreventable' also fail. The winning answer is a layered containment design.

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.

Four frameworks, one product, mostly one set of evidence, the answer interviewers want is the deduplication map. Plus the one thing ISO 42001 covers that nothing else does, and why the labs raced to get it.

A reported Anthropic system-design prompt. The skeleton is standard API platform work; the AI-specific 20%, token-denominated limits, safety classifiers in the path, abuse identity, is what the round actually grades.

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.

A feed touches billions of candidate items and has tens of milliseconds to pick the next 10. The interview is about the two-stage architecture, what you optimize when engagement and integrity pull against each other, and the biases that quietly poison your training data.

A track lasts three minutes, a session lasts an hour, and a new song has zero plays the day it drops. The interview is about blending collaborative filtering with audio content embeddings, surviving cold start on both sides, and reading a skip as the loud negative it is.

Anyone can train a pCTR model. The hard part is proving a change is good before it touches revenue, when the model sits inside an auction, the logs only show ads that won, and a 1% calibration error is real money. This is an eval question, not a model question.

The positive class is maybe 1 in 1,000, your labels arrive late and noisy, and the moment you ship a model the adversary probes it. This is the rare ML problem where the data is actively trying to beat you, so the design is as much about labels, latency, and enforcement cost as about the classifier.

Fraud is well under 1% of transactions, the labels arrive weeks late as chargebacks, and the fraudsters adapt to your model on purpose. Optimizing accuracy gives you a model that approves everything. The interview is dollars-at-risk thresholding, label delay, and a review queue with a fixed headcount.