Amazon Machine Learning Engineer Interview Guide 2026

Interviewing at Amazon

• Practice bank: 6+ questions
• Rounds: 2
• Typical prep: 1–2 weeks
• Interview reports: 4

Interview rounds

Round	Questions
Technical Screen	3
Onsite	3

How hard is the Amazon Machine Learning Engineer interview?

Difficulty	Share	Questions
Easy	0%	0
Medium	100%	6
Hard	0%	0

What Amazon actually tests for

Topic	Share	Questions
ML System Design	33%	2
Machine Learning	33%	2
Analytics & Experimentation	17%	1
Behavioral & Leadership	17%	1

Amazon machine learning engineer interview preparation should connect model quality to the system that produces and serves predictions. A recommendation model can look better offline because its features contain future information. It can also improve clicks while creating a worse listening experience or missing the serving budget.

This guide works through an original music-recommendation click case: labels, feature availability, a runnable baseline, chronological evaluation and a resolved rollout decision. The synthetic code results and fictional canary are separate from Amazon’s hiring information. Neither represents an Amazon production experiment or a private interview rubric.

Confirm the role’s emphasis before preparing

Amazon’s general hiring page states that its process differs by role. The reviewed sources do not establish a universal MLE stage count, duration or assessment. Ask your recruiter how the role balances coding, applied ML, ML system design and behavioral discussion, and which tools are permitted.

Prepare code you can test, a model decision you can justify, an architecture with failure boundaries and true examples of your contribution. Practice in the confirmed environment. A modeling-heavy role and an ML platform role can require different depth even when both use the MLE title.

For company context, read the published Leadership Principles. This guide’s project rehearsal connects customer impact, ownership and investigation to a failed rollout; it does not assign a secret score to a particular phrase.

Original case: predict a click on a recommended song

The verified record covers user/song/context inputs, sparse features, probability quality and listening outcomes. The smaller implementation below isolates point-in-time data and probability evaluation; retrieval and a full ranking model are outside its code.

Practice contract. An impression is one displayed song for a user in a session. Predict the probability of a click within 30 minutes. Use an impression ID to join the label; repeated exposures receive separate IDs. Duplicated impression events must be deduplicated before training.

Wait for the 30-minute attribution window plus a 24-hour ingestion allowance before treating a missing click as a negative. In a real pipeline, use an observed ingestion watermark and a policy for events beyond it. The fixture’s fixed 1,470-minute delay is a teaching choice, not an Amazon or AWS default.

Treat clicks as a proxy. Specify listening-quality guardrails before rollout: early skips, completed listens or another agreed customer outcome. Otherwise a model can learn to attract clicks toward songs that listeners quickly abandon.

Reconstruct features as they were available

Track two times for every feature version: when its source event occurred and when the serving system could use it. For an impression at time 100, an event at 90 that arrived at 105 was unavailable. Filtering only by event time still leaks.

Feature version	Event time	Available time	Eligible at 100?
Known affinity 0.2	80	82	Yes
Late affinity 0.9	90	105	No: not yet available
Future affinity 0.8	101	101	No: event is later

The code selects 0.2. It also excludes a deliberately poisoned future feature derived from the synthetic label. Missing history returns None, which the model handles with the training prior rather than inventing an affinity.

In a larger system, keep the feature definition and transformation version with each prediction. Offline historical reconstruction and online lookup must implement the same semantics. AWS Feature Store distinguishes current online values from historical offline records; history alone does not remove the need for a correct as-of join.

Choose a small baseline before a larger model

The global baseline predicts a Laplace-smoothed training click rate. The candidate estimates separate probabilities for a low- and high-affinity bucket, also with smoothing. This is intentionally a tiny probability model, making its inputs and outputs easy to inspect.

The synthetic generator assigns click probability 0.05 or 0.25 based on the known affinity. That creates a learnable relationship deliberately; it is not evidence that one feature is sufficient for a real recommendation service. A useful real baseline might include popularity, recency and metadata before adding interaction features or a more expensive ranker.

For sparse song and user identifiers, cap vocabulary growth and define out-of-vocabulary handling. Compare a simple feature model with interaction-aware alternatives. New songs can use available genre, artist or audio metadata even when their learned ID representation has little history. Keep missingness distinct from an observed zero.

Runnable data and model fixture

