Medium FDE interview questions

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

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

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.

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

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

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.

The data-volume thresholds, the break-even math, and the regression-prevention checklist that turn 'just fine-tune it' into a defensible engineering decision. Includes the crossover rule interviewers listen for.

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

Malformed arguments, wrong tool, hallucinated parameters, retry loops: the full failure taxonomy plus the production defenses (validation, idempotency, capped retries) that separate builders from readers.

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.

Arguing against agents is the move that reads senior in AI-lab interviews. The error-compounding math, the decision rule, and the workflow-vs-agent spectrum that wins this contrarian question.

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 KV-cache mechanics behind the discount, the prefix rule that silently breaks caching for most teams, and the workloads where caching cuts bills 50-90% versus the ones where it does nothing.

Prompts are production code that nobody treats like code, until an innocent one-line tweak tanks accuracy. The version-eval-canary-rollback pipeline that AI-native interviewers expect by default.

Model migrations break things that benchmarks never show, format quirks, refusal shifts, tool-calling drift. The eval-replay and shadow-traffic playbook for migrating without surprises.

Zero retention, private endpoints, redaction pipelines, or open weights in their VPC, the four-rung ladder for PII-sensitive deployments, and the discovery questions that pick the right rung.

The experience probe that opens half of all applied-AI loops, and the place resumes go to die. The four-beat walkthrough structure interviewers can actually score, plus the two omissions that quietly downgrade you from architect to API caller.

Past tense matters: the interviewer is asking what you actually enforced at runtime, not what you'd design on a whiteboard. The enforcement chain (gate, starve, screen, measure) with the scope-violation metric that proves it worked.

Rotary embeddings encode position as a rotation of the query and key vectors, so attention scores depend only on the gap between two tokens. That relative property is why RoPE generalizes past its training length where learned absolute tables fall off a cliff.

Each chat turn resends the whole conversation, so the model re-prefills the same prefix every time. Server-side KV caching and client-side cache breakpoints kill that redundant compute, but exact-prefix matching and stale entries are where teams silently get it wrong.

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.

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

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

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

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

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.

Perceived latency is a design surface, not an infrastructure detail. Covers progressive disclosure, SSE vs WebSockets, resumability, and the mid-stream failure question most candidates have never thought about.

Calibrated abstention is a system property, not a prompt line. Learn the four abstention signals, the precision-at-coverage framing, and why 'just tell it to say I don't know' fails the interview.

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

Text-to-SQL's nightmare isn't syntax errors, it's the query that runs, returns a confident number, and is silently wrong. The defense is a semantic layer plus transparency UX. Here's the full design.

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

The unglamorous design question that exposes who has run LLMs in production. Batch APIs at 50% off, idempotency keys, poison records, spend kill-switches: the full checklist interviewers listen for.

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

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

The verbatim ElevenLabs case-study prompt. It looks like a UI question; it's a workflow-modeling question, and the candidates who pass start by asking what a 'unit of work' is in dubbing. The entity model, the review-state machine, and the v1 cut.

Reciting the four definitions is table stakes; the differentiator is knowing which two need ground truth, what each dimension tells you to fix, and where the judge-model scores quietly lie. The 2x2 that turns RAGAS into a debugging tool.

Asked constantly in GenAI loops, and most answers are marketing-page recitals. The version that scores: classify by what each actually is, data framework, integration toolkit, graph runtime, then give the selection criteria that outlive all three names.

Trace an old fact from durable storage into the next model call. Separate conversation history, checkpoints, summaries, and verified tool outcomes.

Everyone knows the sort + two-pointer outline. The interview is actually about duplicate handling: three separate skip conditions that candidates routinely botch live. Here's the clean version and the narration that goes with it.

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.

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

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.

The follow-up to number-of-islands, and the question where candidates reveal whether they understand WHY BFS finds shortest paths. Plus the two variants (weights, eliminating obstacles) that decide hard-screen outcomes at xAI.

The third member of the grid trilogy, and the one that tests backtracking discipline: marking, unmarking, and the early-exit pruning that turns a timeout into a pass.

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

The Palantir coding-screen classic. It looks like merge-intervals but needs a different weapon, the sweep line, and the boundary-tie detail decides whether your answer is right or off by a planeload.

The quintessential FDE practical: messy real-world input, grouping, ranking, and a hidden rubric line for how you treat malformed data. Most candidates parse happily and lose the round on the lines that don't parse.

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

