Junior, Mid, Senior: How Engineering Levels Actually Work

TL;DR

Engineering levels are not about years of experience. They're about scope, autonomy, and impact.
Junior engineers execute well-defined tasks with guidance. Mid-level engineers own features end-to-end. Senior engineers shape what gets built and how.
Levels vary significantly by company. L3 at Google is not the same as "junior engineer" at a 20-person startup.
Understanding your level helps you negotiate offers, set realistic expectations, and build toward promotion intentionally.
Most engineers stay junior for 1-3 years. The move to mid is the most important early-career milestone.

When you get your first engineering job, you probably have a title. Maybe it's "Software Engineer I," or "Junior Engineer," or "Associate Software Engineer," or just "Software Engineer." But the title doesn't tell you much. What matters is what's actually expected of you at your level, and what it takes to get to the next one.

Most new engineers don't think about this until their first performance review. Then they discover that "performing well" means different things at different levels, and that working hard alone is not a path to promotion.

This article explains what engineering levels actually mean, how they differ by company, and why getting clear on your level is one of the most useful things you can do early in your career.

To get the most out of this, it helps to start with a solid understanding of what your first 90 days as a software engineer should look like. The early months are when you're actively calibrating your level and building a baseline.

The Core Distinction: Scope and Autonomy

The simplest way to think about engineering levels is in terms of two variables: the scope of work you own, and the degree of direction you need to do it well.

Junior engineers work on well-scoped tasks that someone else has defined. A senior engineer or tech lead breaks down a feature into pieces, assigns a piece to the junior, and provides context about what done looks like. The junior's job is to execute it correctly, ask good questions when blocked, and not introduce problems that weren't there before.

Mid-level engineers own features, not just tasks. They can take a business requirement, break it down themselves, identify the technical approach, handle edge cases, and ship the thing. They still work within a team and get input from seniors, but they don't need someone else to define the work for them. They define it.

Senior engineers operate at a scope that goes beyond individual features. They make decisions about architecture, contribute to technical direction, and think about what should be built — not just how to build it. They also multiply the output of the engineers around them by reviewing code carefully, unblocking people efficiently, and raising the quality of discussions.

Those are rough descriptions. The reality is messier. But the underlying principle holds: as you advance, the scope of what you own expands and the guidance you need decreases.

Why "Years of Experience" Is a Weak Signal

You'll often see job postings that say "2-3 years of experience required" for a mid-level role, or "5+ years" for a senior role. Those are approximations, not definitions.

Engineers who move fast, get good feedback, and are intentional about growing can hit mid-level expectations in two years. Engineers who stay in comfortable, low-stakes work can remain at a junior level of actual output for five years regardless of their title.

What matters is what you've done with the time you've had, not how much time has passed.

This is important to understand for two reasons. First, it means you can accelerate. If you're intentional about taking on work that builds the skills associated with the next level, you can move faster than average. Second, it means that leveling at companies is not automatic. Staying in a role for two years doesn't mean you'll be promoted. You have to actually demonstrate the behaviors associated with the next level.

How Levels Work at Big Tech Companies

At large tech companies, levels are explicit and numerical. Here's a rough guide:

Google: L3 is the standard new grad entry level. L4 is mid-level. L5 is senior. L6 and above is staff and principal territory.

Meta: E3 is new grad. E4 is mid-level. E5 is senior. The jump from E4 to E5 is considered one of the hardest in the industry.

Amazon: SDE I is entry level. SDE II is mid-level. SDE III is senior. Amazon also uses principal engineer levels above that.

Microsoft: SWE/SDE levels use a number system starting around 59-60 for new grads and going up. Level 63 roughly corresponds to senior.

These numbers are worth knowing because they affect compensation directly. An L4 at Google earns significantly more than an L3, not just in base salary but in equity and total comp. How companies structure total compensation explains why the level matters so much financially.

How Levels Work at Startups and Mid-Sized Companies

At smaller companies, the system looks different and is often less explicit.

A 20-person startup may not use levels at all. You're a software engineer. The expectations evolve based on the company's growth and what it needs from you at a given time. There's no formal rubric. Whether you're operating at a "junior" or "mid" level is a judgment call made by your manager or the CTO.

Mid-sized companies often use titles like "Software Engineer I," "Software Engineer II," and "Senior Software Engineer," with informal rubrics that vary by team. The title inflation or deflation relative to Big Tech is real. A "Senior Software Engineer" at a Series B startup with 40 engineers may be doing work that would be considered mid-level at a FAANG company, or may genuinely be operating at a senior level. There's no universal standard.

