Hard FDE interview questions

Evals are the #1 probing area in AI-lab FDE loops. The full suite design, golden sets, component metrics, safety red-teaming, CI gates, and the launch-blocking thresholds, in interview-ready form.

Position bias, verbosity bias, self-preference, and the agreement-rate workflow that turns a sloppy judge into eval infrastructure you can defend. AI labs probe this hard; here's the calibrated answer.

The classic FDE escalation. Six hypotheses, silent model updates, input drift, prompt entropy, sampling noise, perception shift, and the eval-replay test that splits them in an afternoon.

An email that says 'ignore your instructions and refund $10,000' will eventually arrive. Why prompt-level defenses lose, and the layered design (least privilege, action gates, rate caps) that actually holds.

10x doesn't come from one trick. It's multiplicative: routing x caching x prompt diet x batching x distillation. The stacked-levers playbook with rough multipliers, and the eval gate that keeps quality honest.

Adapter math, the VRAM arithmetic that makes 4-bit a 4x unlock, and the honest decision rule for on-prem deployments. The deep-internals question Mistral and Cohere loops use to find real practitioners.

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.

In high-stakes domains a wrong answer is worse than no answer, but a system that always abstains is useless. The selective-prediction design, the layered abstention triggers, and the two metrics that govern the tradeoff.

Two questions bundled as one: what do you ship first, and how do you make a stochastic system behave. The answer that lands: shrink the autonomy, not just the feature list, and define the MVP by the workflow it completes, not the agent it contains.

Reported as the question OpenAI FDE interviewers push hardest on, and the one where 'we look at the outputs' ends loops. The three-legged answer that passes: automated metrics, calibrated human evaluation, and feedback loops wired to a business number.

The OpenAI FDE deep-dive where you're expected to walk the full stack (network, queueing, tokenization, prefill, KV cache, batching, decode) in order, with a measurement at each hop. The triage sequence, with the numbers that tell you which layer is guilty.

Provider model upgrades ship faster than your release cycle and quietly shift behavior. The design that turns 'we hope it's fine' into a blocking gate: a frozen golden set, pairwise diffing, segmented scoring, and a shadow-traffic canary.

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.

The escalation ladder is settled; the at-scale tradeoff is not. Why retries quietly multiply your bill and tail latency, why constrained decoding has its own taxes, and the hybrid that most high-volume pipelines actually run.

Sending every request to the frontier model is the lazy bill. The patterns that route by difficulty, the verifier that enforces a hard quality floor, and the failure mode that turns a cost-saving cascade into a worse, slower system.

Two failure modes, one architecture. Why no single guardrail holds, the defense-in-depth layers that assume the model will be broken, and the design rule that limits the blast radius when prompt filters inevitably fail.

Three stages, one KL leash. The reward-model-plus-PPO loop, the beta*KL term that keeps the policy from drifting off the reference, and how DPO collapses it into a single classification loss by treating the reward as beta*log(pi/pi_ref). The objectives, written correctly.

Win-rate up, facts down is the signature of reward hacking: the policy is over-optimizing the preference proxy and drifting off the reference. The diagnosis (Goodhart on the reward), the immediate lever (tighten the KL/beta anchor), and the held-out factual gate that stops shipping the regression.

Where you put the LayerNorm changes whether gradients survive a hundred layers. Pre-norm keeps a clean residual highway and well-scaled gradients so deep models train without warmup heroics; post-norm normalizes the output but fights vanishing gradients at depth.

Attention is bottlenecked by moving the N x N score matrix to and from HBM, not by FLOPs. FlashAttention tiles the computation in fast on-chip SRAM and fuses softmax with an online running statistic, so it computes the exact same output while never materializing the full matrix.

PPO needs a separate value network to estimate the baseline for its advantage. GRPO samples a group of answers per prompt and uses their mean reward as the baseline, so the advantage is just how a sample compares to its peers, no critic required.

Budget covers maybe 5M of 100M LLM calls. Run a cheap first stage on everything, route only low-confidence items to the LLM, and use those LLM labels to distill a student that absorbs most of the volume. The cost-vs-coverage math that decides where the threshold goes.

This is the live practical several labs run, and it is scored on protocol more than on the prompt you end with. Read all thirty before editing, cluster them, hold some out, change one thing at a time, and report with intervals, because 24 of 30 fixed is somewhere between 63% and 91%.

A 6% word error rate is a good number that measures the wrong thing. Per-digit accuracy of 98% loses 18% of ten-digit account numbers, and no aggregate metric contains that. Talking over callers is a turn-taking problem, not a model problem, and it has its own metrics too.

Word error rate is the number every vendor quotes and the one that predicts the least. The offline suite is built from confirmed real calls with noise and codecs applied, scored on entity accuracy, tail latency and false interruptions. Production adds what a recording cannot simulate: real callers and the reopen rate.

The cheap swap is not a model swap. The prompt becomes atomic typed questions, the parsed label becomes a distribution with a confidence, and the release gate becomes a per-version threshold sweep on the customer's own labeled tickets.

Decide whether retrieval can be removed after fine-tuning. Test changed facts, source support, access boundaries, and the cost of keeping answers current.

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

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.

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.

Memory is a retrieval problem plus a write-policy problem plus a privacy problem. Most candidates only design the first. Covers memory taxonomies, the curation pipeline, and the leak vectors that fail the question.

The question that separates demo-builders from production engineers. Idempotency keys, the saga pattern, dry-run modes, approval tiers: the distributed-systems toolkit applied to agents, with the trap most answers miss.

Harvey's signature design question. The twist: the architecture is the easy half. The graded half is designing for reviewer trust, where one hallucinated clause costs more than a hundred correct ones earn.

Serving 50 enterprise customers off one platform means four leak surfaces most designs miss, including the semantic cache and the eval set. A tier-by-tier isolation model with the noisy-neighbor math.