Every data migration at every customer site needs this exact tool, which is why Palantir and Retool keep asking it. The diff is a dict comparison; the grade hides in keys, duplicates, and column drift.

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

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

The format that filters out LeetCode-only candidates: unfamiliar code, failing tests, 45 minutes. There's a repeatable protocol for it, and a reason the first five minutes decide the round.

The coding question that doubles as a RAG-fundamentals check. Greedy packing is easy; the oversized-sentence case, the overlap-progress trap, and the tests you write unprompted are what AI-lab interviewers actually score.

cd('/foo/bar', 'baz') is easy. cd('/foo/../', './baz') is where the OpenAI screen actually starts, and the symlink follow-up is where it ends. The stack solution plus the loop-guard most candidates forget.

No JSON libraries allowed, and the test data contains commas, newlines, and your escape character itself. Length-prefix encoding solves it in fifteen lines, and knowing why it beats escaping is the actual interview.

Palantir's signature coding genre isn't an algorithm; it's working from unfamiliar documentation: a graph API, a custom serialization spec, a mini query language. The behaviors graders score, plus the BFS-over-an-opaque-client worked example.

The reported ElevenLabs live round, written in a shared Google Doc, no execution, no autocomplete. Inherited folder permissions plus permission-change timestamps, and the two-axis resolution rule that keeps the code to thirty lines.

C3.ai runs the most LeetCode-classic FDE loop, and candidates report the same published set for years: Trapping Rain Water on the phone screen, Daily Temperatures in the tech screen. Both optimal solutions, plus the one-line insight that unlocks each.

The function reads a file, parses it, computes a metric, and prints, all tangled together. The move interviewers want is not prettier code, it's pulling pure logic out from side effects so each piece can be tested in isolation.

A classic FDE take-home shape: messy real documents in, structured index out. The grade is in the seams between reader, extractor, and writer, and in what happens when one file is garbage.

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.

Every chat model decodes with top-p, but few candidates can build it from logits: softmax, sort, take the smallest set of tokens whose cumulative probability crosses p, renormalize, sample. The screen for whether you understand decoding, not just call an API.

The loss every language model trains on, built from logits with no torch in sight. The screen for whether you understand log-softmax and the numerical-stability trick, not just import nn.CrossEntropyLoss.

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.

There is no training, just storage; the work is at query time. The signal is whether you vectorize the distance computation, break ties sensibly, and know when O(n) per query forces you onto an ANN index instead.

The whole question is the representation: store only the nonzeros as index→value, then either two-pointer over sorted indices or hash-join. The follow-up that decides the design is what happens when one vector is dense.

An ML coding screen that doubles as a calculus check. Interviewers watch whether you can write the MSE gradient without looking it up, explain what the learning rate actually does, and say out loud when you'd just solve the normal equation instead.

Almost everyone reaches the O(n²) DP. The signal interviewers want is the O(n log n) patience-sorting trick, plus the honesty to say the array you build along the way is not itself the answer subsequence.

The question that punishes greedy. Interviewers pick denominations where taking the biggest coin first gives the wrong answer, and they watch whether you reach for DP and handle the impossible-amount case cleanly.

The classic linear DP. At each house you either skip it and keep the best so far, or take it and add the best from two back. The signal is collapsing the table to two rolling variables and then handling the circular follow-up cleanly.

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.

Build the output from prefix products on a left-to-right pass, then fold in suffix products on a right-to-left pass using the output array itself as scratch. O(n) time, O(1) extra space. The interesting part is why division is banned and what it costs when the input has zeros.

A sorted array got rotated at an unknown pivot and you still have to find a target in O(log n). The trick is deciding which half is sorted at every step. Here's the clean invariant, and the duplicates follow-up that quietly breaks the log-n promise.

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 longest path between any two nodes need not pass through the root, which is what trips people up. The clean answer is one DFS that returns each node's height while updating a global best as it goes. First, nail down whether diameter counts edges or nodes.

The clean answer hinges on one insight: preorder names the root, inorder splits left from right. The trap is the O(n squared) version that slices arrays and scans for the root; the O(n) version uses a hashmap of inorder indices and passes bounds instead.

The tell is whether you avoid the trap of sorting all n points when you only need k. Two real answers: a max-heap of size k at O(n log k), or quickselect at O(n) average. Knowing which one the interviewer wants is the actual question.

