Amazon Engineering Manager Interview Preparation Guide - Entry Level (0 years)

High-level summary
A robust implementation roadmap organizes work into phases, shows dependencies and the critical path, allocates resources, defines acceptance criteria, and embeds governance checkpoints. As an Engineering Manager I produce artifacts for each audience and keep the plan actionable.

Core roadmap sections & artifacts

• Phases & milestones: concept → design → build → test → launch → iter. Artifact: timeline/Gantt, milestone list.
• Sequencing & critical-path: dependency graph, critical-path analysis, key handoffs.
• Resource allocation: team assignments, capacity model, RACI matrix.
• Acceptance criteria: feature-level ACs, test plan, performance/SLOs.
• Governance & checkpoints: review gates, sign-offs, security/architecture reviews, go/no-go criteria.
• Risks & mitigation: risk register, contingency plan.
• Delivery artifacts: sprint backlog, tech design docs, CI/CD pipeline, runbooks, metrics dashboard.

Audience tailoring

• Engineers: detailed sprint plans, tickets, tech designs, API contracts, code owners.
• PMs/TPMs: feature roadmap, dependencies, delivery timeline, trade-offs, resourcing.
• Executives: one‑page roadmap, milestones, RAG status, top risks, asks (budget/headcount).

Why this works
Aligns expectations, exposes critical path, enables data-driven decisions and faster escalation when bottlenecks appear.

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

Psychological safety, in a mentoring relationship, is a mentee's confidence that they can ask a question, admit a mistake, or push back on something without it costing them standing or opportunity. It's built through small, consistent moments early on, and it's genuinely tested the first time the mentee takes a visible risk and sees how you respond.

Concrete early actions

• Name failure modes yourself first. Mentioning a mistake you made in a similar situation signals that admitting error is normal here, not a one-way expectation.
• Model uncertainty openly. Say "I don't know, let's find out" instead of bluffing, so not-knowing reads as acceptable.
• Treat early mistakes as expected, not exceptional. React to a mistake by focusing on the fix and what it reveals, not on assigning blame.
• Be consistent between casual moments and anything formal. If private conversations are open but a formal review contradicts them, trust breaks immediately.
• Give credit publicly, give hard feedback privately. This is the pattern most people are watching for even if they never say so.
• Agree explicitly that disagreement is welcome, and actually respond well the first time it happens.

Worked example

Early in a relationship, a mentee admitted they'd made a mistake that caused some rework. The response focused entirely on understanding what happened and fixing it, walking through the reasoning openly rather than assigning blame, and treating it as a useful, expected part of learning. In the sessions that followed, the mentee started surfacing problems earlier and asking more pointed questions, rather than waiting until something couldn't be hidden.

Trade-offs and pitfalls

A common mistake is treating psychological safety as a one-time opening statement ("feel free to ask me anything") rather than an ongoing pattern that has to survive contact with a real mistake. The mentee will judge safety retrospectively, based on what actually happened the first time they took a risk, not on what was said at the start. It's also worth not confusing psychological safety with lowered standards: it's about how failure is handled and discussed, not about removing accountability for the work.

There's a menu of lightweight ways to de-risk an ambiguous ask, and the named ones (a spike or POC, a scoped ticket built on stated assumptions, deferral, a quick prototype) aren't the whole list; techniques like a fake-door test, a Wizard-of-Oz stand-in, a small pilot, or simply looking at data you already have all belong on the same menu. The skill isn't memorizing the menu, it's matching the technique to what kind of ambiguity you actually have, and then keeping whatever you pick from quietly turning into the real build.

Match the technique to the unknown.

• If you don't know whether the question is even still open: check data you already have first, always, before building anything new. Support tickets, existing analytics, a past retrospective; this costs close to nothing and sometimes the question is already answered.
• If the unknown is demand (will anyone want this): a fake-door test, a button, link, or landing page for something that doesn't exist yet, measuring click-through, tells you demand without building the thing.
• If the unknown is the shape of the interaction, not whether people want it: a Wizard-of-Oz stand-in, a human manually doing what the automation would eventually do, tests the experience without building the automation, which is usually the expensive part.
• If the unknown is technical feasibility, can this even be built the way we're imagining: a timeboxed spike or proof of concept.
• If the ambiguity is small and low-stakes: skip the experiment entirely, write a scoped ticket on a stated assumption, get a quick nod from whoever owns the area, and move.
• If you need real usage signal at modest scale before deciding to go further: a small pilot.
• If the cost of being wrong is low and nobody is actually blocked waiting on you: defer, explicitly, rather than spending effort now.

