Not automatic but historically a good but not exceptional developer would expect to make senior after maybe 5-8 years of experience. Someone who was still needing close supervision - which is what "junior" traditionally meant - after 5 years would be exceptional and it wouldn't reflect well on either the developer or the places they worked at the start of their career.
Of course this is about the level the employee is capable of operating at in absolute terms but hiring is relative. In an employee's market someone might be able to land a "senior" role before they're really ready for it. In an employer's market the average candidate who gets hired as a "senior" might have 10+ YOE. We've gone from one to the other recently and everyone's expectations will need to adjust accordingly.
> I think I would drive myself mad if I tried to live up to the crazy expectations of senior from most internet commenters.
And maybe that's the point of it. Senior without the title inflations is meant to be an actual high level position - not 50-100% of the company.
A lot of places have just replaced senior with staff/principal engineers instead, but senior used to be a well respected and unique title back in the days.
I agree with half of what you say. Senior should be a high-level position. It's a recognition of someone with solid skills and the ability to get things done.
But suppose a senior is someone who can work mostly autonomously under general direction from their management and tech leadership, which I'd say is a reasonable basic definition of what "senior" level has historically meant in software development. We would expect to see a lot more people reaching that level and sticking around on a tech career path now because of the rapid growth in the industry and the greater awareness that people can be a high-level IC but not have much interest in formal leadership or management roles.
Moreover there is no rule that says an employer should hire mostly juniors, some mids and only a few seniors. Good seniors are almost always disproportionately cost-effective if you can manage to hire them. The trend for rapid job-hopping has left juniors as an almost worthless hire in many cases because they probably won't be around long enough to make a good contribution in return for all the early overheads they incur.
There is definitely a longer formal tech track in large organisations now. I'd say it used to be more that you reached senior and then any other responsibilities like leading a team or dealing with large-scale software architecture issues were kind of attached. So historically you'd associate those higher responsibilities with "senior" people where today those with the skills and experience to do them probably have higher job titles like lead/staff/principal instead.
So I'm not sure senior has been deflated or replaced by staff etc. It's just that senior used to be the top of three levels for many employers but now there's more recognition that your development doesn't just stop after a few years and "senior" today mostly means "first few years as a senior" in old terminology.
> But suppose a senior is someone who can work mostly autonomously under general direction from their management and tech leadership, which I'd say is a reasonable basic definition of what "senior" level has historically meant in software development.
That's where I disagree. A senior should do a lot more than that. Seniors would mentor and train juniors. Software or not - that's how it's traditionally been.
What you describe is more like an engineer (no senior). Juniors are the 1s that can't work autonomously. When you are recognized as fully fitting the role you're just that. A senior then excels the role.
> We would expect to see a lot more people reaching that level and sticking around on a tech career path now
What does this have to do with what roles are available in an organization?
I start a company. I have 1 CTO, 1 tech lead, 2 seniors and the rest are engineers. What level someone is at should not impact what I call the titles available, but to suit the current market, instead we have 1 CTO, 1 principal engineer, 2 staff engineer, 1 tech lead, some seniors and a few engineers. Same same. No 1 actually grew additional roles.
It's all a trick to make people think they've levelled up.
I agree that was typically also something that came in at senior level.
Maybe it's a regional thing? I'm in the UK. I'd say it was fairly standard here for a junior to be someone in the first couple of years on the job who was still learning the ropes and probably couldn't do much beyond very basic grunt work without the assistance of someone more senior. Losing the "junior" label came when you got beyond the near-full-time hand-holding and started doing routine stuff independently. The "senior" label came when you could do the less routine or more difficult stuff mostly independently as well.
What does this have to do with what roles are available in an organization?
It means an organisation that wants to hire a senior-heavy team can now do so. That wasn't realistic for most organisations a decade ago because there weren't enough seniors to go around.
> It means an organisation that wants to hire a senior-heavy team can now do so. That wasn't realistic for most organisations a decade ago because there weren't enough seniors to go around.
There are 2 distinctions and that's what might be confusing. 1 is your experience/level and what you're referring to. The other is the roles an organization offers.
I might have 50 years of experience but if the other roles are taken by more qualified people in THAT organization I can take a normal engineer route. Doesn't have to be senior. It doesn't make myself not qualified to even be a CTO elsewhere.
The roles are fixed. It has to do with budget, balanced, etc. Having all seniors might mean fights and everyone wanting to contribute and pull the project in different directions. A good balance is needed. A senior heavy team might not be good just because you can.
I understand (and agree with) the distinction you're making. An employee's level isn't necessarily the same thing as the level an employer needs for a specific role. The latter sets a desired minimum for the former. And realistically the former usually implies some kind of desired minimum for the latter if only because working at a much lower level than you're capable of will reduce compensation and slow career progression.
Where we perhaps disagree is your final paragraph. The roles might be fixed but there is no rule that says they have to be. Usually things like budgets and the work that needs to be done that are fixed for the team as a whole. An employer might have multiple hiring options available that fit those constraints - for example hiring a smaller team of more senior developers or a larger team with a wider range. My argument above is that if you can hire a smaller team of good senior people then this is often cost-effective.
I don't really recognise the picture you're painting of a senior-heavy team being prone to conflict. A big part of that ability to operate autonomously that I suggested characterises senior developers is learning how to communicate and collaborate effectively without needing constant intervention from above or heavy formal development processes.
What you described seems like what happens if you want a senior-heavy team, hire people who aren't at that level yet, then still manage them as if they were seniors. The team doesn't reach consensus and get behind its choices collectively. However it also doesn't have the stronger leadership and safety rails that less experienced developers might need to be effective. I agree that situation is bad but it's not what I was advocating before.
> My argument above is that if you can hire a smaller team of good senior people then this is often cost-effective.
> I understand (and agree with) the distinction you're making.
Isn't this contradictory?
That's the trap we're stuck in. I remember Amazon HR saying their Senior titles are the equivalent of Staff Engineer titles elsewhere.
You can hire a highly experienced small team and pay each of them more. They don't all have to be "senior" in title and responsibility. They're just engineers. Fixed budget divide by the number of people (roughly) has nothing to do with titles. It only does according to some system where compensation is tied to titles.
You've said you understand the distinction but then some sentences later have just walked it all back.
> What you described seems like what happens if you want a senior-heavy team, hire people who aren't at that level yet, then still manage them as if they were seniors.
I repeat, you're after an experienced/skilled team - not senior-heavy. E.g. you may need someone highly experienced in React and Rust with 50 years experience. It doesn't make them senior. Working autonomously doesn't make you senior.
This is really startup / tech titles as a whole. If anything engineering has avoided the rampant title inflation that has been commonplace among other departments (try finding a sales rep who isn't at least a senior / director).
Of course this is about the level the employee is capable of operating at in absolute terms but hiring is relative. In an employee's market someone might be able to land a "senior" role before they're really ready for it. In an employer's market the average candidate who gets hired as a "senior" might have 10+ YOE. We've gone from one to the other recently and everyone's expectations will need to adjust accordingly.