Senior Software Engineer Guide (L5 / IC5) (2026)

What senior SWE actually does day-to-day

From Google's leveling (rework.withgoogle.com), Meta's published prep guide, Stripe's engineering essays, and Will Larson's StaffEng senior-engineer track:

• Own technical direction for a feature area or service. Not just executing on what someone else designed — making the design call when it matters and owning the consequences.
• Drive cross-team decisions. Architecture, dependencies, migration planning, deprecations. You're the engineer who leads the conversation when two teams need to align.
• Partner with product directly. What to build, when to build it, what 'good' looks like. Senior-level product partnership is bilateral — you push back on requirements that don't make engineering sense; you advocate for engineering investment that doesn't have product visibility.
• Mentor mid and junior engineers without a manager title. Pair-programming, design review, advocacy in calibration discussions. The senior bar is 'mentored a junior to mid-promotion'; multiple of these accumulate the staff case.
• Own outcomes at the team or area level. System reliability, feature impact, code quality. You're accountable when things break in your area; you're credited when they ship cleanly.

The structural shift from mid to senior: at mid, you scope your own work and your manager reviews. At senior, you scope work for yourself and others, set technical direction for an area, and your manager works with you as a peer in technical conversations.

A real senior project: walkthrough with the senior-bar artifacts

Worked example of what a senior-bar project looks like — anonymized but real-shape, derived from leaked promo packets and StaffEng case studies. Reading this is more useful than reading abstract leveling rubrics.

Project: 'Migrate from synchronous to asynchronous payment processing for the checkout flow.'

Phase 1 — Problem framing (week 1).

The synchronous payment processing path was a known reliability risk: when our payment provider's API was slow, /checkout p99 latency spiked, and the user experience degraded. The team had been aware of this for years; nobody had owned the migration.

I proposed taking it on, scoped to a single quarter. Got buy-in from my manager and the product partner. Wrote a one-page problem brief: current state, risks, opportunity, rough scope. Reviewed with the engineering manager and the senior+ engineers in the area.

Phase 2 — Design doc (weeks 2-3).

Wrote a 6-page design doc covering:

• Current architecture (synchronous, with pseudocode of the failure mode).
• Proposed architecture (queue-based async with idempotency keys, dual-write during migration).
• Trade-offs analyzed: kafka vs SQS vs in-house queue; eventual consistency tolerance for charge confirmation; user experience impact.
• Migration plan: dual-write phase, shadow-traffic phase, cutover, decommission.
• Failure modes: what happens if the queue backs up; what happens if a charge confirmation never arrives; what happens during cutover.
• Rollback plan: how to revert at each phase if metrics degrade.

Reviewed with three senior engineers and the team's staff engineer. Iterated based on their feedback for two weeks. Got formal sign-off.

Phase 3 — Implementation (weeks 4-9).

Implemented dual-write phase: every charge written to both the old synchronous path and the new async pipeline, with reconciliation logic. Ran for 3 weeks; reconciliation showed 100% match. Mentored a mid-level engineer (Alice) who owned the reconciliation tooling — she shipped that surface end-to-end.

Shadow-traffic phase: 1% → 10% → 50% → 90% of traffic served from the async path with the sync path as fallback. Each step ran for 3-7 days; metrics dashboard tracked p99 latency, error rate, charge-confirmation lag.

Phase 4 — Cutover and decommission (weeks 10-12).

Cutover to 100% async; sync path remained as standby for one week. Decommissioned sync path on schedule. Wrote a runbook for the new async pipeline; on-call team trained.

Outcome:

• /checkout p99 latency: 320ms → 110ms.
• Failed charges due to provider slowness: 0.4% → 0.01%.
• On-call pages tied to checkout latency: 12/month → 1/month.
• Migration completed in 12 weeks vs 16 originally scoped.

What makes this a senior-bar project:

