7 ms·

My gripe with the "Senior Engineer" title is that I've NEVER met anyone with 5+ years experience who didn't view themselves as "senior". Usually 3+ years. In

My gripe with the "Senior Engineer" title is that I've NEVER met anyone with 5+ years experience who didn't view themselves as "senior". Usually 3+ years. In a market where there are more job openings than employable candidates, and competition for talent leads to rampant ego-stroking and title-inflation... the term "senior" has become just another word for "competent". Someone who can work independently without hand-holding. So how do we verbally distinguish that from, "No, I really DO mean 'senior'"? Most people get 40+ working years in a career. How do you encourage humility and self-awareness, so that people don't honestly believe they've reached the 90th percentile after the only first 10% of that journey?

jerf 10y ago
Write into the job description what you actually expect from the engineer. Sadly, we don't have the shorthand you might expect in other industries, so, spell it out. "Expected to be able to drive product requirements and fundamental architecture, interact at a peer level with product and project management, mentor other team members, and make wise use of resources." Add other criteria for software reliability, security, performance, backwards compatibility, etc. as appropriate to your domain. Someone who may think they're "senior" will if they are realistic realize they haven't done that.
justinhj 10y ago
I work in the video games business and for us (at least at the better companies I have worked at) the title senior programmer is not based on years of experience. Usually it entails being able to work without supervision to design and deliver complicated features on time. It requires someone who is up to date with industry developments and best practises, who can take lead responsibilities but not always. Strong mentoring is another plus. I've worked with people in their late 30s that are still intermediate level. However there is a strong correlation with years and senior level, because those that stay in the business are the ones that thrive and succeed, whilst those who struggle to advance tend to quit and take more suitable work.
- 20andup 10y ago
  "those that stay in the business are the ones that thrive and succeed, whilst those who struggle to advance tend to quit and take more suitable work." That depends on the company they are working for though. I have seen people (from tech and non-tech roles) tell me they are seniors/managers because they have X-years of experience. More often then not, if someone needs to tell me they have X-years of experience rather than showing through example, I roll my eyes, and stay away.
- xiaoma 10y ago
  > "I've worked with people in their late 30s that are still intermediate level." At what age did they start? I've worked with people who were just getting started in their late 30s after a career change or kids growing up enough to become more independent, etc.
  - justinhj 10y ago
    I worked with a guy that was intermediate in his mid 30s after around 10 years experience. Conversely there was a 50 year old guy who became a programmer after he moved to my country and couldn't practice as a doctor. He was senior after about 5 years
  - deleted 10y ago
    [deleted]
brian-armstrong 10y ago
It's far more than the first 10%. Most engineers don't stay in the engineering track for long, and there are almost no lifelong engineers. 5 years of experience is probably closer to 50%+ of the journey.
- StevePerkins 10y ago
  > Most engineers don't stay in the engineering track for long, and there are almost no lifelong engineers. That is absolutely absurd. Plenty of tech titans and small startups have architects and senior devs in their 40's and up (I'm one, and at trade conferences I'm hardly even an outlier). Not to mention that 90% of the industry is in the "enterprise" world (seemingly invisible to much of HN's readership), which is largely composed of devs in their 40's, 50's, and 60's. The high-octane older guys often go into consulting in their later years, where they're billing at $200-400+ an hour while giving technical direction to a team of warm bodies fresh out of school (or off the boat). If you seriously believe that engineering is something that you do from age 25 to 35, before starting your "real career" in PowerPoint, then that's incredibly sad. Why not just go the MBA route to begin with?
allengeorge 10y ago
Allow me to offer myself as a counterpoint ;) I've worked for well over 3 years (8ish now?) and there's a lot I've yet to learn about when to take one design approach vs. another, how to identify risks early, etc. etc. And, for what it's worth, I agree: one should not be considered "senior" after 3, or 5 years. Actually, tenure matters less than perspective and problem-solving approach.
- alexbanks 10y ago
  Some (me) would argue that tenure should not be considered when deciding a developer's skill.
  - collyw 10y ago
    For certain types of problem that may work well, but for me, learning from my mistakes has been where I learned a lot.
    - alexbanks 10y ago
      Totally, but learning from your mistakes is not necessarily tied to years at a desk. edit Also, we've all met that dev that just "gets it" and can be extremely productive regardless of time at a job/company/project. That dev also "got it" when they were pretty new to the industry.
  - StevePerkins 10y ago
    I think that the number of different companies you've worked for (and the diversity in how they operate) is more important than the raw number of years you've worked. Also, how your role has grown or varied from job to job. Rookies worry too much about "job hopping". I can't count the number of people I've interviewed who had "10 years experience"... but really they just had "the same year 10 times".
    - alexbanks 10y ago
      More jobs = more diversity = more experience, no? Both models are flawed I think, as 10 jobs in 10 years brings a ton of understanding of the overarching principles of working as a dev, but has a total lack of long-term team success. 2 jobs in 10 years brings an understanding of that long-term team success but a relatively small window into dev jobs as a whole.