A full sort throws away the structure you were handed. Because no element moves more than k slots, a min-heap of size k+1 always has the next smallest element on top, sorting in O(n log k) and one pass.

A two-part screen that looks like a warm-up and isn't. Part one is the classic stack validator with three bracket types; part two flips to generating every valid string of n pairs, and the Catalan count is the detail that catches people off guard.

You have a coin that lands heads with some unknown probability p. Build a fair 50/50 flip from it without knowing p. The von Neumann trick is two lines; the part that scores is explaining why the bias cancels and how many flips it costs.

This is the shape of the TypeScript debugging round at the agent companies: a forty-line stream handler that mostly works. Each bug has a one-line demonstration, and none of them is in the model. One is a stale closure, one is a decoder splitting a multibyte character, and one is a render per token.

A grid where some cells start infected, and each step every infected cell infects its orthogonal neighbors. How many steps until everything is infected, or -1 if some cell is unreachable? This is rotting oranges in disguise, and the multi-source BFS framing is what they want to hear.

A stateful pass over sorted events, which most candidates get working in ten minutes. The reason it is asked is the next ten: in this domain a false positive is a person accused of something.

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.

The accuracy trap is the easy part. Interviewers keep pushing: resample or reweight? Does SMOTE survive contact with production? What happens to your probabilities? Here's the full chain.

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.

This is a discovery question wearing an ML costume. The strongest candidates run a four-step translation from business pain to loss function, and put a number on each error before choosing anything.

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.

On enterprise data, the feature pipeline routinely buys 2-5x the lift of a model swap. Here's the worked churn example, and the leakage rule every engineered feature must pass, that makes the argument stick.

Explainability is where ML deals in banking, insurance and healthcare live or die. What SHAP actually computes, the per-decision worked example reviewers expect, and the trap of reading it as causality.

Time-series is where standard ML habits, random splits, fancy models first, single-number forecasts, fail loudest in front of customers. The baseline discipline and backtesting setup that keep you credible.

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

Daily peeking can quietly triple your false-positive rate, and almost every customer does it. The math of why, the multiple-comparisons cousin, and how to deliver the bad news without losing the room.

Accuracy metrics don't survive contact with a CFO. The holdout pattern that turns a model into a permanent revenue receipt, and what to do when nobody set one up six months ago.

Models don't crash, they decay quietly while dashboards stay green. The four-layer monitoring stack, data vs concept drift with PSI numbers, and the label-lag problem that makes naive accuracy monitoring useless.

Half the value of this question is the second clause. Feature stores solve three specific problems, and FDEs earn trust by naming the team sizes and model counts below which they're expensive overkill.

"It depends" is correct and unhelpful. The decay-curve method that replaces guesswork with measurement, trigger-based vs scheduled retraining, and the safety rails without which auto-retraining is an outage generator.

Offline wins don't justify big-bang swaps, models fail in ways staging never shows. The shadow → canary → ramp playbook, what to compare at each stage, and the rollback discipline that keeps customer trust.

The classic market-sizing question with Palantir's twist: the estimate is the warm-up, and the scored move is the verification plan. Two independent decompositions, a cross-check, and the datasets that settle it.

C3.ai's reported classical-ML screen pair. Textbook recitation passes; what scores is one practical consequence per assumption, and knowing the random-forest failure mode that bites industrial deployments: no extrapolation.

Most candidates recite the Adam update equation and stop. The interviewer wants the decision: when plain SGD with momentum still wins, why Adam is the safe default for new architectures, and how you diagnose a training run that is silently dying from a gradient that shrank to zero.

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.

The answer is not just 'transformers are better.' It is two specific wins: every position can attend to every other in one step (long-range dependencies) and the whole sequence trains in parallel instead of one token at a time. Plus the cost that buys, and where RNNs still make sense.

Convolution and parameter sharing are why a CNN needs a tiny fraction of the weights a dense net would, and why it generalizes across position. The conceptual answer, the feature-hierarchy picture, and the honest take on when a fine-tuned CNN still beats reaching for a giant vision-language model.

The margin idea is elegant and worth understanding, and the kernel trick is a clever move. But the question that separates levels is why a model that dominated the 2000s is now a niche pick. The scaling math that killed it for big data, and where it still wins.