How you know a lightweight prototype is enough, and don't need something bigger. Three signals: the decision is reversible and low blast radius if you're wrong, the disagreement is about one narrow factual question rather than a whole strategic direction, and a small number of examples or users would plausibly settle it either way. If any of those isn't true, for example the decision is expensive to undo, escalate to a bigger test rather than trusting a five-user prototype.

If it succeeds, what you hand to engineering isn't the throwaway code, it's a one-page brief: the assumption that got validated, the specific approach that worked, the known limitations the prototype deliberately skipped (auth, scale, error states), and a link to the throwaway artifact clearly labeled "not production," so engineering rebuilds the thing properly instead of hardening code that was never meant to survive contact with real load.

Keeping it bounded, in three dimensions.

• Time: a hard calendar boundary with a decision meeting already on the calendar, not "we'll know when we're done."
• Cost: a person-hour ceiling stated up front, for example one engineer for three days, 24 person-hours, and an explicit rule that production-grade requirements (auth, scaling, full error handling) are out of scope for this round.
• Scope: a written "won't do" list next to the "will do" list, and a rule that any request to expand scope becomes a separate, newly-approved ticket rather than silently absorbed into the current one.

Worked example. A PM has an ambiguous ask: would users want a saved-search alert feature. Retrospective check first: support tickets mentioning this over the last quarter are frequent but not conclusive enough to build on their own. Fake-door test: a "Get notified" button on the search results page for 2 weeks to 5% of traffic. Threshold set before launch: above 3% click-through, build it; below 1%, shelve it; between 1 and 3%, run one more cheap check. That check is Wizard-of-Oz: manually send a hand-built digest email to the people who clicked and see if they actually open and engage with a manual version before building the automated one.

A different discipline. An SRE has an ambiguous ask: would customers notice if a non-critical endpoint's data freshness degraded. Instead of building automated degradation logic, they Wizard-of-Oz it, manually holding one internal dashboard's data stale for a day and watching whether anyone notices or complains, before writing a single line of the real feature.

The trap: defaulting to the fanciest technique available, a full pilot or a real prototype, when five minutes checking data you already have would have answered the question. The opposite trap is just as real: using a spike to avoid ever writing an assumption down in a ticket and getting a quick answer, when the ambiguity was small enough that asking didn't need an experiment at all.

Approach (brief)
Balance short-term delivery and long-term capability by prioritizing hires that maximize immediate output while preserving options for platform and senior investment over six months.

Prioritized 6‑month hiring plan

1. Month 0–2: 2 Senior ICs (fastest shippers) — fill critical feature gaps to hit roadmap milestones.
2. Month 2–4: 1 Mid‑level IC + 1 Platform Engineer (part‑time or contract) — sustain delivery and start platform debt remediation.
3. Month 4–6: 1 Senior Engineer (hire window opens) + 1 Junior IC (ramp) — invest in long‑term leadership and capacity.

Rationale: early ICs unblock product velocity; platform work begins via contract to reduce upfront cost; senior hire later improves architecture and mentoring when cash flow and product clarity increase.

Risk mitigation

• Use 3‑6 month contracts for platform work to defer full headcount.
• Pair hiring with clear KPIs: cycle time, lead time, bug rate. Stop/accelerate hires based on metrics.
• Cross‑train team, document designs to reduce single‑point risks.
• Leverage internal promotions to reduce external senior hire costs.

This plan delivers immediate shipping capacity while staging senior/platform investment when impact and budget alignment are clearer.

Direct answer
Five Whys, fishbone (Ishikawa) diagrams, fault-tree analysis, and causal-chain or timeline analysis are all structured root-cause techniques, but they suit different incident shapes. Five Whys is fast and best for a single, mostly-linear chain of causation. Fishbone is best when you suspect several independent categories of cause (people, process, technology, environment) and want to brainstorm broadly before narrowing. Fault-tree analysis is best for complex, multi-path failures where you need to reason about combinations of conditions, not just one chain. Causal-chain or timeline analysis is best when the incident unfolded over a long period with many events, and reconstructing the sequence itself is most of the work.

Structured elaboration