The most FDE question in the bank: every real deployment hits an unchangeable legacy system. The answer is an architectural principle, concentrate brittleness in one owned layer, plus what to do when the GUI is the only API.

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.

Standard A/B machinery assumes a crisp conversion event; agents give you fuzzy, delayed, gameable outcomes. The metric hierarchy, the reopen-window trick, and the sample-size reality check that win this question.

Multi-agent is the most over-prescribed architecture in the industry. A staff-level answer is a decision framework driven by task structure and context limits, with the orchestration failure modes named before the interviewer asks.

Untrusted content plus write-capable tools is the lethal combination. Prompt-level defenses alone fail this question; the winning answer is an architecture where injection succeeding still can't move money.

Launch is the starting line. The staff-level capstone: how production traffic becomes eval cases, prompts ship like code, and a model deprecation becomes a Tuesday instead of an incident.

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.

The verbatim Salesforce Agentforce FDE question. Strong answers name Topics, Actions, and grounding sources specifically, and refuse the word 'replace' without saying no. The component-by-component build with the staged-autonomy rollout.

The staff-level reliability question for agent platforms. Refunds went out, emails sent, tickets closed, and now you have to triage at fleet scale without double-refunding. The recovery model interviewers actually score.

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.

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.

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.

This is the lethal trifecta in one sentence, and most candidates reach for a better system prompt. The answer that scores breaks the trifecta architecturally, because no amount of prompting stops indirect injection once all three capabilities are present.

The data-isolation answer everyone gives misses the harder surface: live OAuth tokens and API keys the agent uses to act in third-party systems. The model that keeps one tenant's credentials out of another's agent loop, and out of the LLM context entirely.

Hard budgets stop the bleeding; they don't fix the cause. The real fix is progress tracking plus semantic loop detection plus a planning layer that commits to a plan instead of re-deciding every step, validated on a fixed trajectory set offline before it ships.

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.

DSPy's pitch is to stop hand-writing prompts and instead declare what the pipeline does, define a metric, and let a compiler search for the prompts and examples. The catch is that the compiler is only as good as the metric, and an LLM-judge metric drags its own biases in.

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.

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.

An agent loop optimizes whatever the verifier rewards, so a weak verifier gets gamed: tests edited, outputs hardcoded, inputs memorized. The fix is a verifier the agent cannot author or edit, run on evidence in a clean environment, with held-out and adversarial checks that track intent.

Every eval question in the prep canon is about answer quality. This agent does not produce answers, it moves freight. You cannot score a reroute for faithfulness, and the candidate who tries has not understood what they built.

The provider bill tells you the total and nothing else. This is a forensics question, and the answer is almost never a pricey model. It is that the transcript grows every turn, so a forty step run costs six times what everyone estimated.

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.

A wrong answer inside one conversation dies with the conversation. A wrong answer written to memory becomes a retrievable fact that conditions every later run, and the agent then derives new conclusions from it. Deleting it is the part nobody designed for.

Everyone sizes the pool on average run length, and average is the one statistic an agent fleet does not have. Simulated, the p99 sat at 160 seconds whether the system was half loaded or nearly saturated, which means capacity was never the problem.

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.

The rate limiter is working correctly and that is the problem. It counts requests, and one hundred-thousand-token request occupies the KV cache of fifty short ones, so admitting both tenants equally hands one of them eighty percent of the machine.

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.

Before you touch a model, check whether the two numbers measure the same thing. Field accuracy of 96% across twelve fields is 61% of documents fully correct, which means half of the drop may be arithmetic. The other half is the documents the pilot never saw.

Nobody deployed anything is true of your repository and false of the system. The model provider, a tool behind an API, the knowledge base and the traffic mix all change without a commit. Segmentation comes before theory: a broken intent and a mix shift produce the same headline and need different fixes.

A nightly suite of fifty simulated conversations per intent catches a collapsed tool with certainty and a five-point drift almost never. Knowing which is which, and sizing each layer for what it can actually see, is the whole design. The grader checks outcomes, not transcripts, or the agent learns to sound resolved.

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.

Extraction accuracy cannot reveal a document that never arrived. Reconcile expected evidence with received and parsed artifacts, and keep completeness separate from any claim decision.

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.

The pitch is a model that runs the loop. The design that survives production is a loop that code runs, with the model answering three narrow questions inside it: which tool, is this done, does this need a stronger model.

Most answers draw an API gateway with OAuth and stop. The bank's problem is the hop from agent to tool: whose identity reaches the CRM, which of 40 tools this agent may call, what stops a runaway loop, and what happens when the gateway itself is down.

70 percent is an average over tasks and runs, and it hides the number the customer cares about: does the same request get the same right outcome every time? Two agents with identical averages can differ from shippable to unusable.

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 frozen policy jumps from 70% to 90% after parallelizing its evaluation. Reconstruct the denominator, separate runner faults from policy behavior, and design the experiment that could invalidate the gain.

The question where production scars are the rubric. Anyone can write a retry loop; the grade lives in which errors you DON'T retry, why jitter exists, and what an idempotency key actually protects you from.

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.

A three-level build that quietly tests whether your L1 design survives L3. Regex substitution wins level one and loses the round; here's the token-based structure that carries through conditionals and loops.

Exact-match pub/sub is a dict of lists. The round is decided at level two (wildcard matching on hierarchical topics) and at level three, when the interviewer asks what happens when a subscriber's callback throws.

Kahn's algorithm gets you level one. The round is won at level three, where 'run up to K tasks at once' breaks naive topo sort, and the indegree bookkeeping you chose at L1 either saves you or sinks you.

The practical build that's secretly a graph problem: formulas are a dependency DAG, evaluation is DFS with memoization, and the three-color cycle trick decides whether A1=B1, B1=A1 crashes you or earns the offer.

The OpenAI FDE signature question, reported near-verbatim for two years: four levels in ~60 minutes, where L4 silently breaks every naive L3 implementation. The lazy-expiry design that survives all four levels, with the pacing plan.