1. I generated the scope (proposed it; nobody assigned it).
2. I owned the design doc end-to-end with senior+ review.
3. I drove cross-team coordination (product partner, on-call team, two adjacent service teams).
4. I mentored a mid-level engineer to ship a substantive piece.
5. Measurable outcomes with specific numbers.
6. Honest about timeline (came in under estimate; named it).
7. Failure modes explicit (the design doc had them; the cutover plan respected them).

This kind of project — one substantive cross-cutting effort per cycle, with measurable impact and visible mentorship — is what gets you promoted to senior. Three of these in 18-24 months is what gets you to the staff conversation.

Senior compensation: cited specifics with the longevity dynamic

From levels.fyi self-reports (verified 2026-04-27):

The longevity dynamic at senior: compensation scales with tenure even without promotion. Refresher RSU grants stack annually; total comp at year 4 of senior tenure is typically 20-30% higher than at year 1. Engineers who stay senior for 5-10 years at FAANG often have higher total compensation than recent staff promotes whose stock hasn't fully vested.

External moves at senior: 15-25% bump on average per levels.fyi job-history. Trade-off: rebuilding context (~6 months), losing stacked refreshers, restarting at year-1 vesting. The 'stay vs leave' calculation is real and often counter-intuitive — leaving for a 20% comp bump can actually decrease 4-year cumulative compensation if you've already accumulated stacked refreshers at the current company. Use levels.fyi's offer-comparison tool to model this.

Built In's senior SWE average (builtin.com/salaries/us/senior-software-engineer) reflects stock-weighted methodology and runs higher than Glassdoor's base-weighted methodology. The truth is in the gap between them; trust levels.fyi's self-reported total comp as the most reliable single source.

What gets you to staff (and what doesn't)

Promotion from senior to staff is the steepest jump in the IC track. The empirical pattern from StaffEng's archetype analysis (staffeng.com/guides/staff-archetypes) and Hello Interview's leveling guide:

The two requirements that consistently separate staff-promoted from staff-stalled:

1. Scope expansion beyond the immediate team. Your work affects multiple teams or sets technical direction at the platform level. Senior owns a service area; staff owns a platform pattern, an org-wide initiative, or a multi-team migration.
2. Technical depth at unambiguously high quality. Your work is the canonical reference in some area — internal libraries others depend on, design docs cited across the org, standards you've established. Staff engineers are technical leaders, not just senior individual contributors.

The four staff archetypes (Will Larson's framework, staffeng.com/guides/staff-archetypes):

• Tech Lead. Owns technical direction for a team while not managing the team. Most common archetype.
• Architect. Owns technical direction across teams; doesn't run a single team's technical work day-to-day.
• Solver. Tackles the org's hardest technical problems — typically incident-bound or migration-bound work that nobody else can drive.
• Right Hand. Operates as a technical extension of an engineering executive; senior-IC scope but with significant strategic involvement.

Each archetype has a different promotion path. Tech Lead promotes from senior by becoming the indispensable technical leader on a team; Architect by driving cross-team work consistently; Solver by being the engineer the org calls when things break; Right Hand by partnering closely with VP/CTO-level leadership.

What doesn't get you to staff:

• Being a great senior engineer for 5+ years without scope expansion. Staff isn't 'senior with more tenure'.
• Volume of contributions without depth. Staff is graded on impact and influence, not commit count.
• Refusing to write design docs, RFCs, or other artifacts that demonstrate technical leadership.
• Avoiding cross-team work because it's harder to coordinate.
• Strong technical work that nobody outside your immediate team knows about — visibility matters at staff.

The honest truth: most senior engineers don't promote to staff, and that's structural. Staff slots are limited at most companies; the bar is high; the path takes 3-5 years from senior. Engineers who stay senior for 5-10 years at FAANG often earn comparable total compensation to recent staff promotes via tenure-stacked refreshers, and have less of the org-political overhead. Senior is a viable terminal level.