
Levels of Seniority - arbhassan
https://roadmap.sh/guides/levels-of-seniority
======
lmilcin
I only recognize difference between junior/senior levels.

My definition of senior developer:

\- Senior will not be "stuck" with a problem. They recognize there is somebody
to get help from and they will seek it. But they can also function when there
is no person to get technical help from. They will dig, and dig, and dig,
until they finally solve the problem.

\- I can trust the solution to be usable even without supervision.

\- They will have minimum standard they will enforce around them (ownership).
Ownership for me means they will look for things that are not right and act on
it, without being specifically instructed to.

\- Is adult in behavior, can recognize and control their emotions, can work
with other people, recognize and deal with communication problems.

From my perspective, people who have huge technical knowledge and experience
but can't be trusted with tasks, can't be trusted to not get conflicted with
the team on the first possible occasion, are not honest with their results
(hide problems), will sacrifice good of the project because they just have to
test that new tech -- all these people are junior devs for me.

~~~
enraged_camel
Your list only handles _how_ senior engineers solve problems.

IMO the most important qualities of a senior engineer pertain to knowing
_what_ problems to solve, and, at an even higher level of seniority, _why_
those problems need solving.

For example, senior-level engineers will recognize when a problem is not worth
solving at all. They might know that a solution is technically
possible/feasible, but they will also understand that the engineering
resources (i.e. their time) can, and in fact _should_ , be better spent
elsewhere -- fixing more egregious bugs, enhancing existing features and
developing new ones.

To go back to what you said, being able to "dig, and dig, and dig" until they
solve a problem is not what makes someone senior-level. Anyone with
sufficiently high levels of dedication and stubbornness can go down rabbit
hole after rabbit hole until they stumble upon something that resembles a
solution. What distinguishes senior-level engineers is being able to step back
and analyze the situation to determine if the rabbit holes are worth diving
into.

~~~
lmilcin
Let's be honest, this is requirements for a senior engineer, not a tech lead.

It would, of course, be nice for a senior engineer to have perfect awareness
but I think that is too much to ask to _qualify_ to be called senior.

Have you watched Star Trek (DS9 for example) lately? You may have a bunch of
senior officers but they still do not always understand why stuff needs to
happen. They muddle through on principles until they succeed. Then it is
always easy, retroactively, to say it was their idea all along.

------
zackmorris
I wish that the article mentioned the fourth level of seniority: graybeard.
Bluntly, that's any developer over 40. But in terms of mindset, it's more like
having multiple years of experience in a discipline spanning 2 or more eras so
that you begin to see solutions outside of the immediate problem space in
front of you.

So for example, a graybeard in the 1990s knew desktop development as well as
the web. In the 2000s it was probably web and mobile dev, then NoSQL and
reactive programming in the teens. Today it might be digging up old sysadmin
knowledge for containerization, or applying functional programming to big data
and machine learning problems. Maybe the definition gets fuzzier over time :-P

The problem with all of this is the danger of being put out to pasture. I hit
an existential crisis last year where I stopped seeing things in code and
started seeing everything like this big spreadsheet that I had to keep
consistent. Satisfying multiple constraints in very large search spaces
started giving me decision fatigue and I reached a point where my productivity
fell below the junior developer level. Like, I'd be given a ticket to fix a
bug in a view controller and discover that the problem was actually due to an
incorrect relationship in the database schema from 10 years ago. After awhile,
nobody wanted to hear about refactoring, they just wanted it to work, and we
began the long death march of playing whack-a-mole with technical debt. It
felt like there was nothing for me to contribute, and I burned out.

Now I don't know if I should continue programming, or try to transition to
being a mentor in a management role, or get out of the industry altogether and
move to something like renewable energy and build stuff in the real world. I'm
still struggling, so any thoughts on this would be much appreciated.