alexbanks 10y ago
The problem is that "senior" is entirely relative to the engineers that surround the developer in question. A senior dev at Company X may not be a senior at Company Y, regardless of how many years in the industry or productive at Company X they were. The problem also comes up for the 3-5 year mark when pay is involved. At my current company, it was impossible to make a certain salary without being promoted to Senior. The bigger problem was that the company has a slightly unrealistic view of the market, and to get any decent talent you'd have to be in the Senior pay bracket. Ultimately I think the best solution is to screen appropriately and decouple salary from title. I think the best model would be to never hire anyone as a Senior, but let the Seniors emerge.
- ascotan 10y ago
  I've been in that company. The problem is that without any leadership, every one is a leader. The practical result of this is that software gets partitioned into the 'parts that the idiots work on' and the 'undervalued but core business logic'. I also feel that this model of hiring is emphasized by the craze over agile (and particular SAFE) where all the engineers are supposed to be like lemmings that take orders from product owners. If you get the right team I suppose this is possible to do, but the lack of senior leadership on a team (and it's deferral to non-technical people like scrum masters and product owners) leads to unnecessary bikering among engineers on the 'right' way to solve a problem.
  - alexbanks 10y ago
    So I guess I don't mean "hire a bunch of devs and see who emerges as a leader." I guess in my head it works out like you already have a group of "seniors," "architects," etc. And when a new dev is hired, they don't get to just dive into the ranks of Sr/Arch. but should instead have to work to get there just like the original Sr/Arch devs did. But you're right, there is no perfect system.
  - nilkn 10y ago
    I don't fully understand why what alexbanks wrote implies that there is no leadership. It just means that new hires are not placed in leadership positions right out of the gate. There will certainly still be a strong leadership structure in place. As far as I can tell, the company I'm at follows the model alexbanks described, and it seems to work quite well. We generally do not hire people on in senior or lead roles. If someone has 15 years of experience and they're a team lead at their previous job, the chances are still very high they'll have to start as a "normal" developer with us. (Notably, we do not tie salary to title. A "software developer" can have an arbitrarily high salary if needed.) If they demonstrate the capacity for leadership, we will identify that and very quickly offer them more responsibility and promotions whenever the opportunity arises.
SatvikBeri 10y ago
There are many, many more developers today than there were 20 years ago. As a result, the median amount of experience is less than 10 years, which means that 5+ years actually is relatively experienced. Furthermore, I observe people being substantially more effective when they're 5 years in than 1, and again when they're 10 years in. Really it seems like we just need more granularity than "senior" or "not senior."
mianos 10y ago
I think the Dunning Kruger effect comes in here. https://en.wikipedia.org/wiki/Dunning–Kruger_effect https://en.wikipedia.org/wiki/Dunning–Kruger_effect After 3 or 5 years you don't really know what you don't know. A lot of people think they are experts after 5. After 10 you will see all the mistakes you have made and have a rough idea of just how little you know.
- tamana 10y ago
  That's not what DK means, which is interesting because you liked directly to the article that explains it.
- tedmiston 10y ago
  The way I look at it these days is: I can manage to do anything related to an API or app. The polish that comes after the 2nd, 3rd, 5th, 10th years is just doing things more elegantly and with better tooling. For me, it's mostly been about stronger separation of concerns. That's my perspective at 3 years into startup software engineering.
  - Swannie 10y ago
    Clue: it's not about the code. This was the point of the original article.
