4 ms·

The market is still extremely tight for good talent in-between Senior and Junior.

lumost 4y ago
So the Senior market is saturated? this is an early sign companies are getting nervous about bloat. After the '08 recession many companies rushed to ditch Architect titles as they found that the role did not serve the interests of their productive engineers or the companies higher ups. Companies that had gone heavy on such talent might find themselves stuck. I recall seeing talks on "Staff Engineer" and thinking that this was going to be the next version of "Architect". Engineers who's primary job is to write code often dislike working with people in such roles.
- outworlder 4y ago
  > I recall seeing talks on "Staff Engineer" and thinking that this was going to be the next version of "Architect". Engineers who's primary job is to write code often dislike working with people in such roles. That depends. If they are actively involved and the architectural decisions are sound, it's fine. If they are "drive-by architects", showing up, dropping a bunch of useless boxes they read on some book, and then leaving before the consequences of their 'architecture' are known, you are right we don't like working with them. At many companies, however, staff engineers are still engineers.
  - theteapot 4y ago
    Drive by architects don't read books. They read AWS's latest product brochure and think "yes".
    - dijit 4y ago
      I think both exist, but you're right. The majority of Architects I've brushed against in the last decade have been exclusively an additional marketing force for AWS with very little ability to objectively reason from first principles or assist with knowledge of anything outside of the AWS ecosystem.
      - qchris 4y ago
        Totally genuine question as someone coming from a background in mechanical engineering, who now does a lot of software-y things: what do you consider to be "first principles" in computing? Are you talking about first principles in terms of project development processes (i.e how information systems evolve) or code (i.e. bits and bytes, where microservices might not be the answer because the network connections are guaranteed to have a fundamental latency that, along with the amount of data required, means you can't meet requirements because [..])?
        openfuture 4y ago
        I think I can name an example, which is how I am approaching datalisp; https://sr.ht/~ilmu/tala.saman/ https://sr.ht/~ilmu/tala.saman/ the first principles bit for my context refers to: fixing a standard encoding that is sufficient for the task, determining inputs and outputs of model, setting a general guideline for expressivity of model (space of conflict-free programs), sketching interaction modes and user interfaces. These are the first principles in question, now from there your architecture is mostly determined, you can fall back on known patterns and decades of research. The axioms are the architecture.
        qchris 4y ago
        Thanks for the insight!
        ntr-- 4y ago
        Not the parent but I will offer you my opinion after I laughed at their comment because it reminded me of many of the engineers at my current work: "First principles" in this context is not just reaching for the nearest/newest AWS service that seems to do what you want. ie. if you want a webserver, don't just run magic lambdas that abstract everything away from you, go and provision a vps and install your dependencies on it so you fully understand and control how the stack works. None of the 12 engineers at my current company had written a test that actually wrote rows to a database when I arrived, they didn't know how. In fact none of them knew anything about how to run our databases on their own dev machines at all, they all shared one RDS PG instance. Again, "first principles" here is: running a process, connecting to a service, asserting the whole thing did what you expected. To do that effectively you have to actually control the whole system, and to do that you have to know how the whole system works together. A lot of developers now just delegate the provisioning and maintenance of everything to a provider, even in development setups.
    - JamesBarney 4y ago
      Every architect i worked with read books. The bad ones took what they read as gospel and the good ones took what they read in context.
    - johndfsgdgdfg 4y ago
      May I also add the demi-god of arhcitecture juggernaut Martin Fowler.
    - nvader 4y ago
      My personal experience screams, ouch!
- sarchertech 4y ago
  Staff engineer is just title inflation for what used to be senior engineer. Senior engineers at most companies just means this isn’t your first job right out of college.
  - dominotw 4y ago
    I have 15 yoe and have senior software engineer title so do people with 2 yrs experience. I might be doing same thing over and over. Time to make a radical change :/.
    - thwayunion 4y ago
      There's also nothing wrong with plateauing for a while or even topping out, especially if you are generally happy with life and career. There's pride to be had in being a good individual contributor; not everyone needs to make it to Senior Super Special Principal :)
      - spacemadness 4y ago
        I keep being told I shouldn’t be writing code at my level and should be knee deep in design docs and estimations all day long. This is actually what happens but I would much prefer to be writing software and am wondering if I can even be happy in this career any longer. This industry has some real bizarre notions of career progression.
        davewritescode 4y ago
        You need to write code and you need to get people around you to write better code. That’s basically what a staff engineer does in addition to making large design decisions.
        spacemadness 4y ago
        That’s my belief as well but there are managers out there that think staff engineers should never write code. It boggles my mind they think this way but many do.
