Amazon Engineering Manager Interview Preparation Guide - Junior Level (1-2 Years Experience)

Headroom sizing

Say baseline traffic is 2,000 requests per second (RPS); 10x gives a forecast peak of 20,000 RPS. Because this is a one-off event with limited prior data for this specific sale, I'd add a larger buffer than I would for a recurring, well-understood pattern, say 30% for forecast uncertainty, putting the target ceiling at about 26,000 RPS.

Hold-ready versus scale-into-it

For a 72-hour hard deadline with no room to react mid-event, I'd hold the full 26,000 RPS capacity ready in advance rather than plan to scale into it reactively. The reasons: there's essentially zero time to safely validate new capacity once the sale is live, and retail checkout paths usually have state that needs warming, caches, database connection pools, CDN edge caches, which can't be spun up instantly under load. This is different from a slow, sustained growth scenario, where reactive scaling is fine because there's time to react.

Cost versus risk

Holding the extra 26,000 RPS-capable capacity ready for about a week around the event, covering setup, the sale itself, and teardown, might cost on the order of a few thousand dollars in extra infrastructure spend. Against that, a marquee 72-hour sale falling over mid-event risks a large multiple of that in lost revenue and reputational damage, on a fixed, unrepeatable window (unlike ongoing growth, where over-provisioning forever really would be wasteful). The asymmetry between a small, bounded extra cost and a large, irrecoverable failure cost is what justifies over-provisioning for this specific case.

Three measurable commitments I'd propose to the client

1. A latency commitment: for example, checkout p99 latency (the slowest 1% of checkout requests) stays under 500ms up to 22,000 RPS, comfortably inside the tested 26,000 RPS ceiling.
2. An error-rate commitment: error rate stays under 0.1% for the full 72-hour window.
3. A headroom commitment as a business metric: at least 15% spare capacity above observed peak traffic is maintained throughout the event, with an internal alert if it drops below 10%, so there's a documented safety margin the client can see, not just a promise.

Situation & goal (brief)
I run PIPs to give clear opportunity for improvement while building a legally-defensible record that minimizes company risk and preserves fairness.

Step-by-step process

1. Diagnose & document before PIP

• Collect prior performance reviews, 1:1 notes, sprint metrics (PR throughput, code review times), bug/incident tickets, missed commitments and any coaching given.

2. Draft PIP with HR input

• Concrete objectives, measurable success criteria, timeline (typically 30–90 days), support offered (mentorship, training), and specific consequences if unmet. Share draft with HR and Legal for compliance.

3. Approvals required

• Manager + HR Business Partner sign-off; for high-risk roles or terminations, include People Ops Director and Legal. Document approvals in HRIS.

4. Communication cadence

• Kickoff meeting with employee + HR present; provide written PIP. Weekly check-ins with documented notes and interim progress summaries to HR. Final review meeting at plan end.

5. Decision & documentation for termination

• Compile the PIP, all check-in notes, objective metrics, accommodations offered, and dates. Have HR and Legal review recommendation before any termination. Provide written termination rationale tied directly to PIP criteria.

6. Ensure consistency

• Use standard PIP template, calibrate with peers for similar cases, maintain audit trail in centralized system, and run quarterly calibration reviews with other managers/HR to detect bias.

Outcome & rationale
This approach creates transparent expectations, an evidence-based record, and multiple approvals — reducing legal exposure while treating the engineer fairly.

Direct answer
This is a behavioral question, so the strongest answers are structured like a mini blameless postmortem of your own: what happened, how you led the review to find the real cause without assigning blame, and what concrete, lasting change resulted. A useful shape: Situation and impact, how you reconstructed the timeline and facilitated the discussion, the root cause you landed on, and the specific action item plus its measured outcome.

Structured elaboration
What a strong answer covers, in order:

