On this page

What is a senior engineer?

What is a staff engineer?

Where the two levels sit at large companies

Scope: one team versus several

Time horizon: months versus years

Influence: through your own work versus through others

The four shapes of the staff role

How the week is spent

What promotion committees look for

Why many engineers stay senior

How pay differs

The interview bar, round by round

Signs you are ready for staff

Staff engineer vs senior engineer compared

Frequently asked questions

Related reading

Staff Engineer vs Senior Engineer: Scope, Expectations, Interview Bar

Image
Arslan Ahmad
Staff engineer vs senior engineer: how scope, time horizon, influence, promotion, pay, and the interview bar differ between the two levels, with side-by-side examples.
Image

What is a senior engineer?

What is a staff engineer?

Where the two levels sit at large companies

Scope: one team versus several

Time horizon: months versus years

Influence: through your own work versus through others

The four shapes of the staff role

How the week is spent

What promotion committees look for

Why many engineers stay senior

How pay differs

The interview bar, round by round

Signs you are ready for staff

Staff engineer vs senior engineer compared

Frequently asked questions

Related reading

A senior engineer owns the technical results of one team. A staff engineer owns technical results that span several teams, and gets most of them through people who do not report to them. Both levels write code, review designs, and mentor others. The difference is the size of the problem each one is trusted with, how far ahead each one plans, and how much of the work happens through other engineers.

That difference sounds small in a job description, and it is large in practice. At Google, the step from Senior (L5) to Staff (L6) commonly takes three to five years or more, and many strong engineers never take it. In an interview loop, the same question can be answered at either level, and the level of the offer depends on which kind of answer the candidate gives.

This article compares the two roles directly. It covers scope, time horizon, and influence, with examples of the same project handled at each level. It then describes the four common shapes of the staff role, how the week is spent, what promotion committees look for, how pay differs, and what each interview round expects.

What is a senior engineer?

A senior engineer is an experienced individual contributor who can deliver large pieces of work for a team without close supervision. An individual contributor is an engineer whose main job is technical work rather than managing people.

A senior engineer typically owns one service or one major feature from design to production. They break a project into tasks, make the important design decisions inside their team, review other engineers' code, and help less experienced teammates grow. When something breaks in their area, they are usually the person who understands it best.

At large companies, the senior level is often the terminal level, or close to it. A terminal level is a level where an engineer can stay for a whole career without pressure to be promoted. Google's terminal level is officially L4, and in practice most career engineers settle at L5. Meta's is E5, and Apple's is ICT4. A company that sets the terminal level there is saying that senior is a complete and respected career, not a waiting room for something higher.

What is a staff engineer?

A staff engineer is a senior individual contributor whose work spans several teams rather than one. At most large companies, staff is the first level above senior: L6 at Google, E6 at Meta, and ICT5 at Apple. Amazon has no staff title, and its closest match is Principal SDE at L7. The staff engineer levels guide compares those four in detail.

A staff engineer is not a manager. They usually have no direct reports, and they still write code, though less of it. Their job is to make sure that the technical decisions affecting several teams are made well, made once, and then carried out. The teams doing the work report to other people, so a staff engineer leads mainly through written designs, reviews, and agreement.

Tanya Reilly, in her book The Staff Engineer's Path, describes the role through three pillars: big-picture thinking, project execution, and leveling up the engineers around you. Each pillar exists at senior level too. At staff level, each one applies to an organization rather than a team.

Where the two levels sit at large companies

The table below places the two levels side by side at four large companies. These mappings are not published by the companies; they come from reported offers and aggregators such as levels.fyi.

CompanySenior levelStaff levelGap between them
GoogleL5 Senior Software EngineerL6 Staff Software EngineerOne level
MetaE5 Senior Software EngineerE6 Staff Software EngineerOne level
AmazonL6 Senior SDEL7 Principal SDE (no staff title)One level, but a larger step in scope
AppleICT4ICT5One level

Amazon is the case that confuses people most. Amazon L6 is a senior level, so it maps to Google L5 and Meta E5, not to Google L6. Engineers who compare the numbers directly misjudge the level by one step.

Scope: one team versus several

Scope is the size of the problem an engineer is trusted to own. It is the clearest difference between the two levels, and it is easiest to see when both levels work on the same problem.