- thwayunion 4y ago
  > So the Senior market is saturated? I am not sure I would say saturated, but yeah, the Sr. SWE market is definitely not as tight as it was a year ago for most role types. However, it does depend on qualifications and company type. Seniors for R&D positions (so, PhD with 5+ years in product-focused R&D) are still basically impossible to hire. Friends tell me that hiring seniors at mid-pay or low-pay companies is still pretty hard. The more important dichotomy is between mid-career/late-career and junior. The entry level positions are absolutely saturated. CS programs are definitely over-producing at this point.
  - noir_lord 4y ago
    Might be true in the US, not what I’m seeing have seen in the UK. Here big companies are taking kids straight out of uni and boot camping them because decent juniors are hard to find.
    - lostcolony 4y ago
      How easy is it to find bad juniors? I think that may be relevant for determining how saturated the field is.
  - oceanplexian 4y ago
    CS programs are overproducing but they are overproducing the wrong skills. Most don’t have the cloud skillset or experience with IaC, they are never thought how to solve problems within distributed systems. And their idea of systems design is a Flask app talking to a MySQL database on a laptop. It’s not the students fault, but the education system is constantly behind the times, and sometimes even teach bad engineering patterns that cause problems and create technical debt.
    - monksy 4y ago
      > It’s not their fault, but the education system is constantly behind the times. Yes/no/maybe. The schools got pressured by the bootcamps that were teaching the "flask app talking to a mysql db" .. they simplified their classes and stop teaching some things. It sucks, the people who come out of that don't have the theory/flexiblity/skills coming out that you would expect before.
- themagician 4y ago
  More and more senior engineers are non-coding or practically so. I see it everywhere. As industries have matured, people have matured into higher level management roles and there hasn't been enough people to replace them. There's still plenty of fresh blood, software engineering actually looks a lot like the labor shortages do in the rest of the market—there's a lack of people who actually want to do the work. Everyone wants that $150k starting comp. Everyone wants a $500k director or VP role. But there is a shortage in that $200-300K range for people who are actually going to put in hours either writing code that makes it into production, or managing junior coders and their codebases. I'm talking SV salaries here. The scale is different elsewhere, but the problem is the same.
  - lumost 4y ago
    Not for nothing, but that sounds a bit like a market peak if I've heard one. Why would the person actually doing the work settle for a mere 300k when the director/VP gets double without doing the hard work? there is a balance here - but it seems like a good time to lure engineers with real equity compensation to early stage startups.
    - dilyevsky 4y ago
      Which industry has it different? I mean there are exceptions like sport teams but by and large this stuff happens everywhere else too.
      - lumost 4y ago
        Difference in tech has been that productivity has largely been divorced from capital, OpEx, and experience. This may be becoming less true today with large enterprises owning specific market segments through network effects... but I wouldn't bet on that quite yet in the long-term. A doctor can't help but work at the world's best hospital, because it probably will still be the world's best hospital next year. A jet engine designer can't help but work at Boeing. A fresh college grad can start a tech business tomorrow.
    - themagician 4y ago
- spamizbad 4y ago
  What makes a "Staff Engineer" is largely a product of an orgs engineering culture. And you may have multiple people with "staff engineer" as a job title that fulfill different roles to varying degrees. I've found those roles to be: * Technical Leadership (driving major technical initiatives) * Technical Contributor (shipping stuff, with technical mastery beyond what would normally be expected from senior engineer) * Architect (planning stuff) * Team Management (mentorship + taking load off an engineering manager's plate if the team is big) Biggest mistake I see orgs make when hiring staff engineers is hiring someone whose strength is in mentorship and technical contributors and decide their new role is architecture and driving major technical initiatives at a high level. Some are best "in the weeds" and others are better planners. Know their strengths!
- hanszarkov 4y ago
  I'm a software architect, I write code every day, I design every day, I write documents every day, and I report to the VP and CTO every day. I have met other architects that claim they "don't code" and honesty don't understand how they can make decisions and reduce risk without that background. Most of the time I have a solution because I've been there and done that. I view my role as one that has the expertise to bring the engineering team to the next level, because if I did all the work - it would just be one person instead of many. I constantly try to unblock, solve hard problems, and reduce entropy - and let the creativity flow to the rest of the team. This has worked for me, as a software architect, for almost a decade.
superfrank 4y ago
I agree it's still tight, but it's not as bad as it was a few months ago, IMO. Anecdotal evidence, but I've had 2 open positions on my team since April and it's just been a constant flow of terrible candidates. I'm in a tech hub and we pay above market average according to levels.fyi, but we're competing with FAANGs for our candidates. The few good ones that popped up over that time often had multiple offers and it was hard to get them to choose us over a household name. In the last 6 weeks I've started to see the number of qualified candidates with no other offers increase to the point where I've filled both positions in a 2 week span.