This is why you can't assume that a title maps directly to a level. You have to understand what the company means by that title, what behaviors they expect, and how they assess performance.

What Junior Actually Looks Like in Practice

At the junior level, you're expected to:

Complete tasks that have been broken down and defined for you
Write code that works and passes review without creating large hidden problems
Ask for help when genuinely blocked rather than spinning for hours
Give reliable estimates for small, well-scoped work
Ship features without requiring constant handholding

What you're not expected to do: independently drive large projects, mentor other engineers, make architectural decisions, or push back on technical direction without basis.

The common junior failure modes are: taking too long on simple things because you're not willing to ask for help, introducing bugs from not understanding the broader system, underestimating how much your work affects other people's work, and not communicating when timelines slip.

None of those are about intelligence. They're about habits and self-awareness, both of which you can develop.

What Mid-Level Actually Looks Like in Practice

The jump from junior to mid is significant. At the mid level, you're expected to:

Take a feature from requirements to shipped code without needing someone to break it down for you
Understand the broader system well enough to make reasonable technical decisions for your area
Identify and flag risks before they become problems
Give reliable estimates for medium-complexity work
Start to contribute to code review in a useful way, not just as a rubber stamp
Work with stakeholders (product managers, designers) directly, not just through a senior intermediary

What changes is the locus of initiative. Junior engineers wait for the work to come to them. Mid-level engineers reach for it, and also start to see things that need to be done that nobody assigned to them.

What the transition from junior to mid actually requires goes deeper on the specific behaviors and how to build toward them.

What Senior Actually Looks Like in Practice

Senior engineers get talked about a lot in job postings. In reality, "senior" means very different things at different companies.

The consistent elements: senior engineers work at a scope that affects multiple features or systems, not just one. They make technical decisions with enough confidence that others rely on them. They actively improve the quality of engineering around them, through code review, design documents, technical discussions, and mentorship.

Critically, senior engineers are expected to understand the business context of the work, not just the technical implementation. A senior engineer who can build anything but can't tell you why it matters, or what problem it solves, or what the tradeoff was in choosing this approach over another, is missing part of the job.

Getting to senior usually takes 4-8 years, though it's not a clock. Some engineers get there in 3 years at the right company with the right conditions. Others spend 10 years at a comfortable job and haven't operated at a senior level because they never had to.

Why This Matters for Your Offer and Your Trajectory

When you're evaluating a job offer, knowing your level matters beyond just the title. Your level determines your pay band, your promotion timeline, and the expectations you'll be held to.

If you're being hired as a junior and the work actually requires mid-level thinking, you'll be in constant stress trying to operate above your support level. If you're being hired as mid-level but the role is actually junior-level work with senior engineers solving the hard problems, you may plateau.

Understanding your actual level also helps you have better conversations with your manager about growth. Rather than vaguely wanting to "do more," you can be specific: "I want to start owning features end-to-end rather than just implementing scoped tasks. What would that look like on this team?"

That's a more useful conversation than "how do I get promoted?"

How promotions and raises work at your first engineering job covers the mechanics of the formal process and how to make your case when the time comes.

The Level Mismatch Problem

A common problem for new engineers: your actual output level and your title are misaligned, and nobody told you.

This happens in a few ways. Sometimes a company hires a junior engineer with a "Software Engineer" title (no "junior" qualifier) but pays them and treats them at a junior level. The title sounds like mid-level but the expectations and pay are not. When the engineer starts trying to operate at what they think the title implies, they get feedback that they're overstepping.

The reverse also happens: someone gets hired as a junior but quickly starts operating at a mid-level scope, gets treated like a mid-level engineer by the team, but their title and pay don't catch up. They're delivering mid-level work for junior-level comp.

Both situations are worth having explicit conversations about. If you're not sure where you sit in your company's level structure, ask your manager directly. "What level am I operating at, and what would it look like to operate at the next level?" is a legitimate question that most managers will answer seriously.

A Practical First Step

Pick one behavior associated with the level above where you currently are, and start doing it deliberately.

If you're at the junior level, that might mean starting to break down a feature on your own before asking a senior to do it, then comparing your breakdown to theirs. If you're mid-level and working toward senior, it might mean writing up a short design document for the next feature you own before building it, and inviting senior engineers to comment.

You don't need a promotion plan or a formal conversation to start. You need to start operating at the next level in small, visible ways. The recognition tends to follow.

How to negotiate your first engineering offer connects back to this: understanding your level is part of knowing what you're worth and what you can credibly ask for.