On a resume, engineering level is shown mainly by scope: a junior delivers tasks and features, a mid-level engineer owns a service, a senior shapes a system, and a staff engineer sets direction across several teams. The scope words, the verbs you choose and the evidence you put first should all match the level you’re applying for. The title alone isn’t enough.
Who this is for: software engineers at any level who want their resume to read at the right level, especially when moving between companies where titles mean different things.
Why titles aren’t enough
A “senior engineer” at a 20-person startup and one at a large tech company can have very different jobs. The first often covers more breadth: infrastructure, product and hiring. The second is judged on depth and influence across teams at scale. Hiring managers know this, so they read your bullets to work out your real level and pay less attention to the title.
Many engineering ladders describe the same progression. Gergely Orosz’s The Software Engineer’s Guidebook covers the journey from competent developer through senior and tech lead to staff and principal. Most company ladders differ in names, not in shape.
The levels at a glance
| Level | Scope | What goes first | Typical verbs |
|---|---|---|---|
| Junior | Task, feature, component | Delivered features, learning speed, quality habits (tests, reviews) | Built, implemented, fixed, added |
| Mid | Service, end-to-end feature | Ownership, reliability, collaboration | Owned, delivered, maintained, improved |
| Senior | System, product area | Design, migrations, trade-offs, cross-team impact, mentoring | Designed, architected, led, migrated |
| Staff / Principal | Several teams, platform, organisation | Direction, standards, multi-team leverage, long-term bets | Defined, set direction, aligned, made standard |
Junior engineer resume: delivered and learning
What reviewers look for: can you deliver well-defined work, do you care about quality, and do you learn quickly?
Put forward the features you built, the tests you wrote, the code reviews you took part in, and the new tools or domains you picked up. Personal or study projects count when they show the same things.
Hypothetical example:
Built the CSV export for the reporting page, including streaming for large files; wrote integration tests and addressed review feedback from two senior engineers.
Avoid “architected the platform” when you added one endpoint. Overreaching is more obvious at junior level than anywhere else.
Mid-level engineer resume: owned and kept running
What reviewers look for: can you take something from idea to production and keep it healthy without hand-holding?
Put forward services or features you owned end to end, on-call or reliability work, and how you worked with product, design and QA.
Before (reads as junior):
Worked on the notifications service.
After (mid-level):
Owned the notifications service from design to on-call; added delivery tracking and retries, and worked with the mobile team to roll out push notifications for both apps.
Senior engineer resume: systems and trade-offs
What reviewers look for: can you design a system, make sensible trade-offs, and lead work that other people depend on?
Put forward designs, migrations, decisions with real trade-offs, impact across teams, and mentoring.
Before (reads as mid):
Owned the checkout service and improved its performance.
After (senior):
Designed the move of checkout from synchronous calls to an event-driven flow so that inventory and payments could fail independently; led three engineers through the migration with no customer-facing downtime.
Numbers help here if you have them. If you don’t, the scope and the trade-off carry the bullet. See resume bullets without metrics.
Staff engineer resume: direction and leverage
What reviewers look for: have other teams changed how they work because of you?
Put forward technical direction, standards other teams adopted, ownerless problems you organised people around, and long-term bets.
Hypothetical example:
Defined the service template and deployment standard adopted by all backend teams; it replaced four in-house variants and made platform upgrades a single coordinated change.
The jump from senior to staff is where most resumes get stuck, so it has its own guide: senior vs staff engineer resume.
The same achievement at different levels
One real project can support different resumes, depending on your role in it. Say a team moved its logging to a new platform:
One logging migration, four levels
Migrated logging for the user service to the new platform and updated the dashboards.
What carries the level: one service, hands-on verb (migrated, updated).
Owned the logging migration for the account services, including alerts and the runbook updates.
What carries the level: ownership of a group of services, including what keeps them running.
Designed the logging schema and rollout plan for the product area; led the migration across six services.
What carries the level: design decisions and leading others across a product area.
Set the observability standard for the engineering organisation and coordinated adoption across teams.
What carries the level: a standard that other teams adopted.
Only one of these is true for you. Write that one. The point is that the scope word and the verb carry the level, and you can’t borrow a level you didn’t work at.
Level and role type are different axes
Level says how wide your scope is. Role type says how your time splits between hands-on work and people:
- Individual contributor: mostly hands-on design and code.
- Tech lead: roughly half technical, half team and delivery.
- Engineering manager: mostly the team: hiring, delivery and how the team works.
- Head or director: mostly organisation strategy, budget and several teams.
A senior IC resume and a senior manager resume look very different. Make sure yours matches the role in the posting.
It depends on the company
| Company type | How levels work | What to show |
|---|---|---|
| Big tech | Formal levels, compared against a written ladder | The ladder’s language where it’s accurate, real numbers where you have them |
| Scale-ups | Newer levels that shift as the company grows | That you can work at the next scope up |
| Enterprise | Titles may be inflated or deflated compared to tech companies | Scope in concrete terms |
| Startups | Breadth often matters more than formal level | Range and what you shipped |
Applying at a different level
One level up: keep your real title and lead with your highest-scope work. If you led a design or a migration as a mid-level engineer, say so plainly.
One level down: this is common when moving to a bigger company. Don’t hide your title. Do lead with depth and hands-on work instead of breadth, so the reviewer sees you fitting the role.
In both cases you’re tailoring the same facts to the reader, not changing them.
Check your own CV
Answer four questions about what is actually written on your CV. It’s a reading of the wording, not an assessment of you.
What level does your CV read as?
What not to do
- Don’t change your title to match the level you want.
- Don’t use staff-level verbs for senior-scope work. Interviewers will check.
- Don’t list everything you’ve ever done. Lower-level work dilutes a senior or staff resume.
- Don’t assume your title means the same thing at the next company.
FAQ
How do I show seniority on a resume?
Through scope (feature, service, system or organisation), the verbs you use, and the evidence you put first. The title supports this but doesn't prove it.
Should I put my level, like "L5", on my resume?
Internal codes mean little outside the company. Use the title and let the bullets show the scope.
My title is "senior" but my work feels mid-level. What do I do?
Keep the title, describe the scope accurately, and target roles that match the work you can show.
How many years does each level take?
It varies a lot between companies and people. Scope is a better signal than years.
Does this apply outside software engineering?
The idea of scope growing over time applies to most professions. The specific verbs and evidence change.