So the Senior market is saturated? this is an early sign companies are getting nervous about bloat. After the '08 recession many companies rushed to ditch Architect titles as they found that the role did not serve the interests of their productive engineers or the companies higher ups. Companies that had gone heavy on such talent might find themselves stuck. I recall seeing talks on "Staff Engineer" and thinking that this was going to be the next version of "Architect". Engineers who's primary job is to write code often dislike working with people in such roles.

outworlder 4y ago
> I recall seeing talks on "Staff Engineer" and thinking that this was going to be the next version of "Architect". Engineers who's primary job is to write code often dislike working with people in such roles. That depends. If they are actively involved and the architectural decisions are sound, it's fine. If they are "drive-by architects", showing up, dropping a bunch of useless boxes they read on some book, and then leaving before the consequences of their 'architecture' are known, you are right we don't like working with them. At many companies, however, staff engineers are still engineers.
- theteapot 4y ago
  Drive by architects don't read books. They read AWS's latest product brochure and think "yes".
  - dijit 4y ago
    I think both exist, but you're right. The majority of Architects I've brushed against in the last decade have been exclusively an additional marketing force for AWS with very little ability to objectively reason from first principles or assist with knowledge of anything outside of the AWS ecosystem.
    - qchris 4y ago
      Totally genuine question as someone coming from a background in mechanical engineering, who now does a lot of software-y things: what do you consider to be "first principles" in computing? Are you talking about first principles in terms of project development processes (i.e how information systems evolve) or code (i.e. bits and bytes, where microservices might not be the answer because the network connections are guaranteed to have a fundamental latency that, along with the amount of data required, means you can't meet requirements because [..])?
      - openfuture 4y ago
        I think I can name an example, which is how I am approaching datalisp; https://sr.ht/~ilmu/tala.saman/ https://sr.ht/~ilmu/tala.saman/ the first principles bit for my context refers to: fixing a standard encoding that is sufficient for the task, determining inputs and outputs of model, setting a general guideline for expressivity of model (space of conflict-free programs), sketching interaction modes and user interfaces. These are the first principles in question, now from there your architecture is mostly determined, you can fall back on known patterns and decades of research. The axioms are the architecture.
        qchris 4y ago
        Thanks for the insight!
      - ntr-- 4y ago
        Not the parent but I will offer you my opinion after I laughed at their comment because it reminded me of many of the engineers at my current work: "First principles" in this context is not just reaching for the nearest/newest AWS service that seems to do what you want. ie. if you want a webserver, don't just run magic lambdas that abstract everything away from you, go and provision a vps and install your dependencies on it so you fully understand and control how the stack works. None of the 12 engineers at my current company had written a test that actually wrote rows to a database when I arrived, they didn't know how. In fact none of them knew anything about how to run our databases on their own dev machines at all, they all shared one RDS PG instance. Again, "first principles" here is: running a process, connecting to a service, asserting the whole thing did what you expected. To do that effectively you have to actually control the whole system, and to do that you have to know how the whole system works together. A lot of developers now just delegate the provisioning and maintenance of everything to a provider, even in development setups.
  - JamesBarney 4y ago
    Every architect i worked with read books. The bad ones took what they read as gospel and the good ones took what they read in context.
  - johndfsgdgdfg 4y ago
    May I also add the demi-god of arhcitecture juggernaut Martin Fowler.
  - nvader 4y ago
    My personal experience screams, ouch!
sarchertech 4y ago
Staff engineer is just title inflation for what used to be senior engineer. Senior engineers at most companies just means this isn’t your first job right out of college.
- dominotw 4y ago
  I have 15 yoe and have senior software engineer title so do people with 2 yrs experience. I might be doing same thing over and over. Time to make a radical change :/.
  - thwayunion 4y ago
    There's also nothing wrong with plateauing for a while or even topping out, especially if you are generally happy with life and career. There's pride to be had in being a good individual contributor; not everyone needs to make it to Senior Super Special Principal :)
    - spacemadness 4y ago
      I keep being told I shouldn’t be writing code at my level and should be knee deep in design docs and estimations all day long. This is actually what happens but I would much prefer to be writing software and am wondering if I can even be happy in this career any longer. This industry has some real bizarre notions of career progression.
      - davewritescode 4y ago
        You need to write code and you need to get people around you to write better code. That’s basically what a staff engineer does in addition to making large design decisions.
        spacemadness 4y ago
        That’s my belief as well but there are managers out there that think staff engineers should never write code. It boggles my mind they think this way but many do.