Consider a company where checkout pages have become slow. The 99th percentile latency, which is the response time that 99 out of 100 requests beat, has grown from 400 ms to 1.8 seconds over six months.

  • The senior engineer owns the checkout service. They profile it, find two slow database queries and a missing cache, fix all three, and bring the service's own latency back to 300 ms. The work is correct, well tested, and done in four weeks.
  • The staff engineer asks why latency grew across six months at all. They find that checkout calls seven other services, and that four teams added synchronous calls to it, each one reasonable on its own. They write a short design that sets a latency budget for every service on the checkout path, which is a fixed share of the total response time each service may use. They get the four teams to agree to it, and they add a check that fails a deployment when a service exceeds its share.

Both results matter. The senior work fixed the problem that existed. The staff work fixed the reason the problem kept returning, and it needed four teams to change how they build software. That second kind of result is what "scope" means in a staff promotion case.

The same slow checkout problem handled at senior scope and at staff scope

Scope is not the same as project size. A senior engineer can lead a large project with ten engineers, all on one team. A staff engineer can own a small change, such as one shared library, that affects twenty teams. What decides the level is how many teams' decisions the work shapes, not how many lines of code it contains.

Time horizon: months versus years

Time horizon is how far ahead an engineer's decisions are meant to hold. A senior engineer usually plans for the current project and the next few months. A staff engineer makes decisions that will shape the next two or three years, which means the design must allow for change it cannot fully predict.

In practice, a longer time horizon changes what a design document contains. A senior design describes the system to build. A staff design also describes:

  • what ships first and what is deliberately temporary;
  • which measured condition, such as write traffic passing 10,000 requests per second, should start the next stage;
  • what the system will cost to operate in on-call hours, not only in dollars;
  • how the company will move from the systems that exist today.

Returning to the checkout example, the senior engineer's cache fix is correct for today's traffic. The staff engineer's latency budget is designed for the year when checkout calls twelve services instead of seven, and when two of today's four teams have been reorganized.

Influence: through your own work versus through others

Influence is how an engineer gets results. A senior engineer delivers mostly through their own work and their own team's work. A staff engineer delivers mostly through other engineers, many of whom report to someone else.

This is the difference that engineers find hardest in their first staff role. A senior engineer who disagrees with a design on their own team can usually settle it inside the team, with the tech lead or the manager making the final call. A staff engineer who disagrees with another team's design has no such authority. They have to persuade, usually in writing, and they have to accept decisions they would not have made when the trade-off is reasonable.

The tools of influence are mostly documents and conversations: design reviews, written technical strategies, architecture decision records, and one-to-one meetings with other teams' leads. An architecture decision record is a short document that states one decision, the options considered, and why one was chosen. A staff engineer who writes clearly can change the direction of a whole organization without writing the code that implements the change.

Preparing for a staff interview loop? The rounds look the same as a senior loop, but each one is scored for scope, time horizon, and influence.

Grokking Staff Engineer Interview teaches what staff answers contain in system design, the project deep dive, and behavioral rounds, with full mock loops to compare against your own answers.

The four shapes of the staff role

Not every staff engineer does the same job. Will Larson, in his book Staff Engineer: Leadership Beyond the Management Track, describes four common shapes of the role, which he calls archetypes.

  • Tech Lead. Guides the technical direction and execution of one team, or a small group of closely related teams. This is the most common shape, and the closest to senior work.
  • Architect. Owns the direction and quality of one critical technical area, such as data storage or the payments platform, across all the teams that touch it.
  • Solver. Works on one hard problem at a time, often moving to a new problem when leadership decides another area needs attention.
  • Right Hand. Works closely with a senior engineering leader and extends that leader's reach across a large organization, without having direct reports.

Larson also notes that one engineer can fit more than one shape, and can move between them over a career. The shapes matter in practice for two reasons. First, a team hiring a Tech Lead will value different experience than a team hiring an Architect, so it helps to ask which shape a role is. Second, the senior engineers closest to promotion usually already work as informal Tech Leads, which is why that shape is the most common entry into staff.

How the week is spent

The clearest daily difference is how much time goes into writing code. The split below is illustrative, based on a typical 40-hour week, and it varies widely by company, team, and archetype.

ActivitySenior engineer (illustrative hours)Staff engineer (illustrative hours)
Writing and reviewing code20 to 248 to 12
Design documents and design reviews4 to 610 to 12
Meetings with other teams2 to 48 to 10
Mentoring and sponsoring engineers3 to 44 to 6
Incidents and on-call4 to 62 to 4