lliamander 10y ago
I think a large part of this is that we didn't have a technical career ladder until recently, and that a "seniority" has different meanings depending upon whether the company treats software development as a strategic business asset[0]. Now that we have technical career paths where one can expect to continue as technical individual contributor, the official "Senior Engineer" title falls roughly in the middle (slightly on the lower side) of the career ladder[1]. I'm generally OK with this personally, so long as we distinguish between the title "Senior Engineer" and the role "senior engineer". The role I would equate to Randall Koutnik's "Finders"[2]. [0]I talked about this in a little more detail on another thread: https://news.ycombinator.com/item?id=11545294 https://news.ycombinator.com/item?id=11545294 [1]http://changelog.ca/log/2013/08/09/software_engineer_title_ladder http://changelog.ca/log/2013/08/09/software_engineer_title_l... [2]https://rkoutnik.com/2016/04/21/implementers-solvers-and-finders.html https://rkoutnik.com/2016/04/21/implementers-solvers-and-fin...
- serge2k 10y ago
  > the official "Senior Engineer" title oh right, the OFFICIAL one. Sure. > falls roughly in the middle (slightly on the lower side) of the career ladder[1]. Not really, as the upper levels aren't reached by most people.
  - lliamander 10y ago
    > oh right, the OFFICIAL one. Sure. Not official in the sense of "there is some standards committee making these designations", but it seems to be a commonly accepted practice that the title of "Senior Engineer" is assigned to someone who "is capable of being given a high level (and often vague) task, and work completely independently on it and finish it" but not anything more. But my main concern was distinguishing between the title and the role. When I think of the role, I think we generally consider someone to be senior when they can: a) work through very thorny technical problems and find novel solutions b) connect technical solutions to the needs of the business c) provide leadership or mentoring to other engineers Like or not (I don't, personally) the title and the role use the same words but mean different things. > Not really, as the upper levels aren't reached by most people. I'm not clear on what your point is. Is it in the middle of most people's career? No. Is it in the middle of most technical career ladders (as used in various tech companies)? Yes. My point is that in places where there is a technical career ladder, there are titles that do actually reflect (what I consider to be) the role of a senior engineer. This is how tech companies get around the fact that convention has lowered the expectations of the title Senior Engineer. The core problem is that there is confusion about the relationship between title and role. The OP is trying to fix this confusion by raising the standards of the title to match the role (by explaining what the role really entails). I'm just trying to clarify the conventions set by the industry so that people can plan their careers accordingly.
ascotan 10y ago
I remember a guy we interviewed that was 1 year out of college and was a 'senior software engineer' because at his previous company he was the only developer. As such they made him the senior SE. The same can be said of 'Lead engineer' or 'Tech Lead' where there are 2 people in the group and you're the 'Lead' (whatever that means).
serge2k 10y ago
> How do you encourage humility and self-awareness, so that people don't honestly believe they've reached the 90th percentile after the only first 10% of that journey? Why would senior by the 90th percentile?
deleted 10y ago
[deleted]
TheCoelacanth 10y ago
Why would "Senior Engineer" mean someone who is at the 90th percentile? Anywhere that gives out the title "Senior Engineer" to someone with 3 years of experience will certainly have many higher titles, so what's the problem?

jerf 10y ago

Write into the job description what you actually expect from the engineer. Sadly, we don't have the shorthand you might expect in other industries, so, spell it out. "Expected to be able to drive product requirements and fundamental architecture, interact at a peer level with product and project management, mentor other team members, and make wise use of resources." Add other criteria for software reliability, security, performance, backwards compatibility, etc. as appropriate to your domain. Someone who may think they're "senior" will if they are realistic realize they haven't done that.

justinhj 10y ago

I work in the video games business and for us (at least at the better companies I have worked at) the title senior programmer is not based on years of experience. Usually it entails being able to work without supervision to design and deliver complicated features on time. It requires someone who is up to date with industry developments and best practises, who can take lead responsibilities but not always. Strong mentoring is another plus. I've worked with people in their late 30s that are still intermediate level. However there is a strong correlation with years and senior level, because those that stay in the business are the ones that thrive and succeed, whilst those who struggle to advance tend to quit and take more suitable work.

20andup 10y ago
"those that stay in the business are the ones that thrive and succeed, whilst those who struggle to advance tend to quit and take more suitable work." That depends on the company they are working for though. I have seen people (from tech and non-tech roles) tell me they are seniors/managers because they have X-years of experience. More often then not, if someone needs to tell me they have X-years of experience rather than showing through example, I roll my eyes, and stay away.
xiaoma 10y ago
> "I've worked with people in their late 30s that are still intermediate level." At what age did they start? I've worked with people who were just getting started in their late 30s after a career change or kids growing up enough to become more independent, etc.
- justinhj 10y ago
  I worked with a guy that was intermediate in his mid 30s after around 10 years experience. Conversely there was a 50 year old guy who became a programmer after he moved to my country and couldn't practice as a doctor. He was senior after about 5 years
- deleted 10y ago
  [deleted]

brian-armstrong 10y ago

It's far more than the first 10%. Most engineers don't stay in the engineering track for long, and there are almost no lifelong engineers. 5 years of experience is probably closer to 50%+ of the journey.

StevePerkins 10y ago
> Most engineers don't stay in the engineering track for long, and there are almost no lifelong engineers. That is absolutely absurd. Plenty of tech titans and small startups have architects and senior devs in their 40's and up (I'm one, and at trade conferences I'm hardly even an outlier). Not to mention that 90% of the industry is in the "enterprise" world (seemingly invisible to much of HN's readership), which is largely composed of devs in their 40's, 50's, and 60's. The high-octane older guys often go into consulting in their later years, where they're billing at $200-400+ an hour while giving technical direction to a team of warm bodies fresh out of school (or off the boat). If you seriously believe that engineering is something that you do from age 25 to 35, before starting your "real career" in PowerPoint, then that's incredibly sad. Why not just go the MBA route to begin with?

allengeorge 10y ago

Allow me to offer myself as a counterpoint ;) I've worked for well over 3 years (8ish now?) and there's a lot I've yet to learn about when to take one design approach vs. another, how to identify risks early, etc. etc. And, for what it's worth, I agree: one should not be considered "senior" after 3, or 5 years. Actually, tenure matters less than perspective and problem-solving approach.

alexbanks 10y ago
Some (me) would argue that tenure should not be considered when deciding a developer's skill.
- collyw 10y ago
  For certain types of problem that may work well, but for me, learning from my mistakes has been where I learned a lot.
  - alexbanks 10y ago
    Totally, but learning from your mistakes is not necessarily tied to years at a desk. edit Also, we've all met that dev that just "gets it" and can be extremely productive regardless of time at a job/company/project. That dev also "got it" when they were pretty new to the industry.
- StevePerkins 10y ago
  I think that the number of different companies you've worked for (and the diversity in how they operate) is more important than the raw number of years you've worked. Also, how your role has grown or varied from job to job. Rookies worry too much about "job hopping". I can't count the number of people I've interviewed who had "10 years experience"... but really they just had "the same year 10 times".
  - alexbanks 10y ago
    More jobs = more diversity = more experience, no? Both models are flawed I think, as 10 jobs in 10 years brings a ton of understanding of the overarching principles of working as a dev, but has a total lack of long-term team success. 2 jobs in 10 years brings an understanding of that long-term team success but a relatively small window into dev jobs as a whole.

alexbanks 10y ago

The problem is that "senior" is entirely relative to the engineers that surround the developer in question. A senior dev at Company X may not be a senior at Company Y, regardless of how many years in the industry or productive at Company X they were. The problem also comes up for the 3-5 year mark when pay is involved. At my current company, it was impossible to make a certain salary without being promoted to Senior. The bigger problem was that the company has a slightly unrealistic view of the market, and to get any decent talent you'd have to be in the Senior pay bracket. Ultimately I think the best solution is to screen appropriately and decouple salary from title. I think the best model would be to never hire anyone as a Senior, but let the Seniors emerge.

ascotan 10y ago
I've been in that company. The problem is that without any leadership, every one is a leader. The practical result of this is that software gets partitioned into the 'parts that the idiots work on' and the 'undervalued but core business logic'. I also feel that this model of hiring is emphasized by the craze over agile (and particular SAFE) where all the engineers are supposed to be like lemmings that take orders from product owners. If you get the right team I suppose this is possible to do, but the lack of senior leadership on a team (and it's deferral to non-technical people like scrum masters and product owners) leads to unnecessary bikering among engineers on the 'right' way to solve a problem.
- alexbanks 10y ago
  So I guess I don't mean "hire a bunch of devs and see who emerges as a leader." I guess in my head it works out like you already have a group of "seniors," "architects," etc. And when a new dev is hired, they don't get to just dive into the ranks of Sr/Arch. but should instead have to work to get there just like the original Sr/Arch devs did. But you're right, there is no perfect system.