thwayunion 4y ago
> So the Senior market is saturated? I am not sure I would say saturated, but yeah, the Sr. SWE market is definitely not as tight as it was a year ago for most role types. However, it does depend on qualifications and company type. Seniors for R&D positions (so, PhD with 5+ years in product-focused R&D) are still basically impossible to hire. Friends tell me that hiring seniors at mid-pay or low-pay companies is still pretty hard. The more important dichotomy is between mid-career/late-career and junior. The entry level positions are absolutely saturated. CS programs are definitely over-producing at this point.
- noir_lord 4y ago
  Might be true in the US, not what I’m seeing have seen in the UK. Here big companies are taking kids straight out of uni and boot camping them because decent juniors are hard to find.
  - lostcolony 4y ago
    How easy is it to find bad juniors? I think that may be relevant for determining how saturated the field is.
- oceanplexian 4y ago
  CS programs are overproducing but they are overproducing the wrong skills. Most don’t have the cloud skillset or experience with IaC, they are never thought how to solve problems within distributed systems. And their idea of systems design is a Flask app talking to a MySQL database on a laptop. It’s not the students fault, but the education system is constantly behind the times, and sometimes even teach bad engineering patterns that cause problems and create technical debt.
  - monksy 4y ago
    > It’s not their fault, but the education system is constantly behind the times. Yes/no/maybe. The schools got pressured by the bootcamps that were teaching the "flask app talking to a mysql db" .. they simplified their classes and stop teaching some things. It sucks, the people who come out of that don't have the theory/flexiblity/skills coming out that you would expect before.
themagician 4y ago
More and more senior engineers are non-coding or practically so. I see it everywhere. As industries have matured, people have matured into higher level management roles and there hasn't been enough people to replace them. There's still plenty of fresh blood, software engineering actually looks a lot like the labor shortages do in the rest of the market—there's a lack of people who actually want to do the work. Everyone wants that $150k starting comp. Everyone wants a $500k director or VP role. But there is a shortage in that $200-300K range for people who are actually going to put in hours either writing code that makes it into production, or managing junior coders and their codebases. I'm talking SV salaries here. The scale is different elsewhere, but the problem is the same.
- lumost 4y ago
  Not for nothing, but that sounds a bit like a market peak if I've heard one. Why would the person actually doing the work settle for a mere 300k when the director/VP gets double without doing the hard work? there is a balance here - but it seems like a good time to lure engineers with real equity compensation to early stage startups.
  - dilyevsky 4y ago
    Which industry has it different? I mean there are exceptions like sport teams but by and large this stuff happens everywhere else too.
    - lumost 4y ago
      Difference in tech has been that productivity has largely been divorced from capital, OpEx, and experience. This may be becoming less true today with large enterprises owning specific market segments through network effects... but I wouldn't bet on that quite yet in the long-term. A doctor can't help but work at the world's best hospital, because it probably will still be the world's best hospital next year. A jet engine designer can't help but work at Boeing. A fresh college grad can start a tech business tomorrow.
  - themagician 4y ago
spamizbad 4y ago
What makes a "Staff Engineer" is largely a product of an orgs engineering culture. And you may have multiple people with "staff engineer" as a job title that fulfill different roles to varying degrees. I've found those roles to be: * Technical Leadership (driving major technical initiatives) * Technical Contributor (shipping stuff, with technical mastery beyond what would normally be expected from senior engineer) * Architect (planning stuff) * Team Management (mentorship + taking load off an engineering manager's plate if the team is big) Biggest mistake I see orgs make when hiring staff engineers is hiring someone whose strength is in mentorship and technical contributors and decide their new role is architecture and driving major technical initiatives at a high level. Some are best "in the weeds" and others are better planners. Know their strengths!
hanszarkov 4y ago
I'm a software architect, I write code every day, I design every day, I write documents every day, and I report to the VP and CTO every day. I have met other architects that claim they "don't code" and honesty don't understand how they can make decisions and reduce risk without that background. Most of the time I have a solution because I've been there and done that. I view my role as one that has the expertise to bring the engineering team to the next level, because if I did all the work - it would just be one person instead of many. I constantly try to unblock, solve hard problems, and reduce entropy - and let the creativity flow to the rest of the team. This has worked for me, as a software architect, for almost a decade.

superfrank 4y ago

I agree it's still tight, but it's not as bad as it was a few months ago, IMO. Anecdotal evidence, but I've had 2 open positions on my team since April and it's just been a constant flow of terrible candidates. I'm in a tech hub and we pay above market average according to levels.fyi, but we're competing with FAANGs for our candidates. The few good ones that popped up over that time often had multiple offers and it was hard to get them to choose us over a household name. In the last 6 weeks I've started to see the number of qualified candidates with no other offers increase to the point where I've filled both positions in a 2 week span.