The base-rate trap is the classic, and it is not academic: it is exactly how a high-accuracy fraud or disease classifier drowns ops in false alarms. The worked numbers, the tree you draw on the whiteboard, and the two levers that actually fix it in production.

MAP is MLE plus a prior, and that prior is not academic decoration: it is the same thing as regularization, and it is what stops a model from making confident nonsense out of three data points. The connection that makes this an applied answer, not a stats-class recitation.

Picking the wrong distribution silently breaks your model: counts are not Gaussian, and treating them that way predicts negative events and underestimates the variance of busy periods. The decision tree by data type, the variance gotcha, and what each choice implies for the model you reach for.

Profile before you model: shape, types, target balance, leakage check. Then the part most candidates botch, that a missing value is often the most predictive feature in the table, so you flag it before you fill it. The first-hour playbook and the imputation decisions that survive production.

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

L2 shrinks every weight smoothly toward zero; L1 drives many weights to exactly zero, which is automatic feature selection. The geometric reason L1 hits the corners is the part interviewers actually want, plus the call on when sparsity beats smooth shrinkage.

Gradient descent is walking downhill on the loss surface, one step proportional to the slope. Knowing when to stop is the part that separates people who have trained models from people who have read about them: it is the validation curve, not the training curve, that tells you.

There's no single number. The trap is reaching for perplexity or BLEU because they're easy to compute, then optimizing a score that has nothing to do with whether the output is good. The move is to match the metric to the task and name where each one lies to you.

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.

Grid search is the answer that signals you have never paid for compute. The efficient answer is random or Bayesian over a small set of parameters that actually move the metric, with Hyperband killing bad runs early, on a validation set you never let leak.

More features is not more signal, it is more variance, more leakage surface, and a thinner data manifold. The disciplined answer ranks filter, embedded, and wrapper methods by cost, leans on L1, and screens every survivor for leakage and stability.

Thirty percent disagreement is not a fact about the annotators. It is a fact about the task definition, and on a skewed label set it can mean the labels are worse than chance. The week is spent on the guideline and the gold set, not on the model, because no model trains past the noise in its labels.

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.

Sessionization is gaps-and-islands with a twist, and it shows up in both SQL screens and Spark rounds at Databricks. The LAG-plus-running-SUM pattern here solves a whole family of interview questions.

The product-analytics staple that quietly tests event ordering, conditional aggregation, and cohort logic at once. Most candidates compute a funnel that double-counts, here's the version that survives interviewer scrutiny.

The triangle-shaped retention table every PM asks for, and a two-join SQL pattern interviewers love because it exposes grain mistakes instantly. Includes the right-censoring caveat that separates analysts from engineers.

Snowflake's signature semi-structured question. Dot-notation, LATERAL FLATTEN for nested arrays, the casting traps, and the schema-on-read vs flattened-model judgment call interviewers really want to hear.

The question that simulates the actual FDE job: a customer's Snowflake bill just doubled. Scale-up vs scale-out is the easy half, the scoring is on workload isolation, auto-suspend, and proving which knob to turn.

The Databricks screen opener that decides whether the rest of the interview goes deep or stays remedial. Definitions are table stakes, the points are in explaining what a shuffle physically does and how to see one in the Spark UI.

The small-files problem is the #1 self-inflicted lakehouse wound FDEs find in the field. The causes are always the same three things, and the fix has a prevention half most candidates forget.

The dimensional-modeling staple. The trip fact table is the easy part, interviewers score grain declaration, the surrogate-key rationale, and how you handle the rider who changes cities. Here's the full shape.

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.

A requirements-interrogation question disguised as an architecture question. The first move isn't Kafka, it's a freshness-SLA conversation that usually deletes 90% of the cost. Here's the script strong FDEs run.

Pure FDE territory: the customer's data is always dirtier than scoped. The layered defense, contracts, quarantine, drift handling, and the alert-severity matrix that keeps you from crying wolf.

The question where data engineering meets the AI-native FDE job. Conversations, turns, LLM calls and tool calls each have their own grain, model them wrong and neither the cost dashboard nor the eval set can be built.

A reported Databricks Solutions Architect screen question where the phrase 'handling ties appropriately' is the actual test. The SQL is six lines; the points are in interrogating 'appropriately' and the PySpark follow-up.

The Databricks Data Engineer self-join classic. One inequality predicate does all the work, get it wrong and you double-count every pair and match products with themselves. Here's the clean version and the fan-out trap.