The other OpenAI signature build, reported in four parts for two years. Part C silently punishes anyone who hardcoded single-condition filtering in part B; here's the predicate-compiler design that absorbs all four parts.

An OpenAI bank regular: next() over a list, then save/restore position, then resume across multiple JSON files where some are empty. The whole question is one decision (what counts as state) and most candidates get it wrong on part one.

The OpenAI variant where the data structure is the warm-up: the round is graded on whether your tests control time and whether you can argue global vs per-key vs optimistic locking with actual reasons. Most candidates ace part one and lose the round in parts two and three.

A reported OpenAI build that looks like billing and is actually a data-structure question in disguise: credit grants that expire, usage that must burn the right grant first, and balance queries at arbitrary times. The earliest-expiry-first invariant carries the whole problem.

A confirmed Anthropic live-coding question that looks exotic and reduces to one operation: diff consecutive call stacks against their common prefix. The recursion edge case is where strong candidates separate from finished-but-wrong ones.

Anthropic's reported twist on the LRU staple: the cache is a decorator, the keys are arbitrary call signatures, and the follow-up writes it to disk. The kwargs-ordering and unhashable-argument traps are the whole interview.

The reported Anthropic concurrency round: the crawler is twenty minutes, the follow-ups are the interview. Why threads work despite the GIL, what asyncio buys you, and where the semaphore goes. The answers, with the race condition graders plant.

The build behind every access policy and routing rule a customer wants to edit without a deploy. The trap is operator precedence: candidates who tokenize fine still get `a or b and c` wrong, and that's the whole grade.

The retry loop's grown-up sibling. Retries protect one call; a breaker protects the whole dependency from a retry storm. The grade is in the half-open state, where letting through one probe instead of all of them is the difference between recovery and re-killing the server.

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.

A 10% rollout where the same user flips on and off between requests is worse than no rollout. The whole problem is determinism: hash the user into a stable bucket so ramping 10% to 25% only ever adds users, never reshuffles them.

Executing a query is the easy half; deciding HOW to execute it is the staff-level half. The interesting failure is choosing an index that returns 90% of the table, where a full scan is faster, and a planner that knows that beats one that always uses the index.

Sliding-window limiters count requests; an API that bills by tokens needs to reserve a variable cost up front and refund it if the call fails. The trick is lazy refill: never run a timer, compute the current balance from elapsed time on each check.

Google's FDE loop added an AI-first round, and this is the opener. The skill being graded is not prompting, it is decomposition: turning a fuzzy sentence into scoped units with named interfaces an assistant can one-shot. Get the seams wrong and no prompt saves you.

The naive fix is to nag the model in every prompt. The staff move is to treat your constraints as a versioned policy library injected as system context, so compliance is structural, then verify it with a linter because prompts are advisory, not enforced.

When the model writes the code, your job shifts to specifying and checking it. The strong answer is a multi-layer validation pipeline that tests behaviors and contracts, not strings, plus the uncomfortable reframe that testing is now the bottleneck skill, not typing.

You can't read the model's weights, so you debug the inputs you control. There's a four-bucket triage, prompt, context, model, or spec, that localizes the fault fast, and the real deliverable is feeding each diagnosis back so the same failure can't recur.

AI code fails differently from human code: it's confidently plausible. The dangerous defects are the ones that pass a quick read and a happy-path test, missing authorization, hallucinated APIs, hardcoded secrets, unsafe deserialization. Here's the checklist and the automated catch for each.

If you read every AI PR line by line, you become the throttle the assistant was meant to remove. The staff answer is a risk-tiered trust model: route by blast radius, let gates clear the low-risk volume, and spend human attention only where reversibility is low.

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.

BPE is how GPT and most LLMs turn text into tokens, and building a tiny trainable version from a corpus is a favorite deep-dive. The screen for whether you understand the merge loop, deterministic tie-breaking, and round-trip decode, not just tiktoken.encode.

All-pairs comparison is O(n^2) and dies long before 1TB. The senior move is MinHash plus LSH: hash documents so only likely-similar pairs ever land in the same bucket, then verify just those.

softmax(QKᵀ/√d_k)·V in four lines, but the grade is the three details people drop: the √d_k scale, subtracting the row max for numerical stability, and getting the causal mask to add -inf before the softmax, not after.

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.

The O(log(min(m,n))) answer binary-searches a partition on the shorter array so the left halves of both arrays together hold exactly half the elements. The whole problem is one invariant plus careful boundary handling for empty sides and odd versus even totals.

A path can start and end anywhere and bends through at most one node, values can be negative, and you want the maximum sum. The move is a DFS that returns the best downward gain (clamped at zero) while a global max tracks the best path that bridges through each node.

The signature coding problem at a legal-AI company, and it is interval merging wearing a product costume. The candidates who struggle are the ones who start matching before deciding what a match even is.

It looks like the grid BFS everyone has written a hundred times, and the usual visited set is exactly what makes it wrong. The fix is one line and it is the whole point of the question.

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.

Almost never, and the gap between score and probability quietly breaks thresholds, expected-value decisions, and customer trust. What calibration is, how to measure it, and the two fixes that work.

Enterprise reality: legal, fairness or ops constraints kill the A/B test, but the exec still demands proof of impact. The quasi-experimental toolkit, and the honest caveats, that let you answer anyway.

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.

The signature production-ML incident, and a pure FDE test: a ranked differential diagnosis run live on a call, because 'nothing changed' is always false, and one hypothesis explains half of all cases.

The maturity exam of production ML: a model that's better on paper and worthless in production. Five distinct causes, the funnel diagnostic that separates them, and when the right call is don't ship.

The capstone panel question that ties the whole track together. The spine, data, training, deployment, monitoring, operating model, plus the maturity-staging judgment that separates architects from slide-readers.

The 2026 successor to 'explain precision and recall', interviewers now test whether your classical ML evaluation discipline survives contact with GenAI. The decomposition, the RAGAS dimensions, and the judge-calibration step everyone skips.

