When did this "junior/senior" lingo get cool? I don't remember it being used when I was young. Maybe the leet code trend brought on a sort of gamification of the profession, with ranks etc..?
As a 51 year old, I hate when other old people think that “back in my day things were different”
> Evans has held his present position
with IBM since 1965. Previously, he
had been a vice president of the Fed-
eral Systems Division with the man-
agement responsibility for developing
large computing systems; the culmina-
tion of this work was the IBM/System
360. He joined IBM in 1951 as a
junior engineer and has held a variety
of engineering and management posi-
tions within the corporation
The title has always existed. I meant the obsession about being a "a junior" or "a senior", like gaining an achievement in a video game or something. I just thought every young person was a junior engineer and every old person was as senior engineer.
You don’t get to be a senior engineer just because of tenure. It’s not gaming the system to expect a level to be based on the amount of responsibility and not just from getting 1 year of experience 10x.
You want a promotion because you want more money. Even though I have found the difference to not be that great on the enterprise dev side. But in BigTech and adjacent, we are talking about multiple six figures differences as you move up.
I work in consulting and our bill rate is based on our title/level of responsibility. It kills me that some non customer facing consultants want to have a “career track” that doesn’t involve leading projects and strategy and want to stay completely “hands on”.
We can hire people cheaply from outside the country that can do that. There is an IC career track that is equal to a director (manager of managers). But you won’t get there hands on keyboard.
The bigger the company the less impressive "senior" is. There are probably three levels of staff above it and then distinguished super fellow territory.
A senior software engineer can easily make $300-400K+ at BigTech that’s “impressive” enough to me.
On the other hand, a “senior” working at a bank or other large non tech company will probably be making less than $175K if you aren’t working on the west coast.
When I talk to a senior: “hey we got this initiative, I know only little about it. Can you talk to $stake_holder figure out what they need and come back to me and let me know your design ideas, how long you think it will take, etc”.
I can do that with a few seniors and put Epics together and they can take ownership of it.
For a junior I have to do a lot more handholding and make sure the requirements are well spelled out
It’s way more than a “pay grade” for any company with real leveling guidelines.
This jibes with both my personal experience at BigTech, knowing the industry and various publicly available leveling guidelines. Sone are more granular
So are you really arguing that tech companies that pay top of the industry don’t require that you demonstrate that you can handle responsibility that requires you to be able to work at a larger scope, impact and dealing with ambiguity and go through a promotion process with a promo doc?
Are you saying that when you interview for one of those tech companies that they don’t level you according to your past experience?
Yes I know the answers to all of these questions from both personal experience of interviewing and hiring at one BigTech company and ignoring outreach from another’s hiring manager who I had worked with in the past.
(At 51, I would rather get a daily anal probe with a cactus than ever work at a large company again and I am damn sure not going back into an office)
You've put a lot of words in my mouth, and I don't know why.
What do I suggest? I suggest that big organizations have pockets of careful, competent folks. But in general a large company tends to be all fouled up. They do a lot of things pretty much randomly. Some stuff happens the way a new graduate has a right to expect, and the way many HN commenters insist it has to go.
But a lot of other shit just ... happens. People get promoted because they have another offer from another fouled-up company, or because the boss thinks they're awesome (but sometimes the boss is dumb), or because they talk the talk exceptionally well, or because they happen to get the attention of someone 2 or 3 levels up, or whatever.
Is any of that controversial? What am I missing here?
Do people not still read Catch-22? Or has it been proved wrong or something? Or take that mysterious cactus that you mentioned in connection with large companies. What's that about? Because the cactus sounds bad.
I have only worked for two large companies in my career - both Fortune 10 companies when I worked their - General Electric and Amazon.
At GE? Sure things are random. But it was also just another random enterprise company where it really didn’t make sense to work toward a promotion just to make $10-$20K more. You would be better off just getting another job (which I did after 2.5 years). There were no published leveling guidelines or procedures.
But I can guarantee you that a random mid level developer is not going to walk up to their manager with a competing offer and be handed a promotion at any of the large tech companies. The manager by themselves can’t determine a promotion. There are promo docs, committees, recommendation requirements. Etc
At 51, with just me and my wife, grown kids and already had the big house built in the burbs that sold for twice what we bought it for 8 years earlier and we downsized to a condo one third the size in state tax free Florida, the juice ain’t worth the squeeze.
But if I were 22 and had a choice between wallowing in enterprise dev making 90K doing CRUD apps or making $160K out of college and over $200K at 25, I would play the game with the best of them.
My own anecdote is that outside of BigTech now, I’m a staff consultant working at a 3rd party AWS consulting company making the same as a 25 year old SA that I mentored when they were an intern at AWS and the first year they came back
I like this. I more generally look for reduces chaos.
I’ve seen the pursuit of disambiguation employed to deadlock a project. Sometimes that’s the right thing to do—the project sponsor doesn’t know what they want. But many times the senior needs to document some assumptions and ship something rather than frustrating the calendars of 15 people trying to nail down some exact spec. Knowing whether to step on the brake or the gas for the benefit of the team and company is a key senior trait.
This is a yes, and to the article; building without understanding the problem usually will increase chaos—though sometimes the least effort way through it is to build a prototype, and a senior would know when to do that and how to scope it.
A very important skill for Senior engineers not mentioned in the article is an ability to take the initiative on something. For example, when a dev sees a bug in an area of code they aren't responsible for and thinks "I'll raise an issue for that and mention it to the product manager so we can get it fixed" instead of "Oh, a bug", then they're starting to show that senior mindset. It's a desire to make the whole of the software good rather than just the little bit they work on good.
I have literally never seen or thought of this as “senior” thing. if anyone on the team regardless of their seniority does not operate this way they will see a quick exit to some other place
Great article. The key things often missing in meetings discussing a vague problem is do we really understand the problem and how do we make concrete progress. Its a hard skill and often just comes through experience - being able to put yourself in the user's shoes to understand their problem, and knowing based on past experience, how to execute. That is the value of seniority.
idk about titles, but my basic thought is that when you are less experienced, you're paid to do things, and when you are more experienced, you're paid to know things.
These are typical questions I ask when I’m interviewing a senior developer:
“Tell me about a project you’re most proud of?” Then I’m going to start asking questions about your decision making process, how you dealt with complexity and ambiguity, etc.
If all you did was pull well defined tickets off the Jira board, you’re not going to be able to answer that question well and you aren’t the type of person I’m going to delegate a very ambiguous assignment where you have to make good architectural and organizational decisions and have to deal with “the business” to disambiguate.
The next question would be “Looking at your resume, I see you have $x years of experience, if you could go back to one of your earlier projects, what choices would you have made differently knowing what you know now?”
If you haven’t led any major initiative, what are you going to say? “I would have pulled more tickets off the board?”
I interviewed someone from AWS at my last job, he thought he was a shoo in especially after he looked on LinkedIn and saw that I was from AWS. I guess he thought he was going to be reversing a binary tree.
No matter what I asked, he couldn’t describe anything he had done of note except be on a team who did stuff. I asked him had he led any features, presented any “six pagers” internally, blog posts on the AWS site, presentations - he had done nothing.
I passed over him for a guy at an unknown company who could talk about where he “took ownership”. That’s one of the Amazon BS Leadership Principals.
Hell I had a public footprint at AWS after only 3.5 years I had been there as a mid level L5 employee.
I think a lot of people in the comments are getting hung up on titles and missing the real point of the post. The headline probably didn’t help with that.
The post actually does a great job of highlighting a genuinely valuable skill that the best engineers practice regardless of their title. In particular, “reducing ambiguity” is something I believe would be really beneficial for many early-career engineers to intentionally develop.
Meanwhile the industry standard definition since the 80s:
- Junior - someone who can work under guidance. - Regular - someone who can work alone. - Senior - someone who can guide others.
It's just a pay grade. Please folks stop trying to analyze "junior," "senior," and so forth. It's just something management told HR to write down.
When did this "junior/senior" lingo get cool? I don't remember it being used when I was young. Maybe the leet code trend brought on a sort of gamification of the profession, with ranks etc..?
As a 51 year old, I hate when other old people think that “back in my day things were different”
> Evans has held his present position with IBM since 1965. Previously, he had been a vice president of the Fed- eral Systems Division with the man- agement responsibility for developing large computing systems; the culmina- tion of this work was the IBM/System 360. He joined IBM in 1951 as a junior engineer and has held a variety of engineering and management posi- tions within the corporation
Dated 1969
https://bitsavers.org/magazines/Computer_Design/Computer_Des...
Next meme that needs to die: “back in my day, developers did it for the love and not the money”
The title has always existed. I meant the obsession about being a "a junior" or "a senior", like gaining an achievement in a video game or something. I just thought every young person was a junior engineer and every old person was as senior engineer.
You don’t get to be a senior engineer just because of tenure. It’s not gaming the system to expect a level to be based on the amount of responsibility and not just from getting 1 year of experience 10x.
You want a promotion because you want more money. Even though I have found the difference to not be that great on the enterprise dev side. But in BigTech and adjacent, we are talking about multiple six figures differences as you move up.
I work in consulting and our bill rate is based on our title/level of responsibility. It kills me that some non customer facing consultants want to have a “career track” that doesn’t involve leading projects and strategy and want to stay completely “hands on”.
We can hire people cheaply from outside the country that can do that. There is an IC career track that is equal to a director (manager of managers). But you won’t get there hands on keyboard.
The bigger the company the less impressive "senior" is. There are probably three levels of staff above it and then distinguished super fellow territory.
A senior software engineer can easily make $300-400K+ at BigTech that’s “impressive” enough to me.
On the other hand, a “senior” working at a bank or other large non tech company will probably be making less than $175K if you aren’t working on the west coast.
For instance Delta
https://www.levels.fyi/companies/delta-air-lines/salaries
I'm deleting my hn account. Have a good day.
It really only matters on an individual level once you become a manager, and have both juniors and seniors to manage.
It matters to me as a senior+.
When I talk to a senior: “hey we got this initiative, I know only little about it. Can you talk to $stake_holder figure out what they need and come back to me and let me know your design ideas, how long you think it will take, etc”.
I can do that with a few seniors and put Epics together and they can take ownership of it.
For a junior I have to do a lot more handholding and make sure the requirements are well spelled out
How I became a staff engineer with 3 yoe making 140k/year
And making $25K less than a new grad at BigTech…
By 1 weird trick?
It’s way more than a “pay grade” for any company with real leveling guidelines.
This jibes with both my personal experience at BigTech, knowing the industry and various publicly available leveling guidelines. Sone are more granular
https://www.levels.fyi/blog/swe-level-framework.html
https://dropbox.github.io/dbx-career-framework/
The company I work for now has similar leveling guidelines, it’s also more granular.
But levels are defined by scope, impact, and dealing with ambiguity
Is pay grade. You can look this up.
So are you really arguing that tech companies that pay top of the industry don’t require that you demonstrate that you can handle responsibility that requires you to be able to work at a larger scope, impact and dealing with ambiguity and go through a promotion process with a promo doc?
Are you saying that when you interview for one of those tech companies that they don’t level you according to your past experience?
Yes I know the answers to all of these questions from both personal experience of interviewing and hiring at one BigTech company and ignoring outreach from another’s hiring manager who I had worked with in the past.
(At 51, I would rather get a daily anal probe with a cactus than ever work at a large company again and I am damn sure not going back into an office)
If I'm being honest, I sense some ambivalence about how perfect and rational big companies really are.
What do you suggest? They just promote people based on tenure?
You've put a lot of words in my mouth, and I don't know why.
What do I suggest? I suggest that big organizations have pockets of careful, competent folks. But in general a large company tends to be all fouled up. They do a lot of things pretty much randomly. Some stuff happens the way a new graduate has a right to expect, and the way many HN commenters insist it has to go.
But a lot of other shit just ... happens. People get promoted because they have another offer from another fouled-up company, or because the boss thinks they're awesome (but sometimes the boss is dumb), or because they talk the talk exceptionally well, or because they happen to get the attention of someone 2 or 3 levels up, or whatever.
Is any of that controversial? What am I missing here?
Do people not still read Catch-22? Or has it been proved wrong or something? Or take that mysterious cactus that you mentioned in connection with large companies. What's that about? Because the cactus sounds bad.
I have only worked for two large companies in my career - both Fortune 10 companies when I worked their - General Electric and Amazon.
At GE? Sure things are random. But it was also just another random enterprise company where it really didn’t make sense to work toward a promotion just to make $10-$20K more. You would be better off just getting another job (which I did after 2.5 years). There were no published leveling guidelines or procedures.
But I can guarantee you that a random mid level developer is not going to walk up to their manager with a competing offer and be handed a promotion at any of the large tech companies. The manager by themselves can’t determine a promotion. There are promo docs, committees, recommendation requirements. Etc
At 51, with just me and my wife, grown kids and already had the big house built in the burbs that sold for twice what we bought it for 8 years earlier and we downsized to a condo one third the size in state tax free Florida, the juice ain’t worth the squeeze.
But if I were 22 and had a choice between wallowing in enterprise dev making 90K doing CRUD apps or making $160K out of college and over $200K at 25, I would play the game with the best of them.
My own anecdote is that outside of BigTech now, I’m a staff consultant working at a 3rd party AWS consulting company making the same as a 25 year old SA that I mentored when they were an intern at AWS and the first year they came back
I like this. I more generally look for reduces chaos.
I’ve seen the pursuit of disambiguation employed to deadlock a project. Sometimes that’s the right thing to do—the project sponsor doesn’t know what they want. But many times the senior needs to document some assumptions and ship something rather than frustrating the calendars of 15 people trying to nail down some exact spec. Knowing whether to step on the brake or the gas for the benefit of the team and company is a key senior trait.
This is a yes, and to the article; building without understanding the problem usually will increase chaos—though sometimes the least effort way through it is to build a prototype, and a senior would know when to do that and how to scope it.
A very important skill for Senior engineers not mentioned in the article is an ability to take the initiative on something. For example, when a dev sees a bug in an area of code they aren't responsible for and thinks "I'll raise an issue for that and mention it to the product manager so we can get it fixed" instead of "Oh, a bug", then they're starting to show that senior mindset. It's a desire to make the whole of the software good rather than just the little bit they work on good.
I have literally never seen or thought of this as “senior” thing. if anyone on the team regardless of their seniority does not operate this way they will see a quick exit to some other place
Great article. The key things often missing in meetings discussing a vague problem is do we really understand the problem and how do we make concrete progress. Its a hard skill and often just comes through experience - being able to put yourself in the user's shoes to understand their problem, and knowing based on past experience, how to execute. That is the value of seniority.
Junior deals with "if" statements.
Senior deals with "what-if" statements.
<EoF>
> this isn’t talent, but practice
This. Totally agree. Seniority level it’s based on the volume of practice someone has. Period.
Oh, so it isn’t about know to solve any leetcode?
Good to hear it
idk about titles, but my basic thought is that when you are less experienced, you're paid to do things, and when you are more experienced, you're paid to know things.
Related: Job Titles are Bullshit (2024) https://news.ycombinator.com/item?id=39511732
When someone calls you senpai
This sounds cool but reality is much more boring than that. If your work title says "Senior" then you're Senior.
Based on a number of people I've worked with whose job title was Senior Engineer, it isn't that.
Sometimes that’s true. Sometimes it isn’t. This seems to be a discussion about the latter.
Until you get to a behavioral interview at your n+1 job…
What's that supposed to mean?
These are typical questions I ask when I’m interviewing a senior developer:
“Tell me about a project you’re most proud of?” Then I’m going to start asking questions about your decision making process, how you dealt with complexity and ambiguity, etc.
If all you did was pull well defined tickets off the Jira board, you’re not going to be able to answer that question well and you aren’t the type of person I’m going to delegate a very ambiguous assignment where you have to make good architectural and organizational decisions and have to deal with “the business” to disambiguate.
The next question would be “Looking at your resume, I see you have $x years of experience, if you could go back to one of your earlier projects, what choices would you have made differently knowing what you know now?”
If you haven’t led any major initiative, what are you going to say? “I would have pulled more tickets off the board?”
I interviewed someone from AWS at my last job, he thought he was a shoo in especially after he looked on LinkedIn and saw that I was from AWS. I guess he thought he was going to be reversing a binary tree.
No matter what I asked, he couldn’t describe anything he had done of note except be on a team who did stuff. I asked him had he led any features, presented any “six pagers” internally, blog posts on the AWS site, presentations - he had done nothing.
I passed over him for a guy at an unknown company who could talk about where he “took ownership”. That’s one of the Amazon BS Leadership Principals.
Hell I had a public footprint at AWS after only 3.5 years I had been there as a mid level L5 employee.
I think a lot of people in the comments are getting hung up on titles and missing the real point of the post. The headline probably didn’t help with that.
The post actually does a great job of highlighting a genuinely valuable skill that the best engineers practice regardless of their title. In particular, “reducing ambiguity” is something I believe would be really beneficial for many early-career engineers to intentionally develop.
age
Nah
Bro thinks this is unique to engineers.