• Five Whys. Strength: fast, requires no special tooling, good for straightforward incidents with a genuinely linear cause. Weakness: it forces a single narrative thread, so on an incident with multiple independent contributing factors it can stop at the first plausible-sounding chain and miss a second, unrelated gap that also mattered. Combining it with a causal-graph or fault-tree check on the resulting hypothesis (does this cause actually explain the full timeline, or just part of it) helps catch that failure mode.
• Fishbone (Ishikawa). Strength: structured brainstorming across categories (commonly people, process, technology, environment) surfaces candidates you might not think of starting from a single chain. Weakness: it's a divergent tool, good for generating hypotheses, but it doesn't by itself tell you which candidate cause is actually correct; you still need evidence to narrow down.
• Fault-tree analysis. Strength: models AND/OR combinations of conditions, so it's the right tool when the incident required several things to go wrong simultaneously (a database failover only failed because BOTH the standby was on an incompatible version AND the health check didn't catch the mismatch). Weakness: more effort and formalism than most incidents justify; overkill for a simple single-cause bug.
• Causal-chain or timeline analysis. Strength: best when the incident unfolded across many events over hours or days, and the real analytical work is establishing what happened when and in what order, which then makes the cause fairly evident once assembled. Weakness: doesn't add much analytical structure beyond reconstruction; you often still need Five Whys or fishbone on top of the assembled timeline to go from 'here's what happened' to 'here's why.'

Worked example
A multi-hour cascading outage across several services: causal-chain or timeline analysis is the right first tool, since the priority is establishing the sequence across services before anything else makes sense. A single service crashing on a specific malformed input: Five Whys is fast and sufficient. A database failover that should have worked but didn't: fault-tree analysis, since it likely required more than one condition (incompatible standby version AND a health check that didn't catch it) to align. A vague, hard-to-pin-down data-quality issue with no obvious single trigger: fishbone, to broadly brainstorm across categories (was it the data source, the pipeline code, a schema change, an environment difference) before narrowing with evidence.

Trade-offs and pitfalls
The most common mistake is defaulting to Five Whys for everything because it's the most familiar technique, even on incidents with multiple independent contributing factors where it will produce a tidy but incomplete story. Pick the technique to fit the shape of the incident, not out of habit, and don't hesitate to combine two (fishbone to generate candidates, then Five Whys or fault-tree to narrow and validate).

Structure & key contents of an ADR

• Title & ID — short descriptive name and sequential ID (e.g., ADR-2026-01).
• Status & Date — proposed | accepted | deprecated, with timestamps and author(s).
• Context — problem, constraints, stakeholders, relevant metrics.
• Decision — chosen option stated clearly.
• Rationale — pros/cons of considered alternatives and why decision chosen.
• Consequences & Trade-offs — technical, operational, cost, security, backward-compat.
• Implementation Plan & Owners — next steps, timeline, responsible engineers.
• Links & Traceability — related tickets, design docs, benchmarks, PRs.

Where ADRs live & process

• Stored in repo under /docs/adr/ as Markdown; each ADR is a file named by ID.
• PR-driven: create ADR via a PR, review in design review meeting, merge once approved.
• Link ADR in relevant epics, tickets, and release notes; CI checks that ADR metadata exists.

Keeping ADRs current

• Quarterly ADR review cadence + tie reviews to major refactors/releases.
• Use status updates via small PRs to change status to deprecated/updated with implementation links.
• Make ADR updates part of “definition of done” for significant architectural work.
• As EM I track outstanding ADRs in roadmap and surface them in tech review and 1:1s to ensure ownership.

Situation & goal (one line)
Design a repeatable benchmarking + cost-model to decide if CDN/edge caching reduces global API latency and network egress spend.

Key metrics to capture

• Latency: p95, p99, median, tail distribution, and DNS/TTFB breakdown
• Throughput: requests/sec and bytes/sec
• Cache effectiveness: hit rate, miss rate, stale-while-revalidate hits
• Egress volume: bytes served from origin vs edge (per-region)
• Cost metrics: $/GB egress origin, $/GB CDN transfer, CDN requests cost
• User impact: error rate, time-to-first-byte by client region

Traffic sampling & experiment design

• Canary traffic: 1%–5% of production routed through CDN per region initially
• A/B testing: split users by consistent hashing for 24–72 hours windows
• Synthetic tests: scripted requests (varying payloads, auth headers) from distributed probes (real user ASNs)
• Duration: 7–14 days to capture diurnal and weekly patterns
• Instrumentation: include request IDs, geo tags, and cache debug headers

Geographies to test

• Top 10 source regions by traffic and cost (e.g., US-east, US-west, EU, India, APAC, South America, Middle East)
• Add high-cost but low-volume outliers (e.g., Africa) if egress rates vary