How a senior engineer and a staff engineer typically divide a working week

Two points in this split are worth noting. A staff engineer still writes code, and the code they write is often the hardest or most foundational part of a project: a prototype that proves a design works, or the first version of a shared library. And the meeting hours are not a sign that the work has become less technical. Most of those meetings are design discussions that decide what several teams will build.

Sponsoring is also different from mentoring. Mentoring means giving advice. Sponsoring means using your own standing to get a less experienced engineer a visible project or a promotion. Staff engineers are expected to do both.

What promotion committees look for

A promotion committee is a group of senior engineers and managers who decide promotions from a written case. At staff level, that case needs evidence that the candidate already works at staff scope. Committees rarely promote on potential at this level.

The evidence committees look for usually falls into four groups:

  1. Projects that crossed team boundaries. At least two, where other teams changed how they work because of the candidate's decisions.
  2. Written technical direction. Design documents or strategies that were adopted, with a record of the alternatives considered.
  3. Results in numbers. Latency reduced, cost saved, incidents prevented, or hours of manual work removed, with the size stated.
  4. Other engineers made stronger. People the candidate mentored or sponsored who took on larger work as a result.

The case is usually written by the candidate's manager, with input from engineers on other teams. That is why visibility outside the home team matters. A staff engineer at another team who can describe what the candidate changed is often the strongest single piece of evidence in the packet.

Why many engineers stay senior

Many excellent engineers stay at the senior level for their whole careers, and at most large companies that is a respected choice. Several reasons are common.

  • The work changes. Staff work means less time writing code and more time in documents and meetings. Some engineers prefer the senior balance and choose it on purpose.
  • The evidence is hard to build inside one team. An engineer on a team with a narrow mandate may never get a project that crosses team boundaries, however strong their work is.
  • The number of staff roles is limited. An organization of 60 engineers might need three or four staff engineers, not fifteen. Meta, for example, has been reported to have only about 15 percent of its engineers at E6 or above.
  • The terminal level removes pressure. Once an engineer is at or above the terminal level, there is no requirement to move up, so the choice is theirs.

Staying senior is not a failure of ambition. It is a decision about which kind of work an engineer wants to do every day.

How pay differs

Staff pay is meaningfully higher than senior pay at large companies, and most of the difference comes from stock. Using figures reported on this blog's levels guides, which draw on levels.fyi, Google L5 total pay in the United States is about 350K to 380K, while Google L6 averages about $600K. That is roughly 1.6 times the senior figure.

The same pattern holds at the other large companies, with different numbers. Levels.fyi reports average US staff-level total pay of about 720K at Meta E6, about 640K at Amazon Principal (L7), and about $560K at Apple ICT5. These are averages that change every month, so check the site for current figures before negotiating an offer.

Pay at smaller companies is lower in cash and stock, and the gap between senior and staff is often narrower. At a company with 200 engineers, the staff title can also mean something closer to a large company's senior level, so compare the scope of the role, not only the title.

The interview bar, round by round

A staff loop usually contains the same rounds as a senior loop: coding, system design, a project deep dive, behavioral questions, and a hiring manager conversation. The difference is what each round expects. In short:

  • Coding. The bar is usually close to the senior bar. A weak round can stop an offer, but a strong one rarely earns the staff level alone.
  • System design. This round most often decides the level. A staff answer defines the problem, states non-goals, plans how the system will change over time, and explains how several teams would build and run it. The L6 system design guide shows a full answer at that level.
  • Project deep dive. The project should have crossed team boundaries, and the candidate should have made the important decisions personally.
  • Behavioral. The stories need scope in numbers, the alternatives considered, and the effect on other teams.

The most common disappointing result for a staff candidate is down-leveling, which means the company makes an offer one level below the one the candidate applied for. It usually happens when the answers are correct but stay at team scope. The staff engineer interview guide explains each round in detail and gives a six-week preparation plan.

Signs you are ready for staff

There is no single test, but engineers who are promoted to staff usually already show most of these signs while still holding the senior title.

  • Other teams ask for your review on designs that do not belong to your team.
  • You have written at least one design or strategy that more than one team followed.
  • You can name the two or three largest technical risks for your organization over the next two years, not only for your team.
  • You regularly say no to work that is reasonable but not important, and explain why.
  • Engineers you mentored have taken on larger work, and you helped them get it.
  • Your manager can describe your impact without mentioning the code you wrote.