The reported Databricks Solutions Architect live-coding staple. Working code is table stakes, the differentiators are explicit schemas, corrupt-record handling, idempotent re-runs, and knowing when explode_outer beats explode.

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.

Everyone writes the join and the ratio. Then the result comes back dominated by people who bought one thing and sent it back, and the list is useless to the person who asked for it.

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.

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

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

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.

Vercel's signature triage question. 3s TTFB is almost never 'the server is slow', it's a rendering-strategy problem with four classic causes, and the rubric rewards proving each fix with a measurement, not vibes.

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

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

A 'simple' queue question with four traps wired in: minutes-long tasks break every default timeout, cancellation has to actually stop spend, progress needs a contract, and one bad job must never wedge the lane.

API keys for systems you don't own, in environments you can't always reach, audited by security teams who don't trust you. The strong answer has one organizing principle, and a concrete story for rotation and the air-gapped case.

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.

You control the sender; thousands of customer endpoints you've never seen control your fate. The rubric hides in three places: what 'ordering' really costs, why retries need the receiver's cooperation, and the debugging surface most designs forget.

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

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

The pattern is expand-contract; the interview is everything around it: the backfill that locks the table, the rollback nobody rehearsed, and the fact that it's the customer's database, not yours. One named technique carries the whole answer.

Reported loop detail: roughly 5 hours to build a RAG system, agent, or eval harness on OpenAI's APIs, a recorded video walkthrough, then a 60-minute defense. The hour-by-hour allocation, why the eval section is the differentiator, and what the video is actually screening for.

The round is conversational discovery plus live Excalidraw diagramming, and it's graded on sequence: candidates who draw before asking fail. The discovery battery, the voice-pipeline boxes worth drawing, and the latency budget that anchors the whole design.

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 best FDE deployment is the one that doesn't need the FDE anymore. This question screens for whether you build for handoff from day one or quietly make yourself indispensable, which is the failure mode that looks like success.

The obvious engineering answer is to rewrite the notebooks properly and schedule them. Do that and you will have built something correct that the people who own the work can no longer maintain.

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.

AI-native companies ask this to separate engineers who move fast with judgment from those who just move fast. The scored part isn't the speed, it's the corner-selection logic. Here's the framework.

The incident is the setup; the disclosure timeline is the test. Interviewers are timing the gap between 'you knew' and 'they knew', here's the answer that builds trust instead of torching it.

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

Nobody cares about your final number, they're grading the decomposition, the sanity checks, and whether you convert tokens into dollars unprompted. Here's a clean worked path.

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

The most common objection in enterprise AI, and arguing back is the fastest way to fail it. The winning sequence is validate, diagnose, reframe, de-risk. Here's the script.

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.

The first use case decides the whole account, pick a flashy-but-doomed one and there's no second. Here's the value × feasibility × data-readiness workshop that strong FDEs run, hour by hour.

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.

The defining trusted-advisor dilemma, and both pure compliance and pure stubbornness fail it. The strong move is a sequence: diagnose, recommend in writing, then a test that lets the evidence decide.

The pure autonomy test: no one to ask, a customer waiting, and a scope line in front of you. Strong candidates reveal a decision rule, not a guess. Here's the rule.

A genuine filter, not small talk, Palantir interviewers have heard every dodge. The answer that works engages the controversy directly, with a position you can defend under two rounds of pushback.

The xAI signature round, 30 minutes of 'why?' aimed at one project, designed to expose orchestrators posing as builders. Here's how to choose the project and survive the drill.

The portfolio probe that opens Salesforce's Agentforce FDE loop and most 2026 screens. Interviewers are smelling for weekend wrappers, the scoring is on evals, users, and production scars, not project count.

A definition question wearing an experience question's clothes. Most candidates answer the resume half and flunk the hidden half: proving they know the operational difference between generation and agency. Here's the two-part frame.

A double-layered probe: your model-selection reasoning, and, quietly, how you handle your employer's confidential information in front of a stranger. Overshare and you fail a test you didn't know was running.

ElevenLabs has no behavioral round, it has five. A short behavioral opener starts every technical interview, which quietly turns consistency into the test. Here's how to prep for the distributed format.

A research team that owns its own way of working does not adopt your process because you're right. The candidates who win this question don't argue, they run a small proof that makes the practice obviously cheaper than the status quo, then let the team claim it.

