AWS Forward Deployed Engineer interview questions

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.

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.

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

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

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

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

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.

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.

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.

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

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

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

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.

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

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

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

Every request emits a usage event worth real money, clients retry on timeouts, and tenants must be stopped at their quota and never overcharged. The hard parts are idempotent usage events and the succeeded-but-confirmation-lost case where the work happened but the client never heard back.

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.

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

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.

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

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

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

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

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.

The trap is that S3 versioning sounds like a complete rebuttal, it isn't, and interviewers at banks know exactly why. What a registry adds that storage never can, and the audit question that decides regulated-industry offers.

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.

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

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

'Retrain weekly' is the answer interviewers let you finish before dismantling it. The four trigger types, how to stop a drift alarm from causing a retraining storm, and why the trigger question is really a cost-and-staleness trade.

Everyone names PSI and KS; almost nobody knows why the KS p-value betrays you at production scale. The thresholds that are actually industry convention, the response ladder behind them, and the trap answer interviewers bait on purpose.

Reported from Capital One ML loops, and the symmetric 'both have pros and cons' answer fails it. Why model failures being statistical makes canary the default, the two cases where blue-green wins, and the entity-randomization detail that survives follow-ups.

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

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.

An incident question graded on method, not tools: interviewers want ordered hypotheses, each with a five-minute test. The version-skew check most candidates never think of, the cache trap, and the triage tree that finds the usual culprit fast.

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 45-minute MLOps capstone reported from Capital One and Uber loops. The component walkthrough is table stakes, what's graded is sequencing, the batch-vs-realtime call made early, and knowing which pieces you'd cut for v1.

The experience probe where tool soup fails and one well-told pipeline wins. The context-stack-hardest-problem-outcome structure, the two challenges every real implementation hits, and the before/after numbers that make the story land.

The 'why' is the question: AWS gives you five ways to host a model, and interviewers want the decision tree plus the trade-off you knowingly accepted. The walkthrough structure, the real cost math between SageMaker endpoints and EKS, and the answer shape that survives drilling.

The lead-level capstone: not 'which metrics' but 'what's your operating program.' SLOs per model, a drift policy with teeth, retraining as routine rather than rescue, and the inventory discipline that separates teams who run models from teams who babysit them.

A staff-level platform design where the constraint set, not the architecture, is the test. The controls SR 11-7 actually demands, how to make audit a byproduct of the pipeline instead of a quarterly fire drill, and the v1 you can ship without a compliance finding.

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 incident with no onset spike and no pager: precision bled out over weeks while every dashboard stayed green. How to run a blameless postmortem when the incident has no clean start time, the root-cause classes that hide this long, and the action items that actually prevent the next one.

An ambiguous, time-pressured staff scenario: the signal is soft, labels won't confirm anything for weeks, and rollback itself has risks. The decision framework under uncertainty, when to revert on a proxy, and the remediation for decisions the bad model already made.

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

Do the weight math first, then choose your poison: shrink the weights, split them across GPUs, or spill to host memory. Each buys you the fit at a different cost, and one of them is almost always wrong for production.

A track lasts three minutes, a session lasts an hour, and a new song has zero plays the day it drops. The interview is about blending collaborative filtering with audio content embeddings, surviving cold start on both sides, and reading a skip as the loud negative it is.

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.

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.

New courses launch every week and most browsers are signed-out or brand new, so the interesting half of this problem is what you recommend when you have almost no behavioral signal. The other half is not optimizing engagement into a clickbait catalog.

A search box is a recommender with a strong prior: the query. The hard parts are understanding ambiguous intent, retrieving in two stages under a tight latency budget, and learning from clicks without teaching the model that whatever you showed first is best.

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.

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.

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.

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

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.