If most of these are true, the next step is usually a conversation with your manager about which project would give the promotion case its strongest evidence. If few of them are true, the gap is usually scope, and the fix is to find one problem that crosses team boundaries and lead it in writing.

Staff engineer vs senior engineer compared

The table below summarizes the differences covered above. In every row, the staff expectation includes the senior one and adds to it.

DimensionSenior engineerStaff engineer
ScopeOne team, one service or featureSeveral teams, one problem area
Time horizonThe current project, a few monthsTwo to three years
How results happenOwn work and own teamMostly through other teams
Main written outputCode and design docs for the teamDesigns and strategies other teams adopt
Coding timeMost of the weekA smaller share, often the hardest parts
Typical levelGoogle L5, Meta E5, Amazon L6, Apple ICT4Google L6, Meta E6, Amazon L7, Apple ICT5
Terminal level?Often, yesNo, it is an optional step
Deciding interview roundsCoding and system designSystem design, deep dive, behavioral

Frequently asked questions

What is the main difference between a staff and senior engineer? Scope. A senior engineer owns technical results for one team. A staff engineer owns technical results that span several teams, plans further ahead, and gets most of the work done through engineers who report to other people.

Is staff engineer higher than senior engineer? Yes. At most large companies, staff is the next level above senior: L6 at Google above L5, and E6 at Meta above E5. Amazon has no staff title and goes from Senior SDE (L6) to Principal SDE (L7).

Do staff engineers still write code? Yes, but less of it. Staff engineers often write the hardest or most foundational code on a project, such as a prototype or a shared library, and spend more of their week on designs, reviews, and work with other teams.

Is a staff engineer a manager? No. A staff engineer is an individual contributor and usually has no direct reports. They lead through written designs, reviews, and agreement rather than through authority over people.

How long does it take to go from senior to staff? At Google, the step from L5 to L6 commonly takes three to five years or more. Many engineers never take it, and at companies where senior is the terminal level, they are not expected to.

How much more does a staff engineer earn than a senior engineer? At Google, reported US total pay rises from about 350K to 380K at L5 to about $600K at L6, roughly 1.6 times. Most of the difference is stock, and figures change often, so check levels.fyi for current numbers.

What is the hardest part of moving from senior to staff? For most engineers, it is leading without authority. A staff engineer has to persuade other teams in writing, accept reasonable decisions they disagree with, and measure success by what other teams deliver.

Ready to show staff scope in every round?

Grokking Staff Engineer Interview teaches the judgment, scope, and influence that staff loops test, and ends with full mock loops you can compare against your own answers.

System Design Interview
Behavioral Interview

What our users say

Matzuk

Algorithms can be daunting, but they're less so with the right guide. This course - https://www.designgurus.io/course/grokking-the-coding-interview, is a great starting point. It covers typical problems you might encounter in interviews.

KAUSHIK JONNADULA

Thanks for a great resource! You guys are a lifesaver. I struggled a lot in design interviews, and Grokking System Design gave me an organized process to handle a design problem. Please keep adding more questions.

Steven Zhang

Just wanted to say thanks for your Grokking the system design interview resource (https://lnkd.in/g4Wii9r7) - it helped me immensely when I was interviewing from Tableau (very little system design exp) and helped me land 18 FAANG+ jobs!

More From Designgurus
Annual Subscription
Get instant access to all current and upcoming courses for one year.

Access to 50+ courses

New content added monthly

Certificate of completion

$31.08

/month

Billed Annually

Recommended Course
Grokking the Object Oriented Design Interview

Grokking the Object Oriented Design Interview

61,282+ students

4.2

Learn how to prepare for object oriented design interviews and practice common object oriented design interview questions. Master low level design interview.

View Course
Join our Newsletter

Get the latest system design articles and interview tips delivered to your inbox.

Read More

Salesforce System Design Interview: Questions and Mock Interview Practice

Arslan Ahmad

Arslan Ahmad

Beginner's Guide to Object-Oriented Programming (OOP)

Arslan Ahmad

Arslan Ahmad

Product Architecture vs System Design: Key Differences

Arslan Ahmad

Arslan Ahmad

2025 System Design Roadmap: From Beginner to Advanced

Arslan Ahmad

Arslan Ahmad

Design Gurus logo
One-Stop Portal For Tech Interviews.
About Us
Our Team
Careers
Partners
Contact Us
Become Affiliate
Copyright © 2026 Design Gurus, LLC. All rights reserved.