Calculating expected egress savings

1. Measure baseline: origin_egress_bytes_region, origin_cost_rate_region
2. Measure CDN runs: edge_served_bytes_region, origin_bytes_after_cache_region, cdn_cost_rate_region, cdn_request_cost
3. Per-region savings:
   • bytes_saved_region = origin_egress_bytes_region - origin_bytes_after_cache_region
   • cost_saved_region = bytes_saved_region * origin_cost_rate_region
   • cdn_additional_cost_region = edge_served_bytes_region * cdn_cost_rate_region + request_count_region * cdn_request_cost
   • net_savings_region = cost_saved_region - cdn_additional_cost_region
4. Global net savings = sum(net_savings_region) — include fixed CDN fees amortized

Trade-offs & runbook

• Consider cacheability, auth/session headers, GDPR data locality, TLS termination, invalidation costs
• If net_savings positive and latency improves p95/p99 in key regions, roll out phased by region with monitoring thresholds (increase error rate or cache hit drop triggers rollback)

This framework balances technical validation and financial modeling for an informed go/no-go decision.

Direct answer

Designing a communication cadence across a stakeholder map means deciding, for each group, how often, through what channel, and at what level of detail they hear from you, based on where they sit on the map, and building in a clear trigger for moving someone between tracks rather than treating the initial assignment as permanent.

Structured elaboration

1. Tie cadence to the stakeholder's actual position, not a one-size-fits-all schedule. An executive sponsor track might get a concise monthly summary focused on outcomes and risk; a working-team track might get detailed weekly updates focused on progress and blockers.
2. Match format to the audience's real need, not just frequency. The executive track likely wants a short written summary they can read in two minutes; the working-team track likely benefits from a live discussion where questions can surface in real time.
3. Define explicit triggers for moving someone between tracks. A stakeholder whose interest or power shifts (a reorg, a new deadline that suddenly involves them, an escalation) should move tracks based on a stated trigger, not be forgotten in whichever track they started in.
4. Build in a feedback loop. Periodically checking whether the cadence still fits (are executive-track people asking for more detail than the summary provides, are working-team members feeling over-communicated to) catches drift before it becomes disengagement.

Worked example

An executive sponsor track for a multi-quarter initiative gets a one-page monthly summary focused on milestones hit, risks, and decisions needed from them specifically; the working-team track gets a weekly quarter-hour sync focused on blockers and near-term work. When a scope change suddenly makes a previously executive-track stakeholder need working-level detail (because their team now owns a piece of execution), they move to the working-team track with an explicit note on why, rather than continuing to receive only the high-level monthly summary that no longer serves their actual need.

Trade-offs and pitfalls

Too many tracks becomes as unmanageable as no structure at all; two or three clear tracks, each with an explicit trigger for movement between them, is usually enough, and adding more granularity than that mostly adds overhead without improving anyone's actual experience.

Explain RICE (brief)

• Reach — how many users/events will be affected in a given time window (e.g., monthly active users, % of API calls).
• Impact — the change in outcome per user (often on a relative scale: 0.25, 0.5, 1, 2) — how much value it delivers.
• Confidence — how sure we are about reach and impact estimates (0–100%); lowers score when assumptions are uncertain.
• Effort — total team time required (person-months or “sprint-weeks”); higher effort reduces priority.

Score = (Reach × Impact × Confidence) / Effort — higher is better.

Concrete EM example

Situation: We must choose between a one-day bugfix that prevents occasional UI freezes for 10% of users, vs. a 3-sprint platform investment to refactor our queueing layer to improve throughput for future scale.

Action: I estimate:

• Bugfix: Reach = 10k MAUs (10%), Impact = 0.5 (reduced frustration), Confidence = 90%, Effort = 0.1 sprint → RICE ≈ (10k × 0.5 × 0.9)/0.1 = high.
• Platform: Reach = 100k MAUs (all users eventually), Impact = 1.5 (throughput/reliability), Confidence = 60% (unknown edge cases), Effort = 6 sprints → RICE ≈ (100k × 1.5 × 0.6)/6 = moderate.

Result: Bugfix yields much higher short-term RICE per effort, so I prioritize it immediately to reduce user pain and unblock metrics. I schedule the platform work as a planned multi-sprint project with milestones, additional validation to raise Confidence, and stakeholder alignment.

Why this helps: RICE forces quantification of user value, uncertainty, and cost — letting me balance immediate user impact against longer-term strategic investments while communicating trade-offs to PMs and execs.