- nilkn 10y ago
  I don't fully understand why what alexbanks wrote implies that there is no leadership. It just means that new hires are not placed in leadership positions right out of the gate. There will certainly still be a strong leadership structure in place. As far as I can tell, the company I'm at follows the model alexbanks described, and it seems to work quite well. We generally do not hire people on in senior or lead roles. If someone has 15 years of experience and they're a team lead at their previous job, the chances are still very high they'll have to start as a "normal" developer with us. (Notably, we do not tie salary to title. A "software developer" can have an arbitrarily high salary if needed.) If they demonstrate the capacity for leadership, we will identify that and very quickly offer them more responsibility and promotions whenever the opportunity arises.

SatvikBeri 10y ago

There are many, many more developers today than there were 20 years ago. As a result, the median amount of experience is less than 10 years, which means that 5+ years actually is relatively experienced. Furthermore, I observe people being substantially more effective when they're 5 years in than 1, and again when they're 10 years in. Really it seems like we just need more granularity than "senior" or "not senior."

mianos 10y ago

I think the Dunning Kruger effect comes in here. https://en.wikipedia.org/wiki/Dunning–Kruger_effect https://en.wikipedia.org/wiki/Dunning–Kruger_effect After 3 or 5 years you don't really know what you don't know. A lot of people think they are experts after 5. After 10 you will see all the mistakes you have made and have a rough idea of just how little you know.