When a model auto-approves loans or routes patients, the probability is the product, not a dashboard number. The calibration-plus-abstention design that lets a customer trust an automated decision, and the subgroup trap that gets it pulled in audit.

The most expensive leakage bug in feature-store ML: training joins that grab feature values from after the label event. The timeline that exposes it, the one query that proves it, and the fix that survives audit.

A budget-constrained design problem, not an ideology question. The per-call math that rules an LLM in or out, the cascade that keeps quality while cutting cost 90%, and the SLO arithmetic that decides where the LLM is even allowed to sit.

When treatment leaks between units, a clean A/B lies in both directions. The interference taxonomy, when to reach for switchback vs cluster vs geo designs, and the analysis trap that makes naive standard errors useless.

Not leakage, not skew, not drift: the model learned exactly what you asked, and you asked for the wrong thing. The proxy-label mismatch that passes every test, the audit that catches it, and why this is the failure no metric can see.

Bandits sound strictly better and usually are not. The regret-vs-inference tradeoff, the three conditions that actually favor a bandit, and the production failure that makes adaptive allocation a debugging nightmare.

Both are tree ensembles, but one averages independent deep trees to kill variance and the other adds shallow trees in sequence to kill bias. That single difference dictates the failure modes, the tuning burden, and which one you hand a customer who will retrain it after you leave.

You can't human-review every summary, and an LLM that wrote the summary can't be trusted to grade it. The move is span-level entailment against the transcript, then a threshold tuned to your cost-of-miss, not 0.5.

A static threshold on prompt length leaves money on the table both ways. The router that learns is a contextual bandit, and the interview lives in the reward function and the cold-start handling, not the algorithm name.

Averaging two scalar scores tells you almost nothing. Blind pairwise battles plus a win-rate confidence interval do, and the result is only trustworthy once you've controlled position bias, verbosity bias, and rater fatigue.

The amateur move is to train a fresh deep net on 200 rows and overfit instantly. The senior move is to spend almost no labels on training: lean on a pretrained model, use the 200 as a validation set, and design a labeling loop that buys the most signal per label.

The thing interviewers actually screen for isn't the Bellman equation, it's whether you know when NOT to use RL. Most problems that look like RL are better solved by supervised learning or a bandit, and reaching for full RL when you have labels is a classic over-engineering tell.

Almost no labels means you cannot train a classifier and you cannot honestly report recall. The senior answer is to score by typicality, threshold by the customer's review budget, and build the labeling flywheel that turns this into a supervised problem within two quarters.

Random sampling is the baseline you have to beat, and honest candidates admit it sometimes wins. Active learning earns its keep by labeling where the model is least sure, but uncertainty alone gives you a batch of near-duplicates, so you also need diversity, and a cold-start plan.

Everyone spots that the customer records need resolving. The failure that actually sinks this project is quieter: the word fraud means three different things in the three datasets, so the union of their labels trains a model that is confidently wrong.

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.

Snowflake's signature internals question, and the trap is in the second half: most candidates can define micro-partitions, but the scoring is on knowing the four cases where scaling up burns credits for zero speedup.

The Databricks signature deep-dive. Everyone says 'salting', almost nobody can write the salt correctly or explain why AQE might make hand-salting unnecessary. The full playbook, in the order a senior engineer actually tries it.

Everyone can define SCD2; very few can write the MERGE that maintains it correctly. The expire-and-insert dance, the one-statement trick, and the late-arriving-change trap that breaks naive implementations.

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.

Palantir's home turf: entity resolution disguised as a dedupe task. The naive O(n²) comparison is the trap, blocking, match scoring, transitive closure, and the golden-record question are where the interview actually happens.

The integration question that decides data-platform FDE offers. Log-based vs query-based capture, why deletes break naive designs, the apply-merge that keeps order, and the snapshot step everyone forgets.

The capstone triage scenario data-platform FDEs get role-played through. A 9x blowup with an obvious-looking suspect, the scoring is on your diagnostic order, the questions you ask, and not stopping at the first plausible cause.

The Deployment Strategist data-modeling case. It looks like schema design; it's graded as ontology thinking, entities with identity, events that link them in time, documents as evidence, plus privacy designed in, not bolted on.

The verbatim Deployment Strategist case. The trap is accepting the premise, 'best for whom?' is the first scored move, and the second is designing a natural experiment from public data instead of hand-waving at 'analytics.'

C3.ai's reported 3-hour data science case, the round their candidates rate hardest. The winners aren't the best modelers; they're the ones who budget the clock, ship a baseline in hour one, and present like a consultant.

The regression with no smoking gun, no deploy to blame, no single bad night. Staff-level triage is about reading the trend, not the last run, and the four slow-burn causes that a one-night comparison can't see.

The aggregate-restatement problem that breaks naive backfills: events arrive days late and out of order, so any partition you already published may be wrong. The staff answer is event-time partitioning plus bounded restatement, not a bigger watermark.

SCD2 tracks when an attribute was true; bitemporal also tracks when you knew it. The question separates engineers who can audit a number from those who quietly overwrite history when a correction arrives.

Basic salting assumes one side is a small dimension you can explode. When both sides are huge and skewed, exploding either one blows up the cluster. The staff move is to split hot keys out and handle them on a different plan entirely.

CDC design questions usually stop at the happy-path MERGE. This one stress-tests it: an at-least-once stream that double-delivers, hard deletes, soft deletes for audit, and a GDPR erasure that must physically purge even the bronze change log. The guarantees have to compose.

Streaming interviews separate people who have run a job at 3am from people who have read the docs. The hard parts are not the windowed aggregate, they are bounding state so the job does not die, and choosing what a late event does to an already-emitted result.

The most common escalation in any data deployment, and the one that quietly ends trust in the platform. Four causes produce it, one of them means nobody is wrong, and you cannot tell them apart without running the ladder in order.

The constraint is the question. It rules out the two approaches most candidates reach for, and the approach that survives has one failure mode that can take the customer's production database down.

