Meta Forward Deployed Engineer interview questions

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.

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.

The most common screen opener, and interviewers use it to check whether hashmap thinking is reflexive. Here's the one-pass answer, the narration that earns points, and the duplicate-handling edge case most candidates fumble.

A 5-minute warm-up that quietly tests the most useful idea in practical coding: choosing a canonical key. The sorted-string vs character-count tradeoff is exactly what interviewers want to hear you reason about.

The interval pattern shows up everywhere in FDE loops: calendars, flight segments, log windows. Master the sort-then-sweep idiom here and three other interview questions fall out for free.

The follow-up interviewers reach for when merge-intervals goes too smoothly. The three-phase scan is elegant, but only if you've internalized the overlap condition most candidates have to re-derive under pressure.

Top-K is the most reused primitive in FDE interviews: it reappears inside log parsers, analytics questions, and retrieval ranking. Three solutions exist; knowing which one to lead with is the real test.

Looks like a sliding-window problem; isn't one. The prefix-sum + hashmap trick that solves it is the same idea behind sessionization and cumulative-metrics questions later in the loop: learn it once, reuse it three times.

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

The single most-asked design-a-data-structure question in FDE loops. There's an interview-legal Python shortcut and a from-scratch version, and knowing when to offer which is half the grade.

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

The canonical grid question, and the template for every flood-fill, shortest-path, and region-labeling variant FDE loops throw at you. BFS vs DFS vs union-find: here's which to write and which to merely mention.

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

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

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

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

The assign-then-update loop is ten lines; the signal is whether you handle the three things that bite in production: initialization, an empty cluster, and a real convergence test instead of a fixed iteration count.

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

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

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

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.

A sliding window with a last-seen index map, O(n) in one pass. The whole interview turns on one subtlety: when you hit a repeat, the window's left edge must jump forward and never slide backward, which is exactly the bug most candidates ship.

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

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

Almost everyone writes the version that only compares each node to its immediate children, and almost every interviewer has a counterexample ready. The fix is to carry a valid (low, high) range down the recursion, or to check that an inorder traversal is strictly increasing.

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

Every pipeline eventually double-loads data, so every FDE screen eventually asks this. There's one canonical idiom, plus a determinism detail that decides whether your dedupe is rerun-safe.

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.

The hardest 'standard' SQL interview pattern, asked everywhere from Meta to Palantir. There's a three-line trick that turns consecutive runs into a GROUP BY key, once you've seen it, you can't unsee it.

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

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

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

Join fan-out is the bug behind half of all 'the dashboard numbers are wrong' escalations an FDE will ever field. The mechanism, the 30-second detection query, and the three legitimate fixes.

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.

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

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

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

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

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

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

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.

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.

Kernel optimization is mostly the art of feeding 100+ TFLOPs from the small fast end of this hierarchy. Know the rough latencies and bandwidths, interviewers listen for the numbers.

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

The backbone question of every frontier-lab infra loop. The answer that scores is organized around what each strategy communicates and how often, not just what it splits.

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

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

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

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

Bits buy bandwidth, bandwidth buys tokens, until quality quietly craters on code and math. A decision framework with the numbers, what GPTQ and AWQ actually do differently, and the eval discipline that keeps you out of trouble.

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

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 feed touches billions of candidate items and has tens of milliseconds to pick the next 10. The interview is about the two-stage architecture, what you optimize when engagement and integrity pull against each other, and the biases that quietly poison your training data.

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.

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

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.

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.

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.

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.

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.

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