~~~
JMTQp8lwXL
You're right-- nobody wants to hear about refactoring. Management instead
hears "time sink and no additional revenue" (which isn't true, since too much
technical debt reduces velocity-- but you're the engineering expert, not
management. For a moment, let's forgive their naivete). So when you pick up
tickets, build more time into your estimates. Adding 30% more time to your
estimates isn't crazy, since estimates are often wrong, and people frequently
go over them. This really is a communication issue with how you package up
your discussion of time allocation to management. Before exiting industry, I
would consider giving this strategy a try.

~~~
jaredgorski
I’ve seen ex-engineers in management positions (one very well known and
experienced engineer in particular) forget how important it is to offset
technical debt. I think, more than naïveté, product managers just become
consumed by feature-making and feel unproductive if there’s not a constant
rush to hand new features off to engineering (which are then rushed to
release).

~~~
leetcrew
my charitable take is that they don't forget, but they have a hard time
explaining to customers why the next release has fewer new features. "now with
fewer crashes!" isn't really a good marketing pitch.

~~~
JamilD
When OS X Snow Leopard was announced, this was the intro slide:
[http://2ig18m1zutag3bjpoclbo8am-wpengine.netdna-
ssl.com/wp-c...](http://2ig18m1zutag3bjpoclbo8am-wpengine.netdna-ssl.com/wp-
content/uploads/S3/snow-leopard-0-new-features.jpg)

------
leto_ii
Many of the points made in the article seem pertinent to me, however I think
thinking in terms of discrete levels of seniority is counterproductive. I also
think that there isn't a single dimension of seniority that we should talk
about.

To give a precise example, in my previous job we had very hierarchically
senior people who understood the industry and the business side very well and
of course knew the company's platform very well. Oh the other hand, strictly
in terms of technical competence I think they lacked a lot of the basic mental
framework. Their code was atrocious (core code in classes of 1000+ lines with
no documentation or tests, lots of copy-paste), their choice of technology and
methodology parochial and antiquated (think Java 5-6, Ibatis in 2016 + a lot
of in-house built stuff, no code reviews, no QA etc.).

This kind of people in some ways would rank as competent architects and in
some other ways as fitting the good old adage "20 years of experience - the
same year repeated 20 times".

~~~
cle
It’s also illustrating that we engineers love to nitpick over stuff that
ultimately doesn’t matter all that much. You know what’s way more important
than short functions and programming platitudes like DRY? Understanding the
business, system architecture, and how to deliver fast in the context of
what’s already built.

~~~
aero142
You picked the easiest strawmen out of his examples to knock down in short
funtions and DRY. The other examples were, no QA, no code reviews, which are
things that I have seen first hand, combined with the other complains, to code
that is always in a half broken state. The code is very difficult to change so
you spend all of your time on support cases. Re-writes have their own
pitfalls. Ultimately, developer retention and hiring suffer because no one
wants to work on these products. The institutional knowledge leaves through
attrition and it takes too long for new developers to learn to be productive
in the code base. Eventually the quality of the product declines until
customers leave. So, even highly profitable products die because of poor
engineering practices. There are certainly engineers that get caught up in
know-it-all platitudes, but I've personally seen more profitable products fail
because of poor engineering practices than good engineering practices fail
because of poor business sense. YMMV, but in my experience, good engineering
is more rare than good business ideas.

~~~
JamesBarney
Woah my experience is completely different. I've never seen a product fail
because of poor engineering practices. And I've seen plenty fail because of
business issues.

I've worked mostly on enterprise software, many of which had awful code bases
but we're wildly profitable.

~~~
ivanhoe
What kills those products is not the bad code itself, it's the side-effects
piling up: added dev expanses, lagging behind the competition in adding new
features, performance problems as app grows, etc. Badly written code is simply
more expensive to maintain and improve. I guess it's less of an issue if you
have a very profitable product and/or enterprise clients who are much more
tolerable to things like the simplest customization taking weeks to finish,
integrations that are complicated and cost thousands and thousands of dollars,
etc. For startups and smaller businesses that are tight on dev budgets it's
much bigger of an issue.

------
camhart
"They know how to give feedback without hurting anyone."

Should instead be they use tact when giving constructive feedback. Too many
people water feedback down--scared that they might "hurt" people--resulting in
the value of the feedback being lost. We shouldn't be scared to be honest with
people--even if it means they might be hurt by it. It'll be better for them in
the long run to hear the truth now--even if it's tough to swallow. Giving this
type of feedback needs to come from a place of love--a desire to truly help,
and should never be done with the intention of hurting or trying to make them
feel like they were "wrong".

It should also be added: "They can receive feedback without being hurt"

~~~
tyurok
Second that.

Pain is constructive in the right dose, and it's also risky since you can lose
trust if delivered incorrectly. It requires maturity to give honest feedback
and recognize that it might be biased since we have a lot of limitations on
how we perceive others.

------
tillmannhgl
I think the idea of having three (or four or five) buckets of seniority is not
applicable for modern work any more. Leveling is too much about hierarchy and
too less about the actual impact. Beyond leveling is something what doesn't
need to be defined in a word, but is more about specific knowledge or
competence that is needed to solve a problem.

~~~
Spooky23
Sure it is, you gate underperforming people at the low bands and attrit them
out.

That’s why in the regular army you don’t see 50 year old Captains.

~~~
yibg
I do wonder about the wisdom of this up or out (to some level usually) some
times. For example, you can’t be SDE I at Amazon for 10 years. But why not? If
I’m doing a good job as a SDE I, I’m happy with the job and pay and just want
to keep doing it what’s the problem?

~~~
beefalo
Because they want people who will grow that they can promote because it's
really expensive to hire SDE III+

~~~
yibg
I don't think internally promoted SED III+ are any cheaper than externally
hired ones. If they were they'd soon go else where anyways.

~~~
cwp
It's really expensive to _hire_ at that level of seniority - even if the
salary is the same once they start, it also takes a lot of time and money to
get them to that point.

------
diN0bot
[https://roadmap.sh/backend](https://roadmap.sh/backend) \- I notice that this
doesn't contain anything about understanding abstraction, abstraction
barriers, managing complexity in problem v solution spaces, identifying "as
simple as possible but not simpler", etc. I don't even mean design patterns or
OOP, though those are nice applications. How things have changed. It's like
how there was a time when physics was witnessable visual and tactile grappling
with the world around us, and now it's become extreme math: the "programming"
joy of yore has been replaced by webdev legoing.

~~~
kamranahmedse
Thank you for the feedback. It's still a work in progress. It was mainly moved
from the repository[0] and needs to be updated. Plus it is lacking in a couple
of other sections also which we plan on improving. Please feel free to leave
your feedback and suggestions in the form of issues on the repository.

\- [0] [https://github.com/kamranahmedse/developer-
roadmap](https://github.com/kamranahmedse/developer-roadmap)

------
top_kekeroni_m8
Senior level developers are usually people with excellent domain and business
knowledge. How does one get a senior programming job without knowledge of the
field? I might consider myself a senior in my current job, but I wouldn’t
necessarily call myself that when applying to a new field.

~~~
Jestar342
IME autonomy is the primary measure of seniority. If you need mentoring, or
are completely uncomfortable being told "I don't know, can you figure it out
please?" then you definitely have an opportunity to grow.

There's a third kind of learning in software. The first two are technical and
domain, the third is abstract application and adaptability of your skills.
That latter one _only_ comes from experience. How do you efficiently learn
both tech and domain? Can you identity waste (time and/or resources) early?
Are you resourceful when seeking information? Are your questions and
discussions phrased in ways that maintain direction and brevity? So on.

~~~
BlargMcLarg
>IME autonomy is the primary measure of seniority

What if you're autonomous by heart, but the software is so huge and poorly
documented, as well as having lots of bureaucratic rules and gripes, that you
pretty much can't be autonomous? That's a reality for many developers, junior
or senior.

~~~
jasonpeacock
The idea that you can't be anonymous in such a situation is a "junior"
attitude.

The "senior" attitude would be to find ways to achieve autonomy _and_ improve
the situation. They would either succeed or determine the company doesn't
actually want a senior person in that role and move on.

In talking with senior people who have been in such situations, you hear
stories about their valiant efforts with partial or full results. When I talk
with junior people, you hear about complaints and wishes but little action
beyond their own work.

~~~
BlargMcLarg
Sounds very "no true Scotsman" and people are taking this way too senior vs
junior. If you are a junior wanting to become a senior or prove themselves as
being more than junior, but find yourself in scenarios where management isn't
actually asking for a senior but a rockstar, domain-expert medior going under
the title of senior, what do you do? Continuously hop jobs until you get
lucky? Wait until you finally rack in enough years so society deems you worthy
of senior? Most situations I find myself in don't want to be fixed. Trying to
take charge comes across as trying to tell the driver how to drive, or take
the wheel myself, when its their car we're riding in. And using my own car is
akin to starting my own company or going contracting.

>The "senior" attitude would be to find ways to achieve autonomy and improve
the situation. How is this a "senior" attitude anyway? This should be the
_default_ attitude of any self-respecting employee, and I personally had this
mindset from day 1 of my career. Who in their right mind wants to be either
dependent or not make their life better? That's not junior, that's lazy.

~~~
dasil003
The needs of a senior engineer vary by org and culture. It's only a "no true
Scotsman" thing if we insist that there must be a single objective definition,
but such a thing is a total myth. I've hired devs with the senior title that
barely kept up with college interns. Similarly I've seen folks with 5+ years
fail to meet expectations for baseline engineer with clear coaching and PIP
over 6+ months, leave the company and land their first "senior engineer" a
month after being fired. I've seen senior google engineers who failed to
thrive in an open-source stack since they were used to being hand-held by
Google's internal tooling and wealth of expertise they could turn to for any
issue that was outside their immediate wheelhouse.

Within a company it's possible to have some standard, and a lot of companies
work very hard to make their levels as objective as possible, but even then
it's incredibly difficult to reduce a large set of diverse individuals working
on diverse projects with diverse skillsets down to a single number.

All that said though, it doesn't matter how good your technical skills are, if
you can't unblock yourself with cross-functional efforts, or figure out a way
to optimize a bad situation, you will not be considered for the fast-track in
most large engineering orgs. If the situation you find yourself in is truly
intractable as you suggest, then the senior mentality would be to cut your
losses and find a new situation.

------
arcanus
This is a good read. Anyone have recommendations for reading on the next steps
past 'senior'? This is called various things, like principal engineer, fellow,
etc. at bigger organizations.

Some people's careers might take them to the point where they do not write
much code, and act as a key interface between executives and programmers. If
they aren't a manager and can still be on the IC track, where they provide
technical leadership, coaching, vision, etc.

~~~
daxfohl
At Microsoft, I'd say roughly senior is able to lead a project end to end.
Principal is being able to represent a department and take responsibility for
making sure multiple projects are run smoothly, developers are growing,
outages are prevented. There's some overlap, and it's really just a matter of
scale and trust. As you produce results, you get more trust and more
responsibility for larger things. Progressing through principal is much more
about paying attention to the bottom line. It's your responsibility to make
sure the things you're doing are things that either customers are willing to
pay for, or things that greatly reduce COGS. These are all achievable by
mortals so long as you're hard working, determined, and focused on the right
things.

Beyond that, Distinguished Engineer I'd say is reserved for someone who works
at a level beyond the most of us, whose work has produced multiple patents or
been widely influential across the company or the industry at large. Fellow is
someone who has done this continually throughout their career.

------
INTPenis
Everyone's talking so positively about seniority but I've seen it backfire
horribly.

I am sure to catch backlash for this next statement but a lot of times it
seems that people with kids stop caring. Which is only natural,
understandable, because biologically something has arrived that takes all
precedence.

But to me as an outside observer and co-worker I see a person stagnating.

I've had to teach senior architects not to send private ssh keys to each other
and instead use public keys. How to do basic naming schemes for servers. And
those are just two "timeless" examples. I won't even mention all the modern
tech they ignore because they haven't cared about their profession for the
last 15 years.

Edit: For context I am mid 30s and these people are late 40s or early 50s. I
am not stupid enough to think I can avoid this in the future.

~~~
inertiatic
Competent people stop caring once they don't have anywhere to go, career-wise.

Incompetent people stop caring once they're sure they won't be found out.

Kids have nothing to do with it.

~~~
pengaru
> Kids have nothing to do with it.

Kids do tend to consume time which may have otherwise been used for work or
work-related personal development.

Time is finite, it's not just a binary matter of caring vs. not caring, it's
also higher priorities displacing lower ones.

~~~
inertiatic
Kids change your life.

Whether they use up your energy or they force you to reevaluate and drop
unimportant things to focus on what matters, depends on your individual
experience.

For myself, having a child made me extremely career focused.

------
29athrowaway
This article conflates personality traits and attitudes towards problem
solving with seniority.

It also speaks of overengineering, which is a highly ambiguous and subjective
term that rarely leads to constructive feedback. It translates to "you are
overdoing your job", rather than how you are overdoing your work. It is not
actionable feedback.

Asking for help is not a trait of junior engineers. Asking for help in a non-
structured way, without providing useful context or asking for help without
making a reasonable attempt to understand the problem first is something that
you would expect of a junior person. Not asking for help while being blocked
for a long period of time is also a trait of a junior person. Being able to
leverage expertise from team members is a trait of a senior person.

Now, about this:

> They have respect for the code that was written before them. They are
> generous when passing judgment on the architecture or the design decisions
> made in the codebase. They approach inheriting legacy code with an
> "opportunity mindset" rather than a complaining one.

No. Here the author is conflating seniority with blind personality cult
loyalty. If something is suboptimal or wrong in a problematic way, then just
go ahead and say it when the opportunity arises in the best way you can.

Even in the early days of software, people realized the importance of good
engineering practices. If your legacy code doesn't reflect that mindset, it is
not worth praising. The article author himself recognizes that dumping work on
other people is a trait of junior engineers, but applies it inconsistently in
this case. Senior maintainers may be able to identify legitimate tradeoffs,
but when a code base is consistently bad, especially when it was already bad
in its historical context, don't expect a lot of praise for the code or the
authors.

------
barrkel
What's not covered here is overlap between what an engineer knows and what the
business needs; and especially knowledge of the business's existing codebase
and architecture.

If you know what exists and how it's put together (and this can come from
tenure or experience in a vertical) you'll be far more productive. Tasks
require less research and are implemented leveraging more of the existing
design, possibly with a few tweaks in key locations, where an engineer with
equivalent or even more talent may rewrite or reinvent a whole module owing to
less deep understanding, and actually add less value.

This can lead to an engineer deserving to be senior in one company but not so
senior in another. It's also a source of technical debt and risk when
employees turn over. Knowledge is lost and merely hiring a replacement doesn't
restore velocity. Sometimes modules need to be rewritten and replaced to get
back to a good place.

~~~
scarface74
I’ve seen this far too often. Theoretically, your pay should be a combination
of what you could get for your same skill set on the open market plus getting
paid over the market value based on what you bring to the company based on
your domain knowledge and the relationships that you’ve built that allow you
to be more efficient than someone off the streets.

If you’re not careful, your marketable skills will become out of date, but
your salary keeps increasing because you’re very valuable to the company. Then
when the company lets you go after a decade, you will be out there competing
with people younger than you who have kept up to date and complaining about
“ageism”. I’m 45 FWIW.

------
narmihou
Aren't these two statements below contradictory when taken at face value? Both
under Junior dev.

Over-engineering is a major problem, often leading to fragility and bugs.

When given a problem, they often try to fix just the current problem a.k.a.
fixing the symptoms instead of fixing the root problem.

------
idoby
The actual content of the roadmaps doesn't seem to be in the GitHub repo so I
can't open PRs to correct typos.

~~~
kamranahmedse
Hey, everything is there at
[https://github.com/kamranahmedse/roadmap.sh/blob/master/cont...](https://github.com/kamranahmedse/roadmap.sh/blob/master/content/guides/levels-
of-seniority.md)

~~~
idoby
I was trying to open a PR to fix a typo in the devops map but the repo doesn't
seem to contain the text I want to fix...

------
HugoDaniel
People trying to find ways to justify paying less to programmers

------
k33n
The real truth is that none of these titles mean anything outside of a given
organizational context. Hilarious that the author felt the need to add "can
give feedback without hurting people" to the senior engineer bullet list. So
much wishful thinking here.

~~~
BlargMcLarg
There's some truth in your statement that most people do not wish to admit and
are quick to dismiss as "rebellious, arrogant juniors".

I generally see two kind of seniors. The first group is senior in terms of
experience and hard work. The second group got there only through obligation,
working for years without growing a lot. Unfortunately, I see most management
puts a hard cap on minimum experience before being a senior, so the former
group and the latter group become indistinguishable. Other problems include
Peter principle, where because someone got promoted to senior, he is now
attributed as a good leader, despite having no experience leading as a junior
before. Skills that are at best orthogonal are attributed to seniority,
despite the fact many junior and medior people may be better at teaching,
leading and mentoring others than their seniors. Nothing in the track
guarantees a senior ever has to practice or show their excellence in these
skills, either.

Furthermore, most people aren't doing interesting things. They get a
revolutionizing experience at work maybe once a month at best, if not far
longer. Couple that with an echo chamber and suddenly, they believe it is
normal to take 3 to 10 years to become an expert on fairly trivial domain
knowledge. We're not talking about top-of-the-line C++ programmers, ML
experts, people driving innovation, veteran software architects or whatever.
We're talking your average CRUD web programmer who did some backend, maybe
some frontend. We're talking people who believe one can only be senior being
able to deploy an application from scratch into a new environment, thinking
this takes at minimum 3 years to learn when in reality, you could pick up a
guide how to do this today. The only real thing you'll miss out are office
politics and navigating in a group setting. The former is so volatile and
context-dependent, you might as well learn it on the fly or wait until 15
years have passed by and pretty much any possible situation has come up. The
latter is severely overstated in difficulty and most people will pick this up
in no time, unless the team is dysfunctional to begin with.

~~~
k33n
Really enjoyed your comment. Your comments about lack of
innovation/interesting problems at most places are spot on. And "senior"
developers being hung up on CRUD techniques is laughable to anyone who has
solved truly difficult problems.

------
psim1
This interesting essay is marred by bad grammar.

Do you want to rise in the ranks? Learn to write well. Documentation, blogs,
email memos, proposals, etc.—this is the evidence of accomplished seniority.

~~~
sputr
His name is Kamran Ahmed and he's from Dubai.

This comment didn't make you look good. Not even a little.

~~~
psim1
The point of discussion here is not to make oneself look good. Do you disagree
with my statement?

~~~
scarface74
English is my first language and I didn’t notice any off putting grammar
errors.

That being said, especially for a non native speaker, I don’t judge their
ability to communicate by their ability to write perfectly grammatically and
idiomatically correct English. It’s whether they got their point across.

------
mberning
This is a very good overview. One thing I would add for the junior and mid
level developer is “attitude towards work in general”. One thing I see
commonly in many junior and some mid level engineers is an inappropriate
attitude towards work vs their career aspirations. For example, they will
treat their job like an hourly employee with no skin in the game, and then
complain about raises, promotions and bonuses. You don’t need the best
development skills to show up on time, be diligent, work hard, and be a good
teammate.

~~~
eropple
As somebody pretty firmly in the staff/principal firmament (when not in a
management role), I absolutely, positively do not care in the slightest and at
least low-key discourage people I mentor from having "skin in the game."
Unless you have entire points in the company, "skin in the game" is a handle
by which people can manipulate you to do things that are bad for you, your
health, and your career. It's not that it should be an adversarial
relationship, and one of the really nice things at my current job is that it
it's the first I've ever been at that _isn 't_ (it's a genuinely good place to
work, with empathic and decent upper management, and they get a lot more out
of us for it)--but most are and it's not a line employee's fault and it's
foolish to not recognize the game being played. Professionalism doesn't
require emotional attachment and it shouldn't be expected or too generously
given. Show up, do your job, do it well. But make sure you are building
towards the next one and don't let the current one minimize your ability to
get the next one.

As your manager I might and generally do care about your personal growth, but
it's not because it relates to your KPIs, it's because you're a person and I'm
in a place to help you improve and I should do that because doing that is
good. And, selfishly, I want to find and build great people to work with in
the future. But at most places, me doing this is in tension with what my
bosses would like me to do. Which is mold you into a _better employee_ over
the expected time horizon of your employee, irrespective of if that makes you
a better developer or technologist. (I've learned that pushing people to be
better technologists makes better employees too, but my experience is that
most management doesn't get this and so we are mostly to be not trusted on
that score.)