The classic Palantir decomposition prompt. The winning answer hinges on one asymmetry candidates rarely surface unprompted, and on starting with something embarrassingly simpler than an ML model.

The most open-ended prompt in the Palantir canon, no scale given, no user given, no disaster given. What separates passing answers is one design assumption about the data that almost nobody states out loud.

The purest data-modeling prompt Palantir asks, the whole interview lives in the entity-resolution edge cases. Twins, maiden names, shared insurance IDs... and one architectural decision about merging that candidates get fatally wrong.

Looks like an algorithms question; it's actually an operations question wearing one. The candidates who fail reach for 'solve VRP'; the ones who pass design for the 2pm reality that invalidates every morning plan.

The decomposition prompt we use to teach the skill that actually decides these interviews: graceful iteration under perturbation. Your score isn't your design; it's the delta when the design gets punched.

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 model is an untrusted code author with an unlimited imagination, and prompt injection means it can be *aimed*. Strong answers pick an isolation primitive deliberately, then close the channel most designs leave wide open: the data the code is allowed to touch.

The question that defines forward-deployed engineering as a discipline: production you're responsible for but can't touch. The answer is a system (version skew, telemetry tiers, diagnostic bundles, release trains), not a collection of favors from customer IT.

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.

A live-reported Palantir FDSE decomp with a built-in twist: after you design for the driver, the interviewer flips you to Uber's side. The expected-value-per-hour model, the tip-prediction ethics trap, and how to survive the flip.

A reported Palantir FDSE decomposition where the fatal move is putting triage inside an algorithm. The bed-capability data model, the visibility-before-optimization v1, and the conflicting-priorities answer that keeps clinicians in charge.

The reported Anthropic open-ended design, and the round where candidates get tested on GPU memory and KV-cache arithmetic mid-whiteboard. The serving spine, the memory math that explains every product limit, and the safety layer the rubric explicitly wants.

Active-active is easy until two regions write the same agent's memory at once. The strong answer picks a write model on purpose, names what conflicts and what cannot, and refuses to pretend a long-running agent run survives a regional failover for free.

No egress is the easy half. The hard half is that an auditor will read your logs, your access trail, and your model-update process for the next three years. The strong answer designs the evidence the audit consumes as a first-class output.

Latency, cost, and quality are one budget with three claims on it. The strong answer treats the p99 SLA and the spend ceiling as a joint constraint, finds where they fight (batching), and names the lever it pulls when traffic exceeds what the ceiling can buy at SLA.

A crashed agent is easy. The hard one returns a confident answer after a tool quietly returned nothing and the model made up the rest. The strong answer instruments the steps that fail without throwing, ties traces to an outcome signal, and refuses to call a 200 a success.

A port is three coupled scheduling problems in a single prompt: where ships dock, which cranes work them, and where containers land in the yard. The strong answer decomposes them, names where they couple, and refuses to solve the whole thing as one giant optimizer.

Per-account scoring catches the lone fraudster and misses the ring whose accounts each look clean. The strong answer reframes the problem as a graph, makes entity resolution the step everything else depends on, and treats a flagged ring as a case for an investigator, not an automatic block.

CAP is a trap if you recite it. The interviewer wants to see you map a customer's real datastore to a real failure mode, then decide where stale reads are free and where they corrupt an agent's decision.

Caching LLM output looks like free latency and cost savings until a cache key collides across tenants or a popular key expires under load and stampedes your model. The senior answer is mostly about what you refuse to cache.

It reproduces once in a thousand runs, never on your laptop, and the customer's data is wrong. This question separates engineers who name the race and reach for the right lock from those who sprinkle mutexes and pray.

A Copilot/Cursor-style assistant lives or dies on the latency budget. The strong answer spends every millisecond of a 200ms end-to-end budget on purpose, separates the inline-ghost-text path from the chat path, and shows why prefix caching and speculative decoding are the only ways to hit it at 10k concurrent users.

A gateway that screens every prompt and streamed token against a live policy without blowing the latency budget. The strong answer separates the policy decision from its data, runs deterministic checks inline and model checks in parallel, and redacts a leaking secret mid-stream before it renders.

Fifty milliseconds at p99 to catch toxicity, PII, and injection on every message. An LLM in the hot path blows the budget. The strong answer tiers the checks and keeps the LLM off the critical path.

Under 500ms from end of speech to first audio out, across three models and a network. The trick is that you never wait for any stage to finish: you stream and pipeline everything.

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 2-second inference and a user who closed the tab. Naive stacks keep the GPU burning to completion. Real cancellation means propagating disconnect all the way to the batch scheduler.

One GPU, callers blocking on the response, and a hardware unit that is only efficient when fed wide batches. The whole job is trading a few milliseconds of queue wait for a large jump in throughput without ever stalling a request.

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.

The source can only upload the file a handful of times before it saturates, but every receiver also has upload bandwidth. The win is making peers serve each other, so total capacity grows with the swarm instead of bottlenecking on one machine.

Every request emits a usage event worth real money, clients retry on timeouts, and tenants must be stopped at their quota and never overcharged. The hard parts are idempotent usage events and the succeeded-but-confirmation-lost case where the work happened but the client never heard back.

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.

A back-of-the-envelope round where the envelope has a purchase order attached. The arithmetic is the easy half. The scoring is in which assumptions you write down, which way you round, and what you say about the number being wrong.

Every integration lesson assumes a queue and nobody designs one. Ordering per entity rather than globally, a dead letter path somebody actually reads, and what your pipeline does when the consumer is slower than the producer for four hours.

Aggregate metrics hide exactly the customer who is about to churn. Adding a tenant label to everything is the obvious fix and it is also how you get a cardinality explosion that takes down the monitoring before it takes down the platform.

The abstain path is designed last and decides whether the deployment is adopted. Routing to the right person, an SLA the queue can actually meet, and what happens to the case the agent already half-processed before it gave up.

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 number 500 is the trap. Candidates hear it as a scaling problem and design a pipeline factory, when the interviewer is watching to see whether you refuse to ingest 500 things at all.

