Amazon SDE onboarding and first 90 days tips 2026

The first 90 days as an Amazon SDE are not about coding fast — they’re about learning the machine. New hires who survive and thrive align with the operational tempo of their team, internalize the 14 Leadership Principles in practice, and ship small wins early. Most fail not from technical gaps, but

Title: Amazon SDE Onboarding and First 90 Days Tips 2026

TL;DR

Who This Is For

This is for new Amazon SDEs who have signed an offer or just started, particularly L4 and L5 hires from outside Big Tech. It’s not for interns or L3s. You’re likely transitioning from a slower-moving company or a non-AWS org, and you need to compress six months of ramp time into 90 days. If you’re at L6 or above, your onboarding is custom and political — this isn’t for you.

What happens during Amazon SDE onboarding (Weeks 0–2)?

Onboarding starts before day one with mandatory compliance training, but real onboarding begins in Week 1 with the “Bar Raiser Bootcamp” and team immersion. You’ll attend 8–10 hours of structured sessions on AWS fundamentals, internal tooling (like CodeArtifact and CodeBuild), and security protocols. The rest is unstructured: setting up your development environment, reading service docs, and scheduling 1:1s.

Not mastery, but pattern recognition — that’s what Week 1 evaluates. In a Q3 2025 onboarding review, a new SDE was flagged not because he struggled with IAM roles, but because he didn’t map dependencies across services by Day 5. The team lead noted: “He asked for help, but never connected the dots between S3, Lambda, and EventBridge — that’s the real test.”

Leadership Principles are embedded in onboarding exercises. You’ll write a short retrospective using “Learn and Be Curious” and “Insist on the Highest Standards.” These aren’t ceremonial. They get filed and referenced in your first performance calibration.

You are not expected to ship code in Week 1. But you are expected to submit a “first hypothesis” — a one-page doc proposing a small improvement to an existing workflow, even if it’s just reducing log verbosity. No doc = no credibility.

> 📖 Related: Amazon Tpm System Design Interview Examples

How do I ramp up fast on my team’s codebase (Weeks 3–6)?

Speed on the codebase is not about reading code — it’s about identifying leverage points. Most SDEs waste Week 3 reading top to bottom. The top performers start with the deployment pipeline and monitoring tools. They ask: “Where do alerts fire? What breaks most often? What services are marked ‘critical tier’?”

In a 2024 HC meeting, a hiring manager killed a positive ramp-up review because the SDE had touched only greenfield features. “He avoided the legacy order processing service — the one with 40% of the p99 latency. That’s not ramping. That’s hiding.” The decision was overturned only after engineering leadership confirmed the SDE had no access — proving that excuse fails at Amazon. You’re expected to beg, borrow, or escalate for access.

Not contribution, but context — that’s the real ramp-up metric. You must deliver your first PR by Day 18, even if it’s a typo fix. More important: attach a “context diagram” to your first ticket — a hand-drawn or Mermaid.js flow showing how your change touches adjacent services. This is not required in writing, but teams that do it get promoted faster.

Use Chime status strategically. Set it to “In Deep Work” from 9–11AM and 2–4PM. That’s when senior engineers are most likely to leave you alone — and when production issues least often erupt. You need uninterrupted time to run local tests.

The best rampers ship three types of work by Week 6:

One bug fix (even if small)
One monitoring alert improvement
One documentation update that someone else uses

If you haven’t been paged yet, you’re not integrated.

How are Amazon SDEs evaluated in the first 90 days?

You are evaluated on three axes: delivery, judgment, and principle alignment — in that order. Delivery means shipping code that passes CI/CD and doesn’t roll back. Judgment means making calls without escalation — even if they’re wrong, as long as they’re principled. Principle alignment means your peers can map your decisions to at least two Leadership Principles.

In a Q1 2025 calibration, an SDE was rated “Meets Expectations” despite shipping five features because every decision went to the EM for approval. The bar raiser wrote: “No evidence of independent judgment. Relied on manager for trivial dependency choices.” That review delayed her vesting eligibility by six months.

Not output, but ownership — that’s what separates L4 from L5 ramp patterns. L4s track task completion. L5s track blast radius. One L5 in EC2 Networking preemptively ran a load test on his PR because “the last change to the subnet manager caused a regional outage.” He didn’t ship fastest — but his manager called it “the most mature first-month work I’ve seen.”

Peer feedback is collected at Day 30, 60, and 90. It’s not anonymous. Your teammates rate you on a five-point scale across four categories: technical contribution, communication, initiative, and principle application. Scores below 3.0 trigger remediation plans.

Your EM owns your final rating, but the bar raiser has veto power. If your ramp isn’t on track by Day 45, the bar raiser will schedule a 1:1 — which is a warning, not support.

What technical tools and systems should I master early?

Mastering the internal stack matters more than AWS certifications. By Day 21, you must be fluent in at least three of the following: CodeDeploy, CloudWatch Logs Insights, X-Ray, Step Functions, and the internal ticketing system (often Jira, but sometimes an Amazon-built tool like Talaria).

