Google Forward Deployed Engineer interview questions

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

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

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

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.

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.

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

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

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

Three transformer families, one distinction that decides everything: which tokens are allowed to see which. The attention mask is the whole answer, and it explains why GPT generates and BERT does not.

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.

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

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

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.

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

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 fixed 1000-token budget forces the search choice. Step-level beam search guided by a process-reward model beats best-of-N and MCTS on accuracy per token for math, and you collect the PRM labels automatically with Monte-Carlo rollouts, no human step annotation.

The citation is real and semantically relevant, yet the advice belongs to different equipment. Resolve applicability before ranking and preserve the version decision through generation and evaluation.

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

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

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

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

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

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

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

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.

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

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.

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

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.

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

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.

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

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

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.

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.

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.

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

A 0.95 AUC model can still flood a review queue with garbage. Knowing when ROC AUC flatters a model, and what to report instead, separates FDEs who've shipped from those who've only run notebooks.

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.

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.

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.

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

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

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.

Unsupervised questions filter out candidates who've only done Kaggle. The elbow method is the warm-up, the real scoring is on validation without labels and the marketing-team handoff.

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.

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

Most working data scientists state the definition wrong, and interviewers know exactly which wrong versions to listen for. The correct one-sentence definition, the VP translation, and the three classic traps.

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

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.

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.

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.

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.

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.

A confusion matrix is the 2x2 of right and wrong predictions per class, and it is the reason a 99% accurate fraud model can be useless. The worked imbalance example, and how reading the matrix as precision and recall fixes the lie.

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

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

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

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.

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

Ten X-ray studies a second, a 2-second budget, and a missed cancer is unacceptable. The hard parts are recall-first thresholding, a monitor that watches the radiologist, and surviving a new scanner.

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

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

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

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

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

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

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.

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

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

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.

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

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

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

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

They answer different questions, and mixing them up costs you the round: one tests your engineering, the other tests your model's business impact. What each can and cannot catch, and the order a strong candidate always runs them in.

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

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

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

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

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 NVIDIA warm-up that exposes whether you've written a kernel or just called .cuda(). The mapping from software hierarchy to silicon explains every GPU performance conversation that follows.

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.

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

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

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.

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

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

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

Going 4K to 1M is not one trick. It is RoPE rescaling chosen by frequency band, a long-doc continued-pretrain mix, needle evals that actually catch failures, and KV math that forces ring attention.

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

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

SAEs can surface candidate 'deception' features in the residual stream, but a correlated feature is not a cause. The real work, and the honest answer, is causal validation and admitting what interpretability cannot yet prove.

Fine-tune a LoRA adapter on the user's typing on the phone's neural engine, add noise locally with DP-SGD, and aggregate only adapter deltas, so no individual's vocabulary is recoverable from the global update.

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

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

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

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

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

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

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

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

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

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

A deceptively simple sampling question with one trap (does temperature 0 fix hallucinations?) and one senior move interviewers reward. Know which workflows want zero.

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

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