Every ML person has chased a proxy that diverged from the thing that mattered. The screen is whether you noticed it yourself, why the proxy fooled you, and how you realigned without just swapping one number for another.

The trap is picking a disagreement you won, with a manager who looks foolish in hindsight. The screen is whether you can disagree with data, commit cleanly once decided, and know the one kind of issue worth escalating past a 'no'.

The trap is picking a disagreement so trivial that being wrong cost nothing. They want a real call you fought for, the specific evidence that flipped you, and the operating change you carry now so the same blind spot doesn't bite twice.

Reversing a decision you championed is a trust test, not a smarts test. The skill is killing your own bet on data before it kills the project, and announcing the reversal in a way that makes the team trust your judgment more, not less.

The tell of real mentorship is that you made yourself unnecessary. They want a named person, the specific gap you closed, the moment you handed them something scary, and the measurable way they grew, not 'I'm always happy to help juniors.'

Nobody assigned it, nobody asked for it, and the people you needed had their own roadmaps. The winning answer isn't 'I pushed through the resistance,' it's a small undeniable proof that turned skeptics into a coalition before you ever asked for headcount.

Every engineer can name a time they 'invested in quality.' The graded version names what you gave up, who you had to talk out of the quick win, and the specific payoff that arrived later, with a number.

The safe-but-failing move is feedback that's secretly a humblebrag ('I cared too much'). The graded version is feedback that stung because it was true, a non-defensive intake, and a specific behavior you changed that someone later noticed.

The losing answer is a personality clash you won by being right. The graded one treats it as an organizational conflict, finds the shared metric both teams actually optimize for, and keeps escalation as a last resort you used cleanly, not a weapon.

'Proud of' is not a metric. The answer that lands names the business number that moved, your specific hands on it, and how you'd defend the attribution to a skeptic who assumes you're rounding up.

Surface knowledge recites the SOTA model name. Depth names the failure mode that bites you in production and the open problem nobody has cleanly solved. This is how to sound like you've actually shipped in your area.

The screen is whether you build for your own replaceability or your own indispensability. Strong answers treat the handoff as a deliverable with a graduation criterion, not a final week of doc-dumping. Here is what to leave behind, how to transfer it, and the trap that sounds generous.

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

The question that separates a forward deployed engineer from a very good consultant. One delivers each engagement. The other notices that the third engagement looked like the first two and does something about it.

Candidate reports describe a Palantir round where you are handed unfamiliar material, given time with it, and asked to explain it. It is the job in miniature: an FDE learns a customer's domain in a week and has to be useful by Thursday. The scoring is on what you chose to teach, and on what you admitted you did not learn.

'We checked accuracy' is the answer that ends interviews. The five-layer test pyramid for ML pipelines, data contracts, transform unit tests, behavioral checks, serving tests, shadow validation, with the gates that actually block promotion.

The honest answer includes an admission most candidates are afraid to make: bit-exact GPU reproducibility is mostly a myth. The five things you version, the audit question banks actually ask, and why 'statistically reproducible' is the senior answer.

Databricks-stack interviewers use this to date your knowledge: describing Staging→Production stage transitions marks you as two years behind. The alias-based promotion flow (@champion/@challenger), gate by gate, with the access-control detail most answers miss.

The AWS ML Engineer staple. The answer that scores is a clean division of labor, CodePipeline owns code, SageMaker Pipelines owns the ML DAG, the Model Registry is the handoff point, plus the cross-account detail that separates real builds from doc reading.

Microsoft's scenario rounds reward one specific framing: two pipeline systems, two jobs, one handoff point. Which tool owns triggers and approvals, which owns compute and lineage, and the managed-endpoint detail that makes blue-green trivial.

Auto-retrain is easy; auto-promote is where teams ship incidents. The champion/challenger gate design, two eval sets, segment floors, guardrail metrics, and the defensible line on when a human stays in the loop.

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

The bug that makes offline metrics a lie: training on information that didn't exist at prediction time. A concrete fraud example with timestamps, the as-of join that fixes it, and the label-maturity trap automated retraining adds on top.

The bug class with no stack trace: the model is fine, the pipelines are green, and production quietly underperforms offline by five points. Why skew survives even feature-store adoption, and the log-and-wait pattern Google-style answers center on.

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.

