Levels measure scope and ambiguity, not years. Before an interview, find out what the target level owns at that company, then prepare stories whose scope matches it: tasks, projects, team goals, multi-team strategy or company direction.
What changes between levels: scope and ambiguity, not years
Dropbox publishes its engineering career framework, which makes it a useful worked example. Its first level executes defined tasks with specific guidance; the second executes defined projects toward team goals and chooses the solution; the third owns projects for quarterly goals and solves ambiguous, open-ended problems independently; the fourth owns half-year or annual team goals with impact starting to reach other teams. Staff (IC5) sets multi-year, multi-team technical strategy, and Principal (IC6) owns organization- or company-wide goals.
Years appear only indirectly. Dropbox's promotion guidelines list typical time in level as 1.5 to 2 years at the first level, 2 to 3 at the second and 2 to 4 at the third, and describe the fourth as a career level for many engineers. Its promotion principles add “evidence, not faith”: promotions recognize sustained impact at the next level, not hope that you can handle it. Tenure correlates with level; it does not define it.
Scope, impact and autonomy by level
The table condenses the common progression into five bands. It is a synthesis anchored on Dropbox's published wording, not any one company's ladder; your employer may split a band in two or merge two of them. The useful column is the last one: it describes the evidence an interviewer or promotion committee looks for, which is what your stories must contain.
Notice that each step widens two things at once. The unit of work grows from task to project to team goal to multi-team strategy, and the problem arrives less defined: a junior engineer receives a solution to implement, a senior engineer receives a problem, and a staff engineer often has to decide which problem is worth solving at all. That is why a bigger codebase or a longer tenure alone does not move you up a band.
| Level | Scope | Ambiguity | Evidence interviewers seek |
|---|---|---|---|
| Junior | Defined tasks | Solution mostly given | Clean code, good questions |
| Mid-level | Defined projects | Chooses the approach | Features shipped end to end |
| Senior | Team goals, quarter or longer | Open-ended problems | Leads designs, mentors, owns outcomes |
| Staff | Multi-team, multi-year | Defines what and how | Strategy adopted beyond own team |
| Principal | Org or company-wide | Industry-level problems | Shapes direction across groups |
Google L5, Meta E5, Amazon SDE II: what the labels tell you
Big-tech level codes circulate widely, but they are company-specific. A common public reference is Levels.fyi, a community site whose data is self-reported by professionals; the site says each entry is reviewed before publication. As of November 2026 its community data lists Google levels from L3 (entry) with L5 as Senior SWE, Meta levels from E3 (entry) through E9, and Amazon levels from L4 (entry) with L6 as Senior SDE. Treat any cross-company equivalence as approximate and confirm it with the recruiter.
Amazon's own job board uses the titles Software Development Engineer I, II and III, and many senior postings read Sr. Software Development Engineer. Amazon describes its principal engineers as its most senior individual contributors, working on the company's hardest problems, with published community tenets such as Technically fearless and Exemplary practitioner. The search query “what is software engineer level 3” shows the trap: Levels.fyi lists Google's L3 as entry level, while Dropbox's third level owns projects for quarterly goals. Ask what a level owns, not what number it carries.
| Company | Labels | Source |
|---|---|---|
| Dropbox | IC1 to IC7; IC5 Staff, IC6 Principal | Published career framework |
| Amazon | SDE I, II, III, Sr. SDE; Principal | amazon.jobs titles and PE tenets page |
| L3 entry; L5 Senior SWE | Levels.fyi, self-reported | |
| Meta | E3 entry through E9 | Levels.fyi, self-reported |
Staff vs senior engineer, and staff vs principal
The senior-to-staff jump changes the unit of work. A senior engineer owns outcomes for a team's projects; a staff engineer's work spans teams, and success means other teams adopt the direction. Dropbox's staff level talks about influencing other teams' roadmaps and favoring the wider organization over locally optimal choices. Staff to principal widens scope again: Dropbox's principal level owns company-wide, multi-year goals, partners with senior leadership and takes an industry-level view of where the systems must go.
Staff is also several jobs under one title. Will Larson's StaffEng describes four archetypes, and he notes that some companies use tech lead as a title while others use it as a role. When you interview for staff, ask which archetype the opening needs, because the evidence differs: a Solver's best story is a hard problem cracked, an Architect's is a domain kept coherent for years.
- Tech Lead: guides the approach and execution of one team, often a first staff role.
- Architect: responsible for direction and quality within a critical technical area.
- Solver: goes deep on arbitrarily complex problems wherever they appear.
- Right Hand: extends a senior leader's attention with borrowed authority; the rarest.
How your target level changes the interview loop
Loops differ by company, so ask the recruiter which rounds you will have and which level the loop is calibrated for. Because levels differ by scope and ambiguity, the rounds that reveal scope, system design and behavioral, usually carry more of the leveling decision as the target rises, while coding rounds check fundamentals at every level. A senior candidate is expected to drive a system design conversation: gather requirements, propose a design, name trade-offs and failure modes. A staff candidate adds sequencing, migration, cost and cross-team constraints.
Behavioral stories carry the scope signal. If you target staff but your strongest story is a well-executed project inside one team, you are giving senior evidence. Build a story bank keyed to the level's language: one story each for ambiguity you resolved, influence beyond your team, mentoring, a technical decision others adopted, and a failure. Put a number and a time span in every story, because scope words without scale sound like title inflation.
How to argue for the right level
Leveling decisions are usually made from interview evidence, so the argument starts before the loop. Describe your work in scope terms rather than titles: “I owned the reliability roadmap for payments across three teams for a year” says more than “senior engineer at a fintech.” Bring artifacts you can talk through, such as design documents you wrote, systems you own, and engineers you mentored. If you are offered a lower level than you targeted, ask what evidence was missing.
A concrete answer to that question is a promotion plan; a vague one is a warning sign. Weigh the actual scope of the role more than the label, since a well-scoped role at a lower level can be the faster path. Do not argue level from compensation or years, because the people deciding are calibrating evidence, not need. If you still believe the level is wrong, offer additional evidence, such as a design document or a reference to a system you owned, rather than repeating your title.
- Ask early: which level is this loop calibrated for, and what does that level own here?
- Translate titles into scope, time span and number of teams affected.
- Prepare one story per level-defining trait, with numbers.
- If down-leveled, ask what was missing and how promotion works on that team.
Practice: map your stories to a level
Take your five best work stories and label each with the band it demonstrates using the table above. If most land one band below your target, you know what to prepare: either find bigger stories you have undersold, or target the level your evidence supports and plan the next step. Rehearse saying the scope sentence of each story, team count and time span, until it comes out naturally.
The guides below cover how leveling connects to pay growth, what changes if you are considering the management track instead, and how one large company structures its loop. Revisit the mapping after each interview: the questions you struggled with usually point to the band where your evidence runs thin.
Quick answers
Frequently asked questions
How many years does it take to become a senior engineer?
There is no universal number. Dropbox, which publishes its promotion guidelines, lists 1.5 to 4 years as typical time in each of its first three levels, but promotion there requires demonstrated, sustained impact at the next level. Treat tenure as a correlation, not a requirement.
Is a staff engineer a manager?
No. Staff is an individual-contributor level that leads through technical direction and influence rather than reporting lines. Dropbox's framework, for example, runs engineering managers on a separate track, M3 to M7, next to the IC levels.
What does software engineer level 3 mean?
It depends on the company. Levels.fyi's self-reported data lists Google's L3 as entry level, while Dropbox's third level owns projects for quarterly team goals and handles ambiguous problems independently. Always ask what the level owns, not what number it carries.
Should I accept a lower level to join a company I like?
Sometimes. Weigh the actual scope of the role, how promotion works there and how quickly you could show next-level impact. Ask what evidence was missing from your loop; a specific answer gives you a plan, a vague one is a reason for caution.
Source notes
References and review policy
Information checked on November 7, 2026. Section links identify sources for factual claims and technical explanations. Interpretations, practice scenarios and preparation recommendations are RecallDeck’s editorial work.
From reading to recall
Practice the full interview loop.
RecallDeck schedules the concepts you miss and keeps coding, design, and behavioral fundamentals available when the interviewer changes direction.