Save the following as click_model.py and run python click_model.py. It uses only Python’s standard library. All data is synthetic, generated with seed 6262; time is expressed in minutes relative to a toy origin.

import math, random

def as_of(history, key, t):
    eligible = [r for r in history.get(key, []) if r['event'] <= t and r['available'] <= t]
    if not eligible: return None
    r = max(eligible, key=lambda r: (r['event'], r['available']))
    return r['value']

def mature(rows, start, end, cutoff):
    return [r for r in rows if start <= r['t'] < end and r['ready'] <= cutoff]

def fit(rows):
    if not rows: raise ValueError('empty training data')
    prior = (sum(r['y'] for r in rows) + 1) / (len(rows) + 2)
    probs = {}
    for bucket in (0, 1):
        group = [r for r in rows if r['x'] is not None and int(r['x'] >= .5) == bucket]
        probs[bucket] = (sum(r['y'] for r in group) + 1) / (len(group) + 2) if group else prior
    return prior, probs

def predict(model, x):
    prior, probs = model
    return prior if x is None else probs[int(x >= .5)]

def evaluate(rows, predictor):
    if not rows: raise ValueError('empty evaluation data')
    ps = [predictor(r['x']) for r in rows]
    return {'n':len(rows), 'clicks':sum(r['y'] for r in rows),
            'log_loss':sum(-r['y']*math.log(p)-(1-r['y'])*math.log(1-p) for r,p in zip(rows,ps))/len(rows),
            'brier':sum((p-r['y'])**2 for r,p in zip(rows,ps))/len(rows)}

def fixture():
    rng = random.Random(6262); rows=[]; history={}
    for i in range(1000):
        t=i*60; key=str(i); x=rng.randrange(2); y=int(rng.random() < (.05 if x==0 else .25))
        history[key]=[{'event':t-10,'available':t-5,'value':float(x)},
                      {'event':t-1,'available':t+1,'value':float(1-x)},
                      {'event':t+2,'available':t+2,'value':float(y)}]
        rows.append({'id':i,'t':t,'x':as_of(history,key,t),'y':y,'ready':t+1470})
    return rows, history

def run():
    rows, history=fixture()
    train=mature(rows,0,36000,36000)
    valid=mature(rows,36000,48000,48000)
    test=mature(rows,48000,60000,61470)
    model=fit(train)
    outputs={'train_n':len(train),'model':model,'validation':{},'test':{}}
    for name, split in [('validation',valid),('test',test)]:
        outputs[name]['baseline']=evaluate(split,lambda x:model[0])
        outputs[name]['candidate']=evaluate(split,lambda x:predict(model,x))
    return outputs

if __name__=='__main__':
    import json
    print(json.dumps(run(),indent=2))

The example has 1,000 impressions at hourly intervals. Of the first 600 intended training rows, only 576 have mature labels at the fitting cutoff. Of 200 intended validation rows, 176 are mature at its assessment cutoff. All 200 final test labels are mature at the later cutoff.

The candidate is fit once on training data. Validation checks the proposed comparison; the subsequent test evaluates that same frozen model. No test outcomes tune thresholds, features or smoothing. Waiting for labels creates an explicit gap before each later evaluation period.

Inspect observed offline results

The learned global prior is 0.159170. The candidate probabilities are 0.062937 for low affinity and 0.255102 for high affinity. Missing features use the prior. The executable output gives:

Later split	Labels / clicks	Baseline log loss	Candidate log loss	Baseline / candidate Brier
Validation	176 /28	0.438159	0.421675	0.133781 /0.129216
Test	200 /31	0.431350	0.401608	0.130992 /0.123801

Both metrics are lower for the candidate on this fixture. Log loss penalizes confidently incorrect probabilities; Brier score measures squared probability error. Neither proves calibration for every cohort or that reranking songs will improve customer outcomes.

The local harness passed 1118 checks: 100 independently sorted as-of comparisons, all 1,000 feature selections, label-boundary tests, disjoint chronological splits, probability fallbacks, empty-data rejection and evaluation checks. The generated late and future records are excluded from every impression’s feature.

Before using real data, compare new versus established users, new songs, feature-missingness cohorts and device slices. Inspect reliability bins with enough samples and distinguish discrimination from calibration. Logged exposures reflect the old recommendation policy; songs never shown provide no ordinary click label. Off-policy evaluation needs additional assumptions and logged action probabilities where applicable.