• Situation: a real incident with real stakes, stated concretely (what broke, how many users or how much revenue, how long).
• Your role in the review: specifically how you assembled the facts (logs, timeline, who you talked to) before the meeting, and how you kept the discussion focused on the system rather than the person once it started, including a moment where you actively redirected a conversation that was drifting toward blame.
• What you found: the root cause and at least one contributing factor, stated in system terms, not person terms.
• What changed: a specific action item, who owned it, and, ideally, evidence it actually worked (the incident class hasn't recurred, a new safeguard caught a similar issue before it became an incident, and so on).
• If the story also involved coaching a less experienced teammate through their first postmortem, or the postmortem was for a non-technical failure (a partnership or research misstep, not a software outage), that is a legitimate and often more differentiating variant of the same story shape.

Worked example
"I led the postmortem after a database migration corrupted a subset of order records over a weekend, affecting about 2% of orders. I pulled the deploy history, error logs, and the migration script itself before the meeting so we started from a shared timeline instead of memory. In the meeting, when someone started to say the engineer who wrote the migration 'should have known better,' I redirected: I asked what in our migration process would have caught this regardless of who wrote it. That reframing surfaced that we had no dry-run-against-a-production-snapshot step for migrations touching financial data. The action item was to require exactly that step for any migration touching the orders or payments schema, owned by our platform lead, with a two-week deadline. Three months later, a similarly risky migration was caught by that new dry-run step before it ever reached production, which is the clearest evidence the fix actually worked rather than just looking good on paper."

Trade-offs and pitfalls
The most common weak answer is one that's really about the technical debugging (what specifically was broken and how it was fixed) with almost nothing about facilitation, blamelessness, or follow-through, which misses what the question is actually probing. A close second is a story with no verifiable outcome at all, just 'we made a change and things got better,' with no way to check that claim; naming a concrete, checkable result is what separates a strong answer from a generic one.

Clarify scope & goals

• Rollback must be safe (no data corruption), support partial service rollbacks, minimize user impact, and allow fast recovery.

Framework / approach

1. Pre-rollout: runbook, automated health checks, canary + phased deploy, feature flags per feature, semantic versioning (v1/v2 endpoints), DB migration patterns (expand-contract).
2. Detection: aggregated SLO/alerting, request tracing, circuit-breaker metrics, smoke tests.
3. Action matrix: map failure modes → prescribed action (feature-flag-off, partial service rollback, DB migration rollback).

Core mechanisms

• Orchestrated versioning: run multiple versions side-by-side behind API gateway with traffic-splitting; use compatibility contracts and backward-compatible API changes.
• Partial rollbacks: deploy rollback per service using CI/CD with dependency graph to ensure safe order (downstream first for consumer-safe rollback).
• Feature flags: kill-switch flags for user-visible features; use progressive flags (per-user, per-region) to limit blast radius.
• Circuit-breakers & bulkheads: short-circuit calls to failing services; degrade gracefully and fail open/closed as appropriate.
• Data compatibility: write-forward, read-backwards migrations; use migration toggles and reversible schema changes; snapshot backups before schema changes.

Coordination & communication

• Incident commander (IC) role + service owners on war room; clear runbook steps and single source of truth (status dashboard).
• Pre-agreed change windows and rollback authority matrix.
• Staged commands via CI/CD with automated gating; only IC triggers cross-service rollback choreography.
• Post-mortem with action items (test coverage, stronger contracts, automation).

Avoid cascading failures

• Throttle cross-service calls, reduce traffic via gateway, enact circuit-breakers, and rollback non-critical services first; validate with end-to-end smoke tests before full traffic restoration.

Direct answer

Reducing implicit rewards for firefighting and last-minute heroics requires changing what actually gets recognized and evaluated, since as long as visible, dramatic saves are what get noticed and rewarded, quieter, more sustainable practices (careful planning, early risk-flagging, boring reliable delivery) will keep losing out by comparison, regardless of what the team says it values.

Structured elaboration

1. Change what gets highlighted in visible recognition. If team updates and performance conversations mostly mention who saved the day during a crisis, start deliberately and visibly calling out the quieter wins too: the engineer who caught a risk early enough that it never became a crisis, the person whose thorough planning meant no last-minute scramble was needed. Recognition is a signal about what the team actually values, regardless of stated policy.
2. Adjust performance review criteria explicitly. If performance narratives implicitly reward "went above and beyond during the outage," add explicit criteria that reward prevention and sustainable delivery just as visibly, so the review process itself does not quietly keep reinforcing hero behavior even after the recognition practices change.
3. Address the root causes that create the need for heroics in the first place. Hero culture often persists because of a genuine underlying problem, chronic understaffing, unrealistic deadlines, or fragile systems that require firefighting to keep running; changing recognition alone without addressing why fires keep starting will not fully solve it.
4. Model the change from leadership visibly. If a leader continues to publicly praise a specific dramatic save while sustainable work goes unmentioned, the stated policy change will not be believed; leadership's own reaction in the moment carries more weight than a stated values change.
5. Change the incentive structure itself, not just recognition and reviews. Adjust what counts toward a bonus or promotion case so prevention and reliability work credits the same as a visible incident save, for example explicitly including "reduced incident frequency for owned systems" as a promotion-packet bullet alongside "resolved a major incident." Rework on-call compensation so quiet, uneventful coverage is paid the same as an eventful shift, instead of implicitly rewarding drama through extra visibility or overtime pay that only kicks in once something breaks. Set a team-level OKR that includes a leading, prevention-oriented metric (near-miss catch rate, or reduction in repeat-incident categories) with real weight in how the team's quarter is judged, not just a lagging uptime number that only moves after a fire.

Worked example

A team's monthly update has historically celebrated whoever pulled a late-night save during an incident, while the engineer who redesigned a fragile system to prevent that class of incident entirely goes unmentioned. The team lead changes the update format to explicitly include a "prevented problem of the month" section alongside any genuine incident response, and brings this up directly in the next performance-review cycle as an equally weighted category. Over a couple of quarters, incident frequency for that system drops, and the team lead is deliberate about connecting that drop publicly to the preventive work, not just noting it as a lucky quiet month.

Trade-offs and pitfalls

The main pitfall is changing recognition language without changing the underlying performance-review criteria, which leaves the more consequential signal (what actually affects someone's rating and career) still implicitly rewarding heroics. A second pitfall is swinging too far the other way and failing to recognize genuine, necessary crisis response when it does happen, which can make people feel that stepping up in a real emergency is unappreciated; the goal is rebalancing, not eliminating recognition for real incident response.

Direct answer

I would refuse to ship anything that puts the client's data, access or legal standing at risk in a way that cannot be undone. Everything else about the release (breadth of features, polish, performance tuning, convenience tooling) is negotiable, and I would cut those to protect the date. In plain terms: scope is the lever I pull, the compliance floor is not.

How I decide which controls are negotiable

A control is a safeguard that prevents or detects a failure (for example, who can read customer data, or whether actions are logged). I put each one through three questions:

1. Is it contractually or legally required for this client? If the contract or the regulator says it must exist at go-live, it is not negotiable. Ask the compliance owner, not the engineers, to confirm the exact list.
2. Is the failure reversible? Borrowing the "one-way door vs two-way door" idea from Jeff Bezos's 2015 shareholder letter: a leaked record or a missing audit trail cannot be undone, so it is a one-way door. A slow report can be fixed next sprint, so it is a two-way door.
3. Can an interim safeguard cover the gap? For example, a manual review by a named person for two weeks, or a smaller pilot population, can stand in for an automated control if it is written down and time-boxed (it has a fixed end date). Such a stand-in is an interim control.

Resulting line (what I would draw)

Justifying it to speed-focused stakeholders

I do not argue "security matters." I price it: a failed audit or breach at a regulated client risks the contract itself, which is larger than three weeks of schedule. Illustration: if the contract is worth $1.2M a year, that is about $23k a week, so three weeks of delay costs roughly $69k. Even a 10% chance of losing the contract is worth $120k, before any penalty or remediation work, so the delay is the cheaper risk. Then I offer them speed where it is cheap: "Here is what we can still ship on day 21, here is what lands in the following two weeks, and here is the one thing that would move the date." I ask for a named executive to accept any residual risk (the risk left after controls are in place) in writing, which also tells me quickly whether the risk is really acceptable.

What would change my call

If the client's compliance contact confirms in writing that an item is not required at go-live, or an interim control satisfies their auditor, I would move that item to the deferred list.

Direct answer

I track a mix of leading indicators I can observe soon and lagging outcome indicators that take months, and I treat any single outcome metric with real suspicion, because most of the obvious ones have confounders that have nothing to do with the mentoring itself. If it isn't working, the signal usually shows up in behavior long before it ever shows up in an outcome number.

Leading indicators (fast, but softer)

• The mentee proactively brings a problem before being asked, rather than only responding when prompted.
• They apply a technique from an earlier conversation without being reminded.
• They can articulate their own reasoning, not just repeat a conclusion.
• They start contributing to others, a strong late signal that something has actually been internalized rather than just followed along with.

Lagging indicators, and why they alone are not enough

Promotion, retention, and performance rating movement all matter, but none of them are clean measures of mentoring on their own. Promotion timing is affected by team budget, level-bar changes, and reviewer variance, not just capability growth. Retention is affected by pay, personal circumstances, and the direct manager relationship, often far more than by a mentoring relationship. Treating either as a dashboard number risks giving mentoring false credit when someone would have succeeded anyway, or false blame when the real cause was entirely outside the relationship. That's the reason to pair outcome numbers with direct, harder-to-fake behavioral signals rather than reporting them alone.

Telling it isn't working, and what to do

Signs it's not working: no observable change in independence over a reasonable window, the mentee still routes every decision through you, flat or disengaged body language in 1:1s, or the mentee saying directly that it isn't useful. Once suspected: ask directly rather than only inferring from behavior, check for a format mismatch (wrong cadence, wrong topics, or the mentee not feeling safe raising what's actually going on), adjust before assuming failure, and if the mismatch is genuinely personal rather than fixable, consider a different pairing without treating that as anyone's fault.

Worked example

After several weeks, a mentee was still checking in before making small, reversible decisions that should have been theirs to make. Rather than assuming a skill gap, a direct conversation surfaced that the actual blocker was fear of being wrong, not lack of ability. The adjustment was explicit permission to make a defined class of reversible decisions without approval, plus a standing offer to review the reasoning after the fact rather than before. Over the following sessions, they started making more of those calls on their own and explaining the reasoning unprompted.

Trade-offs and pitfalls

A junior answer to this question is usually a list of KPIs and stops there. A stronger answer explains why the obvious outcome metrics can lie, and pairs them with behavioral signals that are harder to fake. A common pitfall is over-attributing outcome metrics to the mentoring relationship (selection bias: motivated people who get assigned strong mentors were often already on a good trajectory). Another is waiting too long to check in because outcome metrics take a quarter or more to move, by which point a struggling relationship may have already quietly failed.

Direct answer
Most large employers that codify their interview values name broadly similar underlying traits, even when their specific vocabulary differs: a customer or user-first orientation, taking ownership beyond a narrow scope, moving with appropriate urgency, holding a high quality bar, and being trustworthy and transparent recur across nearly every published framework, just under different labels.

Structured elaboration

Worked example
The table above is itself the worked example. A strong candidate should be able to reproduce a table like this from memory for whichever specific company's list they are asked about, translating each of that company's named principles onto one of these five underlying traits, rather than treating an unfamiliar company's vocabulary as an entirely new set of ideas to learn from scratch.

Trade-offs and pitfalls
Treating every company's list as identical is itself a mistake; the values differ in emphasis, and in what is explicitly left off the list. A company whose published list omits any explicit ownership language may culturally deprioritize individual initiative in favor of process, for example, and that is worth noticing rather than flattening away. A candidate who can only speak the vocabulary of one company, fluent in one set of terms but unable to translate the same underlying trait into a different company's language, reads as having memorized rather than internalized the competencies involved.

Direct answer

Model the annual loss with and without a second provider, count only the outage hours the second provider can actually bypass, and compare the saving with its yearly cost. With the illustrative inputs below the second provider pays for itself in the middle case and loses money in the low case, so the answer depends on outage frequency, which I would measure before committing. The hardest inputs are the share of outages failover can truly bypass, the quality of failover, and the tail of outage duration.

The model

Variables: failover means switching traffic to the backup provider when the main one fails. The covered share is the portion of outages that are the processor's own fault and so can be bypassed. The recovered share is the portion of lost sales customers retry later. The failover gap is the minutes of loss while the switch happens.

loss now      = outages per year x mean hours x $200,000 x (1 - recovered share)
loss with 2nd = loss now x (1 - covered share) + failover gap loss
failover gap  = outages x covered share x failover hours x $200,000 x (1 - recovered share)

Outages from your own bugs or shared networks stay in the loss. Example of estimating covered share from data: if 24 months of logs show 5 outages (2.5 a year, between the mid and high cases) and 4 were the processor's own fault, covered share is 4 / 5 = 0.8. Better still, weight by outage hours, because the model multiplies hours: if the processor-caused outages were the short ones, the count share overstates what failover saves.

Run it (inputs illustrative: $90,000 a year to run plus $250,000 to build spread over 3 years)

cost_per_hour = 200_000

def annual_loss(outages, mean_hours, recovered):
    # recovered: share of lost sales that customers retry later and complete
    return outages * mean_hours * cost_per_hour * (1 - recovered)

def loss_with_second_provider(outages, hours, recovered, covered, failover_minutes):
    # covered: share of outages the second provider can bypass
    base = annual_loss(outages, hours, recovered)
    gap = outages * covered * (failover_minutes / 60) * cost_per_hour * (1 - recovered)
    return base, base * (1 - covered) + gap

second_cost = 90_000 + 250_000 / 3   # yearly run cost + build cost spread over 3 years
print(f"second provider annual cost ${second_cost:,.0f}")
cases = {
    "low":  (1.0, 1.0, 0.40, 0.70, 15),
    "mid":  (2.0, 1.5, 0.30, 0.80, 15),
    "high": (3.0, 2.5, 0.15, 0.90, 30),
}
for label, args in cases.items():
    base, after = loss_with_second_provider(*args)
    saving = base - after
    print(f"{label:5s} loss now ${base:>9,.0f}  after ${after:>9,.0f}  saving ${saving:>9,.0f}  net ${saving - second_cost:>10,.0f}")

second provider annual cost $173,333
low   loss now $  120,000  after $   57,000  saving $   63,000  net $  -110,333
mid   loss now $  420,000  after $  140,000  saving $  280,000  net $   106,667
high  loss now $1,275,000  after $  357,000  saving $  918,000  net $   744,667

Reading the result

Mid case: loss now is 2 x 1.5 x $200,000 x 0.7 = $420,000; the second provider removes $336,000 of it but failover time costs $56,000 of new loss, so the saving is $280,000 and the net is about $107,000 a year. In the low case the saving ($63,000) does not cover the cost ($173,333). In the high case the net is roughly $745,000.

Hardest inputs to estimate

1. Covered share: most outages are partly caused by things a second processor cannot fix (your own code, a shared bank or card network issue). Review incident history for cause.
2. Failover quality: code that has never run in production often fails. A second provider's approval rates (share of card payments it accepts), routing rules (which transactions go to which provider) and reconciliation (matching payments to the books) also matter.
3. Frequency and duration tail: a few years of status-page history is thin, and costly outages are long ones.
4. Recovered share: depends on checkout behaviour.

Decision

Gather 24 months of the processor's incident history and our own logs first, then reassess. If the mid case holds, I would fund the second provider, and rehearse failover quarterly so the covered share is a tested figure. Also check what the contract's service credits (refunds the provider owes for downtime) pay: they rarely cover lost sales. Accepting the dependency is rational only if low-case inputs are confirmed.

Pitfalls

Counting every outage hour as saved; ignoring the second provider's own failures and complexity cost.

Direct answer
My default is to build a temporary mitigation myself rather than wait, unless the vendor's ETA is both short and credible, because customer experience shouldn't depend on a timeline I don't control and can't verify. The key criteria are how reliable the vendor's own status communication has historically been, how cheap and low-risk a mitigation is to build, and whether building a mitigation might itself mask a vendor problem that needs to stay escalated.

Structured elaboration

• Assess the vendor's ETA credibility. Vendors are often optimistic about their own timelines; check their status page's track record, whether they've given a specific, committed time or a vague 'we're looking into it,' and weigh that against your own tolerance for continued impact.
• Assess mitigation cost and risk. A cheap, well-understood mitigation (a circuit breaker to fail fast instead of hanging, a cached fallback response, a degraded-but-functional mode) is usually worth building even for a short outage; a mitigation that requires new, untested code under time pressure carries its own risk and might not be worth it for a vendor issue expected to resolve in minutes.
• Don't let your mitigation hide a problem that still needs escalating. If you build a good enough fallback, make sure someone is still tracking and escalating the underlying vendor issue; a well-built mitigation can quietly make an important problem invisible to leadership or to the vendor relationship owner.
• Verify the vendor issue is what you think it is, not just assumed: check the vendor's own status page or reach out directly rather than purely inferring from your own symptoms, since 'looks like a vendor is down' and 'confirmed the vendor is down' warrant different confidence levels.

Worked example
A third-party payment processor starts intermittently failing, causing checkout errors for a subset of users. The vendor's status page shows 'investigating' with no ETA, and their historical incidents have often run longer than initially communicated. The team decides not to wait: they add a circuit breaker so failing calls fail fast rather than hanging and degrading the whole checkout flow, and enable a secondary, lower-priority payment path they'd already built for exactly this kind of situation. They keep the primary vendor issue actively tracked and continue monitoring the vendor's status page, so once the vendor recovers they can cleanly revert to the primary path, rather than letting the fallback silently become permanent.

Trade-offs and pitfalls
Building a mitigation under pressure risks shipping throwaway code that never gets properly cleaned up and becomes unplanned permanent technical debt; it's worth explicitly flagging a mitigation as temporary and following up after the incident. Waiting on a vendor whose communicated ETA turns out to be optimistic (vendors very often are) means your customers experience longer impact than necessary, purely because you trusted someone else's timeline you had no way to verify. The same underlying judgment applies whether the failing dependency is a payment processor, a cloud provider's specific service, or a network transit provider throttling traffic to a region: the calibration is always about ETA credibility versus mitigation cost, not about the specific vendor.