A dataset lands in your lap with a one-week deadline attached. Most candidates start exploring the data. The ones who pass start by working out which questions this data physically cannot answer.

It reads as an optimization problem and it is not, quite. One of the three inputs can never be traded against the others, and a design that scores all three has quietly built a compliance incident with a scheduler attached.

The only round where you choose the problem, which sounds like a gift and is where most candidates lose it. Four things get graded in one flow, and the fourth is the one engineers skip.

Three different causes produce the same rising line, and resident memory alone cannot tell them apart: a leak climbed 25.2 MB an hour and fragmentation climbed 22.8. The gauge that separates them costs nothing and has to have been shipped before the incident.

Every instinct says move fast. The arithmetic says otherwise: eight hours of preparation reached a fixed system 26% sooner than shipping immediately, because each failed attempt costs a two-day approval cycle and you only get one shot per cycle.

The instinct is to grade the codebase. Grade the feedback loop instead: a repo with no docs and a 90-second test command is friendlier to an agent than a beautifully documented one whose suite takes 40 minutes and flakes 8% of the time, and the arithmetic on that second number is worse than it looks.

Nobody turns off an AI reviewer because it missed a bug. They turn it off because it left nine comments they had to read and three that mattered. Precision is the design variable, and the arithmetic says cutting comments per PR from twelve to four costs you 7% of the real findings and two thirds of the triage time.

Both payloads parse to the same object. Only one authenticates. Trace the bytes, endpoint secret and timestamp before replaying the customer's missed events.

Deduplicating by call ID drops the analysis event. Replacing the whole record can erase it. Design the receiver around separate facts and explicit business effects.

A successful provisioning run and a green dashboard leave several paths untested. Locate the broken boundary using agent health, upgrade headers and the route the user actually takes.

Uptime and latency are the easy SLIs. The hard ones are whether the case was actually resolved, which you only learn days later, and what to do with an action that must never happen, which no error budget should cover.

'Too expensive' after a winning pilot is a solvable engineering problem wearing a procurement costume. Here's the diagnose-then-optimize playbook, including the 10x cost levers, that turns it around.

Every enterprise AI deployment hits this wall, interviewers want to know if you deliver the bad news early, with options, or sit on it hoping. Here's the conversation script, beat by beat.

The Databricks/Snowflake signature round: the interruptions ARE the interview. Here's how to structure for derailment, the objection-handling loop that scores, and why finishing your deck doesn't matter.

The Palantir classic. He's not irrational, your product might really make his role redundant, and escalating over him is the losing move. Here's the playbook that converts the blocker.

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 nightmare scenario every agent deployment signs up for. Interviewers grade the first hour hardest, containment before diagnosis, honoring the invented policy, and who you call in what order.

An integrity trap with a political twist: the person gaming your metric is usually your own champion. Blowing the whistle loudly and looking away both fail, here's the third path.

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.

The verbatim opener from Anthropic's customer-simulation round, reported as the highest-signal stage of the loop. The word 'convince' is the trap: candidates who pitch lose, and the winning move is almost no pitching at all.

Work trials and utilization-driven staffing are the 2026 startup FDE reality, and 'no questions, sounds great' is a failing answer. The reverse-interview questions that signal seniority, and the trial terms worth negotiating.

FDE comp spans roughly $150K to $550K+ for the same title, because some companies pay it on the engineering ladder and some on a field ladder with variable comp. The first question to ask, and the traps in comparing OTE to base.

The eng lead isn't testing your architecture, he's already decided you should go and is performing it for the room. Trying to win the technical argument is the trap. Here's how to split his audience from his position and leave with a next meeting.

You hit 71% against an 85% bar nobody wants to say out loud, and the easy moves (quietly redefine the metric, ask for 'one more month') are how pilots rot in purgatory. Here's the honest salvage path, and how to recommend a kill without losing the account.

Both dials broke at once and now the most senior person in the building wants answers. The instinct to lead with explanation is how you lose the room in the first minute. Here's the structure that turns an execution interrogation into a decision meeting you control.

The conflict isn't you versus the customer, it's you versus your own quota-carrying colleague who wants the deal. The answer that passes refuses the line without grandstanding, finds the compliant adjacent path, and accepts the churn if there isn't one. Here's how to hold it without becoming the obstacle.

A board isn't an engineering audience and the postmortem they want isn't the one you'd write for your team. Lead with the wrong thing and you confirm their fear that this is unmanageable. Here's the board-grade structure, blameless but accountable, that restores confidence.

The capability isn't real, the ink is dry, and the customer found out from you, not your AE. Throwing sales under the bus and quietly building vaporware both fail. Here's how to reset the expectation without breaking the account or the internal relationship.

Around 95% of enterprise AI pilots produce no measurable impact, almost always from deployment, not the model. As the first FDE in a skeptical SWE shop, your month-one job is to not be pilot 95: pick a project that can win, prove it in 30 days, and turn the engineers who roll their eyes into the ones who vouch for you.

The gap is real, the date is close, and the business is about to ask if you'll make it. The wrong first move is to start tuning prompts. The strong move is to split the failure into causes you can act on, give the business an honest forecast with options, and protect the launch even if you can't fully close the gap.

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.

A model that's too good is a bug, not a win. The screen is whether your instinct on a suspiciously high number is to celebrate or to get suspicious, and whether you disclosed the leak instead of quietly fixing it.

At 100k QPS you cannot 10x the model for a +2% quality bump. This question screens whether you can find the actual operating point under a real constraint and get product, finance, and the customer to agree to it instead of pretending the tradeoff away.

The humble-brag ('I work too hard') fails on sight, and a fatal flaw sinks you. The narrow win is a real gap that's yours, a real cost it imposes, and the concrete way you contain it. Here's how to find that lane.