tamana 10y ago
That's not what DK means, which is interesting because you liked directly to the article that explains it.
tedmiston 10y ago
The way I look at it these days is: I can manage to do anything related to an API or app. The polish that comes after the 2nd, 3rd, 5th, 10th years is just doing things more elegantly and with better tooling. For me, it's mostly been about stronger separation of concerns. That's my perspective at 3 years into startup software engineering.
- Swannie 10y ago
  Clue: it's not about the code. This was the point of the original article.

lliamander 10y ago

I think a large part of this is that we didn't have a technical career ladder until recently, and that a "seniority" has different meanings depending upon whether the company treats software development as a strategic business asset[0]. Now that we have technical career paths where one can expect to continue as technical individual contributor, the official "Senior Engineer" title falls roughly in the middle (slightly on the lower side) of the career ladder[1]. I'm generally OK with this personally, so long as we distinguish between the title "Senior Engineer" and the role "senior engineer". The role I would equate to Randall Koutnik's "Finders"[2]. [0]I talked about this in a little more detail on another thread: https://news.ycombinator.com/item?id=11545294 https://news.ycombinator.com/item?id=11545294 [1]http://changelog.ca/log/2013/08/09/software_engineer_title_ladder http://changelog.ca/log/2013/08/09/software_engineer_title_l... [2]https://rkoutnik.com/2016/04/21/implementers-solvers-and-finders.html https://rkoutnik.com/2016/04/21/implementers-solvers-and-fin...

serge2k 10y ago
> the official "Senior Engineer" title oh right, the OFFICIAL one. Sure. > falls roughly in the middle (slightly on the lower side) of the career ladder[1]. Not really, as the upper levels aren't reached by most people.
- lliamander 10y ago
  > oh right, the OFFICIAL one. Sure. Not official in the sense of "there is some standards committee making these designations", but it seems to be a commonly accepted practice that the title of "Senior Engineer" is assigned to someone who "is capable of being given a high level (and often vague) task, and work completely independently on it and finish it" but not anything more. But my main concern was distinguishing between the title and the role. When I think of the role, I think we generally consider someone to be senior when they can: a) work through very thorny technical problems and find novel solutions b) connect technical solutions to the needs of the business c) provide leadership or mentoring to other engineers Like or not (I don't, personally) the title and the role use the same words but mean different things. > Not really, as the upper levels aren't reached by most people. I'm not clear on what your point is. Is it in the middle of most people's career? No. Is it in the middle of most technical career ladders (as used in various tech companies)? Yes. My point is that in places where there is a technical career ladder, there are titles that do actually reflect (what I consider to be) the role of a senior engineer. This is how tech companies get around the fact that convention has lowered the expectations of the title Senior Engineer. The core problem is that there is confusion about the relationship between title and role. The OP is trying to fix this confusion by raising the standards of the title to match the role (by explaining what the role really entails). I'm just trying to clarify the conventions set by the industry so that people can plan their careers accordingly.

ascotan 10y ago

I remember a guy we interviewed that was 1 year out of college and was a 'senior software engineer' because at his previous company he was the only developer. As such they made him the senior SE. The same can be said of 'Lead engineer' or 'Tech Lead' where there are 2 people in the group and you're the 'Lead' (whatever that means).

serge2k 10y ago

> How do you encourage humility and self-awareness, so that people don't honestly believe they've reached the 90th percentile after the only first 10% of that journey? Why would senior by the 90th percentile?

deleted 10y ago

[deleted]

TheCoelacanth 10y ago

Why would "Senior Engineer" mean someone who is at the 90th percentile? Anywhere that gives out the title "Senior Engineer" to someone with 3 years of experience will certainly have many higher titles, so what's the problem?