Databricks Forward Deployed Engineer interview questions

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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

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

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

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

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.

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.

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

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

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

Everyone can describe the five folds. The question is really about the second half, the two data shapes, both everywhere in enterprise data, where standard k-fold quietly lies to you.

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.

Every RAG deployment runs on this math, and most candidates can't say why cosine beats Euclidean, or when the two are secretly identical. The 90-second version with a worked example.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

The honest version: deep learning learns its own features but is hungry for data and compute, and on a customer's 50,000-row tabular dataset a gradient-boosted tree wins on accuracy, cost, and time-to-ship. The dividing line and the conditions that flip it.

A Type I error blocks a real invoice; a Type II error delivers the phishing email. Which one costs the customer more decides where you set the threshold. The spam-filter framing, the precision/recall mapping, and the asymmetric-cost call interviewers want.

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.

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.

The validation set is the one you tune and select on; the test set is the one you only look at once. Confusing them, or tuning so hard you overfit the validation set, is how a model that aced offline metrics dies in production.

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.

The naive pipeline gives you 10 million 'summarize this paragraph' pairs and a model that can only summarize paragraphs. The hard part is diversity and quality control at 100-billion-document scale, not the generation call.

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.

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.

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.

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

A warm-up that quietly reveals whether you understand why analytical engines are fast at all. Compression, projection, predicate pushdown, and the one workload where columnar is the wrong choice.

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

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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

One malformed message can silently wedge an entire pipeline, and it happens at every customer eventually. The DLQ answer interviewers want covers what most candidates forget: what happens *after* the message lands there.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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

There's no trick here, except that interviewers are listening for one specific word: a plan. The candidates who fail give enthusiasm; the ones who pass give logistics.

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

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.

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.

A live translation test of the FDE's core skill: same facts, different altitude. There's a four-line formula execs actually read, and one translation error that destroys trust.

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.

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

The graded shape is specific: learn and ship something small by day 30, own a deployment by day 60, drive a cross-customer improvement by day 90. Vague answers about 'meeting stakeholders and ramping up' fail. Here is the staged plan with what good looks like at each gate.

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.

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

Asked in every loop, prepared for by almost nobody, and it has a single mechanical test that tells you whether your answer is any good before you ever say it out loud.

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.

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.

A textbook screen with a non-textbook scoring rubric. Naming Tracking, Projects, Models, and Registry gets you a pass, knowing which component nobody actually uses, and why, gets you the offer conversation.

A real interview question designed to catch resume inflation: candidates say 'we promote to production' and can't name the API call. What actually moves when a model is promoted, and the answer that proves you've done it.

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

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

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.

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.

Each customer has their own LoRA on a shared 8B. The S-LoRA-style answer keeps one base in memory, pages adapters in and out, and tags every KV block with an adapter ID so reuse never crosses tenants.

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

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

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.

Averages lie, and interviewers know most candidates quote them anyway. The fastest way to sound production-grade in any latency discussion is to reason about percentiles correctly, including the one trap almost everyone falls into.

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 standard AWS ML Engineer opener. Most candidates recite 'data and model versioning' and stall, the answer interviewers score highest explains why ML tests can't be pass/fail and what continuous training adds as a third loop.

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

A 40-year-old SQL classic that still filters out half of candidates, because of ties, NULLs, and departments with one employee. The interview-proof solution fits in six lines.