The trap is sounding like an absolutist who would torch every deal on principle. The win is a real story where you held a line with judgment: you found what was actually at stake, drew it narrowly, and paid a cost you can name. Here's the difference.

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.

Nothing about the software changed. The single person whose belief the contract rested on is gone, and the replacement has more to gain from cancelling your project than from finishing it.

The structural tension of the job in one question. You are the customer's advocate inside your company and your company's representative at the customer, and this is the day those two roles openly disagree.

Palantir hiring managers are reported to spend a large part of the final round on this one question. It is not a stress test, and treating it like one is how strong candidates talk themselves out of an offer.

The trap is that it looks like a prioritization problem you can solve with a scoring rubric. You do not have the authority to rank these people's work, and the moment you try, you have made yourself the obstacle.

A working demo leaves authorship and understanding unresolved. Defend the decisions, reproduce a failure and adapt the code under a changed requirement without overstating what you tested.

Three individually reasonable requests create an impossible week. Build a capacity ledger, protect existing obligations and obtain a decision from the people who can change cross-account commitments.

A passing evaluation and an enthusiastic sponsor can coexist with a blocked release. Separate the decisions, preserve useful progress and write a recommendation with a specific approval dependency.

A high-value request arrives before its permissions and operator. Decide which work can start, who can authorize an exception and what a responsible practice launch commits to.

A fluent demonstration earned a strong hire from one assessor, while another recorded a critical gap. Reconcile the observation, assistance and role requirement without averaging away the disagreement.

The total-hours plan fits while a shared specialist cannot meet the change windows. Reconcile support obligations, skill coverage and coaching cost before adding another customer.

Services income, expansion contribution and retained business overlap in the board packet. Rebuild the economic boundary and identify which assumption changes the funding decision.

A bank-round system design where the budget math does the screening: ~10ms for features inside a 100ms decision. Streaming aggregates, the hot-key problem during an active attack, and the parity discipline that makes training data honest.

The senior-MLOps question that exposes dashboard-driven candidates: your accuracy chart is blind for 60 days, or forever. The layered substitute, proxy metrics, score-distribution sentinels, delayed-label backfill, and paid-for labels, and which layer to trust when they disagree.

The cluster shows eight free GPUs and your four-GPU pod still won't schedule, the fragmentation puzzle GPU-platform rounds open with. Bin-packing vs. spreading, MIG/MPS/time-slicing for the small-model problem, and the pod-per-model math that breaks at scale.

An incident question graded on method, not tools: interviewers want ordered hypotheses, each with a five-minute test. The version-skew check most candidates never think of, the cache trap, and the triage tree that finds the usual culprit fast.

A real customer-interview question that rewards scar tissue: the 29-second timeout wall, retry storms that triple your own load, and connection pools sized for web traffic meeting 30-second inferences. The issues worth claiming and the fixes that prove you were there.

The 45-minute MLOps capstone reported from Capital One and Uber loops. The component walkthrough is table stakes, what's graded is sequencing, the batch-vs-realtime call made early, and knowing which pieces you'd cut for v1.

The 'why' is the question: AWS gives you five ways to host a model, and interviewers want the decision tree plus the trade-off you knowingly accepted. The walkthrough structure, the real cost math between SageMaker endpoints and EKS, and the answer shape that survives drilling.

The lead-level capstone: not 'which metrics' but 'what's your operating program.' SLOs per model, a drift policy with teeth, retraining as routine rather than rescue, and the inventory discipline that separates teams who run models from teams who babysit them.

A staff-level platform design where the constraint set, not the architecture, is the test. The controls SR 11-7 actually demands, how to make audit a byproduct of the pipeline instead of a quarterly fire drill, and the v1 you can ship without a compliance finding.

The GPU-platform capstone: dozens of models, spiky traffic, a fixed monthly GPU budget, and a p99 SLO that scale-to-zero would wreck. Token-based autoscaling, the three layers of LLM cold start, and the residency tiering that makes the budget math work.

The incident with no onset spike and no pager: precision bled out over weeks while every dashboard stayed green. How to run a blameless postmortem when the incident has no clean start time, the root-cause classes that hide this long, and the action items that actually prevent the next one.

An ambiguous, time-pressured staff scenario: the signal is soft, labels won't confirm anything for weeks, and rollback itself has risks. The decision framework under uncertainty, when to revert on a proxy, and the remediation for decisions the bad model already made.

A staff platform-design question about leverage, not metrics. The split between what the platform owns and what teams bring, the logging contract that makes everything else possible, and why the hardest problem is alert fatigue, not data collection.

The staff on-call simulation: three alarms at once, partial information, and pressure to do something. How to separate symptom from cause, the common-cause hypothesis that explains all three, and why mitigating before diagnosing is the senior move, not a shortcut.

Logs, traces, and model-quality signals from hundreds of LLM products at firehose volume. The storage split that keeps queries fast, the alerting that survives drift and toxicity at scale, and why sampling has to be cost-aware and tail-biased.

Two hard numbers in the contract: 95% accuracy and $0.50 per resolution. The job is an eval and rollout system that proves both hold on real traffic before you scale, with rollback triggers wired to the same numbers.

A reported DeepMind research-engineer question. The winning answer opens with a memory budget in bytes, not a list of parallelism buzzwords, here's the full arithmetic and the layout it forces.

A real infra-loop question that candidates fumble by guessing. The correct map, TP on NVLink, PP and DP across the scale-out fabric, falls out of three traffic profiles, and the reasoning is the answer.

The MoE question frontier labs use to test whether you see routing as a systems problem, not just a modeling trick. Covers the collapse spiral, auxiliary losses, capacity factors, and what changes at serving time.

A reported DeepMind debugging-round prompt. What's scored is your search order, not your bug list, the overfit-one-batch ladder that finds 90% of flat-loss causes in under an hour.

At 16k GPUs something fails every few hours, Meta logged 466 interruptions in 54 days training Llama 3. The checkpoint-interval math, straggler detection, and automation that turn failures into a budget line instead of an emergency.

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.

