Microsoft Forward Deployed Engineer interview questions

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

A classic metrics question with a domain twist. The answer isn't 'recall'; it's a cost-of-errors argument plus a threshold strategy, and interviewers grade the reasoning, not the metric you pick.

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.

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 classic FDE escalation. Six hypotheses, silent model updates, input drift, prompt entropy, sampling noise, perception shift, and the eval-replay test that splits them in an afternoon.

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

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

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

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.

Glean's signature design question. The two traps: post-filtering that drains your top-k, and the leak through generated answers. The winning architecture filters at retrieval, and here is how, at scale.

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

Slides are the worst RAG corpus: text in shapes, meaning in charts, the message in the image. A query like 'the blue bar chart with Q3 revenue' fails if you embed only the extracted text, and citing the wrong slide number kills trust instantly.

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.

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.

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.

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

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

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

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

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.

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.

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.

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

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.

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.

The most common bug in analyst SQL, and a favorite warm-up in Retool's debugging-flavored screens. One word's placement, ON vs WHERE, silently deletes your unmatched rows.

Asked constantly because it tests whether you understand aggregation rather than syntax. The CASE-inside-aggregate idiom works on every engine, plus when to reach for Snowflake's PIVOT and its dynamic variant.

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

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

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

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

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

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.

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.

This isn't a deployment question, it's a judgment question wearing one. Interviewers are scoring whether you have a decision framework, a safety checklist, and the spine to say no to a customer politely.

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.

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.

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

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

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

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

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

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

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

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

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.

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

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.

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.

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

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.

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

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.

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

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

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

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.

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.

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.

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.

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.

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

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

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.

OWASP's LLM01 is the opening question of nearly every AI security screen. Most candidates can define direct injection; the ones who get hired explain why indirect injection is the one that ruins enterprise deployments.

Candidates use these terms interchangeably and security interviewers notice immediately. The distinction, whose policy is being violated, drives completely different defenses, and that's the actual question.

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.

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.

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.

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

A deceptively simple screener: each detection method maps to a PII class, and the 'why not regex for names' sub-question has a precise answer about structure vs context that interviewers use as the pass bar.

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.

The four-point redaction design is becoming the standard FDE privacy round. Most candidates fortify the chat box and lose on the other three doors, here's the full design, including the de-redaction map that makes it usable.

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.

The defining security design problem of enterprise RAG, and the reason Glean exists. Query-time ACL filtering, permission sync lag, and the leakage channels that survive naive designs: caches, citations, and the model itself.

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

A real customer ask from the field, and a layered design question in disguise: attribution, budgets, anomaly detection, and enforcement, plus the attribution problem that decides whether any of it works.

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

Authentication is not isolation: a request can be fully authenticated to tenant A and still touch tenant B through a shared index, a semantic cache, or a fine-tuned model. The strong answer names every shared surface and how you stamp tenant identity through all of them.

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

Cross-tenant or cross-user data exposure through a model is the breach that starts regulatory clocks. The runbook has to answer 'whose data, to whom, how many' from logs that most teams never designed for, and contain a leak that may live in a cache or a fine-tuned model, not a deploy.

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

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

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

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.

Two ways to prove a cloud LLM run is the audited model on the customer's input: a zero-knowledge proof of the computation, or a TEE attestation. They differ by roughly an order of magnitude in overhead and entirely in trust assumptions.

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.

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.

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.

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

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.

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.