Reported from JPMorgan's MLE loop, and graded on one distinction most candidates miss: rollback is a capability you build before the incident, not an action you improvise during it. The pointer-flip mechanics, the auto-trigger debate, and when rollback itself is unsafe.

An experience probe with a depth gauge: 'we used Kubernetes' fails, and so does reciting the KServe README. The stack-process-role-warstory structure, the resource and probe details that prove hands-on work, and where KServe earns its complexity.

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 'works on my GPU box, CUDA error 803 in prod' bug, solved at the source. What the host driver actually pins, why the toolkit version is fungible, and the multi-stage build that ships a lean reproducible image.

The dataset is too big to fit on disk, so you stream it. The components that keep the GPU fed, the throughput math that says whether you'll be I/O-bound, and the failure handling that makes a multi-day run resumable.

The two access-pattern killers behind most 'my kernel is 10x slower than cuBLAS' mysteries. The matrix transpose walks straight into both, which is why NVIDIA loves asking about it.

Everyone says 'maximize occupancy.' The candidates who get hired at NVIDIA know when 25% occupancy beats 75%, and can explain the resource math that decides it.

The roofline model in one ratio: FLOPs per byte against the hardware's ridge point. Get the H100 arithmetic right and you can classify any kernel, including why LLM decode will never be compute-bound at batch 1.

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.

The one derivation every GPU-infra loop expects on a whiteboard: scatter-reduce plus all-gather, 2(N−1)K/N per GPU, and why that's provably near-optimal. Plus the latency catch that motivates tree algorithms.

The 16-bytes-per-parameter breakdown that makes ZeRO's three stages obvious instead of memorized, and the communication bill each stage runs up in exchange.

NCCL's topology tricks, GPUDirect RDMA, and the single most misleading metric in distributed training. If you've ever trusted nvidia-smi on a slow run, this question was written for you.

Both carry RDMA at 400Gb/s; the decision is about loss behavior, tuning burden, and who operates it. A defensible recommendation with the conditions that flip it, the format this question is scored on.

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.

The OS virtual-memory trick that made vLLM the default serving stack. The answer interviewers want quantifies the fragmentation it killed, and knows what it cost in exchange.

One forward pass, two opposite performance regimes. The arithmetic-intensity argument that explains TTFT vs TPOT, GPU pool design, and why the big serving stacks split the phases onto different hardware.

Free tokens from idle FLOPs, losslessly, which surprises most candidates. The mechanism, the acceptance-rate math, and the high-batch regime where speculation quietly stops paying.

torch_xla makes the demo run in an afternoon; making it fast is where migrations die. The lazy-tensor mental model, the recompilation traps, and the honest fork between porting and rewriting in JAX.

A reported OpenAI phone-screen exercise that looks trivial and is graded on edge cases: money-safe arithmetic, billing increments, unknown SKUs, and the clarifying questions you ask before typing.

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.

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

Poisoning questions sort candidates who've read about backdoors from those who can name where poison enters a real pipeline, and why the embedding store is the soft target nobody audits.

ATLAS questions filter candidates who can name the framework from those who can run an incident through it. The mapping exercise, one concrete attack, kill-chain stage by stage, is what the interviewer actually wants to hear.

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.

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

MCP turned 'install a plugin' into 'inject text into every conversation.' Interviewers ask this to see if you understand why tool descriptions are an attack surface, and what a least-privilege agent runtime looks like.

A reported AI-security interview staple with a known grading rubric: recon, bypass, leakage, tool abuse, multi-turn drift. Candidates who free-associate attack ideas fail; candidates who run a structured campaign pass.

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

Every EU enterprise deal hits this question, and the FDE in the room is expected to carry it without legal on the call. The processor/controller split, the transfer mechanics, and the one GDPR right that's hard for LLMs.

'Can't leave our environment' means four different things to four different stakeholders. The FDE skill is decomposing the demand into the actual requirement, and knowing which deployment tier each requirement really needs.

HIPAA-with-LLMs questions test whether you know the three things that gate the deal: the BAA, the minimum-necessary standard, and audit controls. Engineers who can name 45 CFR obligations in design terms win these rooms.

The AI Act question is a classification exercise in disguise: interviewers give you a use case and watch whether you can tier it, name the obligations, and know whose job each one is, provider or deployer.

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 Snowflake solutions-loop classic that generalizes to every AI deployment: why masking retrofits fail, what a role hierarchy actually looks like, and the policy-attachment model that makes governance survive schema growth.