A reported OpenAI design prompt. The skeleton: gang scheduling, topology-aware placement, preemption with checkpoint contracts, and quota, plus the fragmentation problem that quietly eats 20% of naive clusters.

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.

The OpenAI capstone design. What separates passing answers: token-based capacity math, KV/prefix-aware routing instead of round-robin, and a degradation ladder for the day demand doubles overnight.

The worst failure mode in distributed training: no crash, no log, every GPU pinned at 100%, and the job dead. The triage order that finds a collective mismatch or a dead rank before you burn a day of cluster time.

A sparse model with few active params per token, a brutal latency target, and an all-to-all on the critical path. The parallelism layout that hits the SLA, why expert parallelism not tensor parallelism is the lever, and the tail the all-to-all hides.

The CFO-facing infra question: a demand forecast with a fat tail, GPUs that take months to land, and three cost structures that win in different regimes. The layered commitment model that keeps you from paying for peak all year.

One synchronous job, 16k GPUs, and any single component can stall all of them. The blast-radius analysis interviewers want: which faults take down a rack vs the run, where the shared single points of failure hide, and how parallelism layout maps onto failure domains.

The fleet was fine on 8k contexts and falls over when a few 200k-token requests arrive. The math that explains why, the admission and pooling fixes that contain it, and why throwing GPUs at it is the wrong first move.

No error, no hang, the loss still moves, but the run is suddenly half as fast and burning the same dollars. The triage that separates a straggler from a fabric problem from broken comm/compute overlap, using the signals nvidia-smi can't give you.

A very large sparse model, hundreds of experts, and users on every continent. The layout that keeps experts close to compute, routes around regional skew, and decides what 'global KV cache' can and cannot mean.

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.

The grown-up version of 'how would you red-team a chatbot', Microsoft-style loops ask for a program, not a pen test. Team composition, harm taxonomy, iteration cadence, and which attack classes you script on day one.

An Anthropic-style system design axis: architectural safety. The answer is a pipeline diagram in words, five checkpoints, what each catches, what each costs in latency, and the streaming complication most candidates forget.

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 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 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.

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.

The LLM billing round has three trapdoors: retries double-charging customers, metering latency leaking into inference, and month-end numbers that don't match the provider invoice. The design that survives all three is the answer.

When the agent does something expensive, 'what happened and why' must be answerable in minutes, to an auditor, from records they trust. Most logging designs answer 'what'; the AI-specific work is 'why', and tamper-evidence is what makes it count.

The capstone governance round: AI incidents break standard IR playbooks in three specific places, containment without rollback, blast-radius over probabilistic systems, and root cause for nondeterministic behavior. Interviewers grade you on knowing which three.

The agent has real money authority and a write path into the system of record, which is the exact shape attackers want. The strong answer is layered enforcement outside the model, with the spend cap and the chain rule in code, not in the prompt.

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.

One backdoored MCP server can BCC every email an agent drafts, and a clean server can rug-pull its tool definitions a week after approval. This is a software supply-chain program for dependencies that talk, not a one-time review.

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.

NIST AI RMF is voluntary, which is exactly why a CISO uses it as a shared yardstick. The strong answer turns Govern, Map, Measure, Manage into artifacts you already produce, and uses the Generative AI Profile to name the LLM-specific risks the core framework leaves abstract.

When agents call agents, one agent's output is another's untrusted input, and a single injected instruction can propagate across the whole graph with accumulated privileges. The strong answer treats every inter-agent edge as a trust boundary and bounds privilege per agent, not per system.

Sensitive meeting audio in, speaker-attributed summary out, and a hard guarantee that the raw transcript never lands on disk. The strong answer keeps everything on-prem, processes transcripts in memory only, and proves non-retention with architecture and audit, not a policy promise.

Turn a constitution of rules into a model that follows them, with no human labels on harmful examples. The strong answer walks the two phases (self-critique SFT, then RL from AI feedback), then spends real time on the part papers gloss: adversarially validating the aligned model holds under attack.

A code model that occasionally produces ransomware, reverse shells, or exfiltration scripts. The strong answer builds an automated loop: adversarial prompt generation, static and behavioral output scanning, layered mitigations, and attack-success-rate per category to prove the mitigations worked.

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.

Candidates treat computer-use agents like API agents with a screenshot. The interviewer is probing the new visual attack surface (hidden text, off-viewport UI, injected images) and how containment changes when the agent drives a real customer desktop. Most miss the per-turn-approval trap.

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.

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.

Watch time is the label everyone optimizes and almost nobody measures cleanly. You only observe minutes for videos people chose to play, the distribution is brutally skewed, and the position they saw it in moved the number. The interview is whether you can predict a biased label honestly.

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.

This model's output is not a ranking, it is a price input. A miscalibrated CTR makes the auction bid wrong, so you overpay or underdeliver. Add conversions that land days after the click and advertisers with zero history, and calibration plus delayed feedback become the whole interview.

An ETA is a promise. The interview is whether you model it as a point estimate (and apologize when wrong) or as a distribution where p90 lets you under-promise, plus how you fold live traffic and finished trips back into the model.

There are millions of landmarks, most with a handful of photos, and the next photo might be of something not in your catalog at all. A flat classifier dies on the long tail and never says 'I don't know.' The interview is embeddings plus retrieval plus a confident refusal.

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.

New courses launch every week and most browsers are signed-out or brand new, so the interesting half of this problem is what you recommend when you have almost no behavioral signal. The other half is not optimizing engagement into a clickbait catalog.

The whole product lives or dies on a feedback loop measured in seconds: a swipe is a label, and the next video has to reflect it. The hard part is exploring enough to discover what someone likes without trapping them in a filter bubble or amplifying junk.

A search box is a recommender with a strong prior: the query. The hard parts are understanding ambiguous intent, retrieving in two stages under a tight latency budget, and learning from clicks without teaching the model that whatever you showed first is best.