Not syntax, but speed — that’s the real benchmark. One SDE onboarding in AWS Lambda was praised not for writing clean code, but for reducing build time from 12 minutes to 3.5 by caching dependencies in S3. His EM cited it in the onboarding review as “immediate ROI.”

The undocumented tool you must learn is the “org graph” — a live, internal service that shows team dependencies, escalation paths, and who approves changes. It’s not taught in onboarding. You find it by asking: “Who owns the deployment gate for this service?” and following the chain.

Learn how to read canary metrics. Most outages start with a 2% error rate in the canary environment. If you’re not checking them daily, you’re not operational.

Use the internal “debug portal” — a search tool that correlates logs, traces, and alerts. Type in a request ID, and it shows you the full path across services. Engineers who use it in their first PR get labeled “high potential.”

One SDE in Prime Video reduced incident response time by 40% by building a lightweight CLI wrapper around the debug portal. He wasn’t asked to. He shipped it to his team Slack channel. It’s now used org-wide.

How do Amazon’s Leadership Principles apply in the first 90 days?

The Leadership Principles aren’t culture wallpaper — they’re evaluation criteria. “Earn Trust” means your peers believe your estimates. “Dive Deep” means you find the root cause, not the surface fix. “Bias for Action” means you deploy on Friday if the data supports it — even if others hesitate.

In a 2025 debrief, a new SDE was dinged on “Deliver Results” because he waited two weeks for a design review before starting work. The bar raiser wrote: “He could have prototyped in parallel. Bias for Action isn’t ‘act recklessly’ — it’s ‘act with intent.’”

Not adherence, but translation — that’s what matters. You don’t just follow principles — you reframe problems using them. When a service was missing SLA reports, one SDE didn’t file a ticket. He built a dashboard using CloudWatch and linked it in the team’s standup doc. His manager wrote: “That’s ‘Ownership’ and ‘Invent and Simplify’ in action.”

You will be asked to self-assess using the principles at Day 30 and Day 60. Vague answers like “I showed Customer Obsession by writing good code” fail. Specifics win: “I added retry logic to the checkout API after seeing 12% of mobile users drop during peak latency — that’s Customer Obsession.”

The principle that sinks most new hires is “Are Right, A Lot.” You’re not expected to be right 100% of the time. But you must show a pattern of learning from being wrong. One SDE who misdiagnosed a database deadlock was still rated “Exceeds” because his postmortem included a new monitoring rule that caught two similar issues in the next month.

Preparation Checklist

Complete all pre-day-one compliance and security training modules — Amazon tracks completion time, and delays raise red flags.
Set up your development environment by Day 0 — including CLI access, SSH keys, and internal DNS resolution.
Schedule 1:1s with your EM, tech lead, and peer mentor within 48 hours of joining.
Read the last three postmortems for your team’s critical services — annotate them with one improvement idea each.
Write and share a “ramp plan” by Day 3 — a one-pager listing your learning goals, first PR target, and knowledge gaps.
Attend at least two “tech talks” from adjacent teams by Week 4 — these are intelligence-gathering opportunities.
Work through a structured preparation system (the PM Interview Playbook covers Amazon’s operational rhythms and Leadership Principle applications with real debrief examples).

Mistakes to Avoid

BAD: Waiting for permission to access production logs. One SDE at AWS Analytics waited 10 days to request Kibana access. His EM noted: “He treated access as a privilege, not a necessity.”

GOOD: Escalating to your tech lead on Day 2 with a written justification for log access. Frame it as risk mitigation: “I can’t validate my changes without seeing the error patterns.”

BAD: Focusing only on feature work. A new SDE on Seller Central spent six weeks building a new UI component but never touched the order processing pipeline. He was labeled “not operationally ready” at 60 days.

GOOD: Shipping a tiny but impactful change in the first critical path service — even if it’s just adding a missing metric. Shows you understand what matters.

BAD: Citing Leadership Principles generically in your self-review. “I showed Ownership” with no example fails.

GOOD: Writing: “I took ownership of the deployment rollback when the CI pipeline failed — coordinated with SRE, documented the fix, and updated the runbook.” That’s evidence, not assertion.

FAQ

What salary range should I expect as an L4 SDE during onboarding?

L4 SDEs in 2026 typically receive $135K–$155K total compensation, including base, stock, and sign-on, based on Levels.fyi data from 120 verified reports. Location adjusts base pay — Seattle is $153K base, while Austin is $142K. Stock vests 5%/15%/40%/40% over four years. Your onboarding package is fixed — no negotiation after offer acceptance.

How many interview rounds does Amazon’s SDE process usually include?

Most external SDE hires go through four rounds: one recruiter screen, one technical phone interview, and two virtual on-site loops — each 45–60 minutes, with one coding session and one behavioral round. Some teams add a design round. The process averages 21 days from first call to offer. Glassdoor shows 68% of candidates report the process as “lengthy but fair.”

Where can I find official Amazon SDE career resources?

Amazon’s official careers page (amazon.jobs) lists all open SDE roles, team descriptions, and office locations. It includes sample interview questions and Leadership Principle guides. For internal tools and onboarding timelines, use the internal “SDE Ramp Hub” — accessible after day one. The public site doesn’t disclose team-specific metrics or promotion criteria.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.