Amazon promotes the document that makes next-level judgment obvious, not the engineer who lists the most tickets. A credible SDE3 brag doc proves scope, mechanism, and repeatable influence across roughly the last 2 quarters, not isolated heroics. If your draft reads like a task log, it is already losing.
TL;DR
Amazon promotes the document that makes next-level judgment obvious, not the engineer who lists the most tickets. A credible SDE3 brag doc proves scope, mechanism, and repeatable influence across roughly the last 2 quarters, not isolated heroics. If your draft reads like a task log, it is already losing.
Wondering what the scoring rubric actually looks like? The 0→1 SWE Interview Playbook (2026 Edition) breaks down 50+ real scenarios with frameworks and sample answers.
Who This Is For
This is for an SDE2 or equivalent engineer who already owns a real system, has shipped across at least one planning cycle, and needs a promotion case that survives calibration, not just a manager’s goodwill. It is not for someone looking for motivational copy or a way to decorate ordinary execution. The reader is usually strong on raw output and weak on narrative control.
What does Amazon actually want in an SDE3 brag doc?
Amazon wants proof that you are operating one level above your current badge, not proof that you are busy. In the room, the question is never whether you worked hard. The question is whether you repeatedly made better decisions at broader scope than your current level suggests.
In one Q3 debrief I sat through, the manager cut off the project timeline after two minutes and asked, “Who changed behavior because of this work?” That was the real test. The packet that survived showed adoption, decision influence, and failure recovery. The packet that died was full of task descriptions, Jira closure, and adjective-heavy praise.
Not a work diary, but a selection algorithm. Not self-expression, but calibration evidence. Not technical cleverness, but technical judgment under ambiguity. Reviewers mentally map the packet to Amazon’s leadership principles whether the document names them or not, especially ownership, dive deep, earn trust, deliver results, and hire and develop the best.
The deeper point is organizational psychology. Promotion packets are read as risk documents. Reviewers are not trying to admire you. They are trying to decide whether the company can safely assign you larger problems without supervision. If your evidence does not reduce that risk, it does not matter how polished the prose is.
> 📖 Related: Apple PM vs Amazon PM: RSU Vesting Schedule Differences and Total Comp Impact
How should I structure the brag doc so it gets read fast?
A good SDE3 brag doc is short enough to scan and dense enough to defend. In practice, the strongest ones read like a decision memo: one thesis, three to five proof sections, and an evidence appendix. If the reviewer has to hunt for the case, the case is weak.
The template should look more like a calibration file than a retrospective. Start with a two-sentence thesis that says what level you are already operating at and why. Then add a current-scope section, three impact stories, a leadership-principles mapping, and an evidence appendix with links to design docs, launch notes, incident writeups, and peer feedback. If you have eight stories, you probably do not have a focused case.
In a real promo discussion, nobody rewarded elegant prose. They rewarded a packet that made the answer obvious in under five minutes. The strongest docs had a blunt top line like: “I led the redesign of X, reduced Y, and became the decision point for Z.” Then they proved it with receipts. That is the pattern. Not a chronology, but a case file.
Another useful split is between what you did and what changed after you did it. The first is activity. The second is leverage. Amazon cares about leverage because higher levels are expected to change the operating shape of the team, not just keep shipping. A packet that only lists deliverables usually describes a solid L5. A packet that shows a changed system starts to sound like L6.
What evidence actually counts for SDE3?
Evidence that shows repeated leverage counts; screenshots of hard work do not. The packet should include shipped outcomes, architecture decisions, incidents you resolved, and visible moments where other engineers or partner teams changed direction because of your judgment. The bar is not activity. The bar is influence.
In a senior engineer debrief, the conversation usually turns when someone can point to a design review, an oncall incident, or a migration where the candidate became the person others trusted when tradeoffs were ugly. A single impressive launch can help. Two or three examples of the same judgment pattern change the argument. Reviewers are looking for a pattern, not a highlight reel.
The best evidence usually comes in four forms. First, durable artifacts: design docs, RFCs, launch reviews, postmortems. Second, behavioral evidence: peer feedback, skip-level feedback, partner comments. Third, operational evidence: fewer pages, lower manual load, faster recovery, fewer reversals. Fourth, decision evidence: a case where you changed the default path and others followed. If the claim only exists in your manager’s memory, it does not count.
Not “I owned the service,” but “I changed how the service is run.” Not “I mentored someone once,” but “I raised the team’s operating standard and the result is durable.” Not “I fixed a bug,” but “I turned a recurring failure into a mechanism.” This is the difference between output and operating level.
> 📖 Related: Amazon Forte vs 1on1 Cheatsheet for Performance Feedback: Which Wins?
How do I show scope without sounding inflated?
Scope should sound bounded, measurable, and consequential, not grand. A strong packet names the system, the owners, the time horizon, and the decision surface; then it shows how the scope expanded from one team to two teams, or from one service to a downstream chain. Inflated language makes reviewers suspicious because it hides where the actual leverage was.
In one manager conversation I watched, the candidate kept saying “cross-functional leadership” and the room stayed cold. The moment they translated that into “I aligned three teams, resolved one launch blocker, and changed the default architecture for the next two quarters,” the packet became legible. Reviewers do not reward altitude by itself. They reward altitude with contact points.
The trap is pretending that bigger nouns equal bigger scope. Not “platform transformation,” but the specific system boundary you changed. Not “strategic influence,” but the decision that would have gone the other way without your intervention. Not “big impact,” but impact that survives after you leave the room.
There is also a timing issue most engineers miss. S3-level scope at Amazon is usually not a single heroic month. It is repeated ownership over a full planning cycle, often 2 quarters, where your decisions keep showing up in downstream work. If your evidence is compressed into one fire drill, reviewers read it as luck, not level.
What breaks an SDE3 promo packet in calibration?
The packet usually fails when it proves competence instead of next-level ownership. Calibration rooms are skeptical by design; a clean execution story is not enough unless it shows judgment, force multiplication, and durability. If the doc reads like performance review prose, it is already too soft.
The most common failure is over-indexing on heroic execution. I have seen packets full of late-night saves and launch fire-fighting get cut because they described rescue work, not leverage work. Amazon does not promote insomnia. It promotes people who prevent the next incident, shape the system, or raise the bar for others.
Another failure is mismatch between story and evidence. If the manager says “strong scope” but the appendix only has self-written summaries and no durable artifacts, the room goes quiet. Reviewers can smell borrowed confidence. They trust decisions more than claims, and they trust externally visible mechanisms more than praise.
The psychological dynamic matters. In calibration, one weak story can poison the entire case because reviewers anchor on the weakest claim, not the strongest one. That is why the doc needs consistency across stories. Not one brilliant project surrounded by fog, but several examples that all point to the same level of judgment. Consistency beats intensity.
Preparation Checklist
The packet gets stronger when the evidence is assembled before the prose.
- Reconstruct the last 2 quarters into a single timeline and mark the 3 decisions that had the most leverage.
- Pull 3 artifacts per major project: the design note, the launch or incident writeup, and one external piece of feedback.
- Map each claim to a leadership principle, but only where the principle is actually visible in the work.
- Rewrite every vague claim into before/after language, with the system boundary, the owner group, and the downstream change.
- Cut anything that only proves effort. If it does not show judgment, impact, or repeatable influence, it is noise.
- Ask your manager one direct question: “What in this packet still looks like strong L5, not clear S3?”
- Work through a structured preparation system (the PM Interview Playbook covers promotion narratives, evidence selection, and debrief-style rebuttals with real examples) so the packet does not collapse under the first skeptical read.
Mistakes to Avoid
The common failures are inflation, vagueness, and the wrong evidence.
- BAD: “Led a critical cross-functional initiative that improved the platform.”
GOOD: “Aligned three teams on a new retry policy, removed a recurring oncall escalation path, and made the default safer for the next 2 releases.”
- BAD: “Built a scalable system and showed strong leadership.”
GOOD: “Changed the service contract so two downstream teams stopped hand-rolling workarounds, then documented the pattern so the team could reuse it.”
- BAD: “Mentored junior engineers and helped the team.”
GOOD: “Got two engineers to independent ownership on the same subsystem and changed review expectations so the team now catches the same class of defects earlier.”
The judgment behind these examples is simple. Bad examples describe status. Good examples describe changed behavior. Amazon promotion packets are not scored on how flattering they sound. They are scored on whether they make a higher-level operating pattern undeniable.
FAQ
- Should I write the brag doc myself or let my manager do it?
You should own it. If your manager writes the whole thing, the packet usually sounds generic and second-hand. The manager should sharpen the case, not invent it. The best outcome is when your language is precise enough that your manager only has to cut weakness, not manufacture substance.
- How long should the doc be?
Shorter than you think. A usable packet usually has a one-page thesis, 3 to 5 proof sections, and a compact evidence appendix. If it stretches because you keep adding stories, you have not found the case yet. You have found your workload.
- What if most of my work is invisible operational work?
Then make the mechanism visible. Invisible work can still support promotion if you show what stopped breaking, what became repeatable, and who now depends on your judgment. If you cannot connect the work to a durable change, the packet will read as maintenance, not SDE3 scope.
Ready to build a real interview prep system?
Get the full PM Interview Prep System →
The book is also available on Amazon Kindle.