Serve within a declared budget

For the original design exercise, choose a 120ms request budget for scoring an already retrieved candidate set. Allocate caps of 15ms to request handling, 10ms to lookup, 35ms to model scoring, 10ms to response work and 25ms to reserve, totaling 95ms. These are hypothetical component caps, not measured AWS performance.

Adding component p95 values would not prove a request-level p95. Measure end-to-end latency under load and examine feature-missingness, timeouts and fallback rates. The local Python fixture makes no latency claim.

Version the model, feature schema and transformation together. A schema mismatch or feature deadline should trigger a defined fallback to the previous compatible model or baseline. Keep the fallback’s exposure logged so downstream evaluation knows which policy actually served the request.

Resolve a fictional canary decision

The following numbers are fictional practice data, separate from the executed offline fixture. Randomize by user, with one evaluated impression per independent user and 20,000 users per arm. The control records 800 clicks; the candidate records 816.

CTR rises from 4% to 4.08%: 0.08 percentage points, or 2% relative. A normal approximate 95% interval for the difference is −0.3059 to +0.4659 percentage points. It includes zero; this sample does not establish a positive click effect. Repeated looks and multiple metrics would need a predeclared analysis plan.

Signal	Control	Candidate	Declared decision rule
CTR	4%	4.08%	Estimate effect with uncertainty
Early skips	20%	23%	Rollback above +1 percentage point
End-to-end p95	90ms	145ms	Rollback above 120ms

Decision: rollback. The click estimate does not rescue the failed listening and latency guardrails. The difference between an operational safety canary and a statistical benefit test matters: healthy serving is necessary for further exposure, but it does not establish business benefit.

Pin routing to the previous compatible model and feature version, verify traffic adoption, fallback rate and request latency, and watch listening outcomes after their label delay. Preserve request logs and manifests for investigation. Do not immediately retrain on immature negative labels or claim the rollback restored every delayed outcome.

AWS SageMaker deployment guardrails offer traffic-shifting and rollback mechanisms for supported real-time and asynchronous endpoints, with exclusions. This is implementation context, not a claim that those settings are automatically enabled or that a latency alarm protects listening quality. Configure the actual alarms and bake period for the chosen endpoint and workload.

A failed-rollout story for behavioral rehearsal

Use this fictional rehearsal outline to practice structure, then replace it with your own truthful project. A team proposes a rollout because offline log loss improves. The owner notices that the canary’s skip rate and latency exceed the predeclared limits, recommends rollback and explains why the small click increase is inconclusive.

The fictional investigation finds that the serving transformation performs an extra remote lookup that the offline evaluator never executes. The repair makes the feature contract explicit, adds a deadline and compatible fallback, and tests the serving path. The proposed new model remains unlaunched until delayed listening labels and a new controlled evaluation are reviewed.

Explain your responsibility, the evidence available at the decision time, the alternative considered and what remained unresolved. Connect customer outcomes to Customer Obsession, investigation to Dive Deep and the recovery mechanism to Ownership. Those are reflection prompts based on published principles, not private interview scoring instructions.

If your real result was imperfect, say so. Separate your code, your recommendation and the team’s execution. Do not present a rehearsal or synthetic test as something you shipped at work.

Prepare across coding, ML and operations

Use day one to confirm your loop and implement the feature/label contract. On days two and three run the fixture, explain both metrics and inspect leakage failures. Use day four to add sparse-feature and cold-start design choices; day five covers serving budgets and a versioned fallback.

On day six rehearse the canary decision, including uncertain CTR and delayed outcomes. On day seven run a mixed mock and a true project deep dive. For coding, practice data structures and clean APIs alongside the ML work; being able to discuss models does not replace executable reasoning.

Sources and scope

• Amazon How We Hire: role-dependent process and interview resources.
• Amazon Leadership Principles: published behavioral context.
• SageMaker Feature Store: online current values and offline history.
• SageMaker deployment guardrails: supported endpoint deployment and rollback options.

Checked October 9, 2026. Offline outputs come from the original local Python fixture; the canary and failed-rollout story are explicitly fictional. No Amazon interview, AWS endpoint, real recommendation traffic or production rollout was exercised. Your invitation controls current interview details and permitted tools.