I think the issue started way before AI when it comes to not having enough fresh blood for this industry. Companies have decided they don't want to train juniors. They want seniors who already have the skills.
> Companies have decided they don't want to train juniors. They want seniors who already have the skills.
It got worse in last two years. Now Senior Engineers must have exact combo of the weird tech stack and tools with N years of experience exactly as the existing employees, else gtfo, you don't even get screening calls. You don't have something from nice to have list? Lol, why are you wasting our recruiter's time even? She needs to use GenAI to write her next rejection email.
Also, your 15yoe does not matter, unless you are coming from direct competitor, in which case your 1.5yoe with internship is also excellent.
I think it is important to acknowledge that it takes much longer to train juniors in systems software today than a couple decades ago because the nature of the problems have changed. It now takes several years to get someone to an acceptable level for a lot of systems software work. In many cases that’s longer than the entire development cycle — a junior would never really be productive on the project. And yes, this is creating a vicious feedback loop where we are no longer producing many new people with these skills despite a lot of demand.
The minimum level of sophistication required to be effective in systems software has increased dramatically since the 1990s, when I first started doing systems software. The kinds of systems software we were putting in production in back then would be considered a trivial toy today. This shift has placed an enormous amount of upward pressure on the minimum level of experience and skill that would allow someone to become productive within a useful amount of time.
It is no longer feasible in many cases to have companies effectively subsidize the development of highly skilled systems software people. The training time has become so long that companies will never recoup the investment. It is easy to see how the incentives have created the current situation and it is not clear how to address the shortage. Even before the current situation, it was widely noted that most systems software developers were self-taught over many years rather than trained up in a structured environment.
>And yes, this is creating a vicious feedback loop where we are no longer producing many new people with these skills despite a lot of demand.
if the company would rather burn out and age out all their talent than invest in the future, I don't know what to say. For niche domains, you can't treat talent a a pure business expense. That's how you lose out all that talent to China and suddenly you can't compete at all. If anything, training should be treated like insurance.
>It is no longer feasible in many cases to have companies effectively subsidize the development of highly skilled systems software people.
"subsidize" implies that somehow engineers are saving money by choosing to take these more niche paths. It doesn't make sense. You have a product and you need talent to develop and maintain it to compete. There's no "subsidies" in a business relationship like this.
your choices are few and simple: train in-house, lobby schools to train for you, or publicize your tech and hope people train themselves for you again. It seems like these days companies aren't looking out long term though and just want to jump the ship that has plenty of time to steer past the iceberg everyone sees ahead.
I agree but it was always like that. Also there isn't any incentive anymore in growing juniors if they're going to immediately take the next better offer that comes around when they know enough, and you have such thing being offered on a daily basis (at least until a couple years ago).
I would love to work on low-level, systems stuff (anything as close to the hardware as possible), that's even my education and area of expertise. BUT SaaS companies in reality:
- pay better
- have lower costs
- are way easier
- don't have that many (or any at all) geographical restrictions (e.g. importing hardware prototypes).
>there isn't any incentive anymore in growing juniors if they're going to immediately take the next better offer that comes around when they know enough
okay. Promote them with proper pay then. This HR debacle of putting more budget into hiring over retaining is entierly self-inflicted.
>People follows the money.
Well that love sounds more like a low priority whimsy in that case. I don't think tech workers of all people are ones who ever complain about low compensation. Unless you work in games, I suppose.
This doesn’t follow. Below some level of skill and experience they can contribute negative value to the project. Companies need a minimum level of experience just to make the role pay for itself.
Does the high skill standard for surgeons mean the market for surgeons is saturated?
If you are not needing to consider having someone who does not meet a certain skill standard to perform surgery on you, then, yes, it would seem that the surgeon market is saturated as the parent describes it.
It depends on the time scale you are looking at it with. It looks saturated short-term, but it surely is not long term. The problem will only show up once your surgeons start retiring.
Instantaneous time is the only time scale that makes sense with respect to the topic at hand.
Sure, it is possible for the market to desaturate at some point as key people leave. But at that point, assuming suitable, per the earlier comment, replacements don't fill the void, the market will either come to accept lesser skilled people or it will come to accept fewer surgeries, returning to equilibrium. Not exactly magic.
...this doesn't make sense. Surely you need to factor in price point. Often times junior engineers deliver disproportionate value. Some ratio of juniors:seniors just seems rational, and those juniors grow into seniors.
Maybe there's a good argument against training, but it could also just be irrational and stubborn in this case.
In my experience it only works if you pull in juniors into strong teams and keep the proportion of juniors reasonably small. You also need to have a process in place for training them - it’s not enough to rely on ad-hoc mentoring from peers.
If you get the ratio wrong, with too many juniors and weak technical leadership then you will end up in a very bad place in your code base.
In terms of value, even if juniors are half the cost, it is much wiser to hire one senior instead of 2 juniors for the same money.
> it is much wiser to hire one senior instead of 2 juniors for the same money.
Maybe in terms of pure productivity, but if you can match hiring to roadmaps you can give them more approachable/further from revenue work for which seniors would be an overkill. Etc. I'm just saying anyone with a simple explanation is only telling you part of the story.
Besides, hiring is expensive. If you say live near a university, you have an edge in finding talent.
> give them more approachable/further from revenue work for which seniors would be an overkill
My experience suggests there is no such thing. There is work that seniors might not want to do, but if you hired well then they will be professional enough to do it, if it really needs to be done. And it takes some experience to determine which “non-revenue generating” work (e.g. tech debt) actually needs to be done, to advocate doing it to the stakeholders and to actually do it well.
Juniors need a lot of supervision and that is not free. Which is not a reason not hire them in the first place, just that that it should be done mindfully.
>which “non-revenue generating” work (e.g. tech debt) actually needs to be done
This mentality is part of the problem. You can't fundamentally treat juniors as a profit center. Especially in more niche fields. They need to be trained and schools don't cover your specific pipeline.
maybe it doesn't "need" to be done, but some refactoring work will pay off to turn your juniors today into seniors tomorrow. If you can only think in productivity charts, then you don't hire juniors.
I’m a lead consultant on a gig where the CTO outright told us that he’s not really interested in growing their (frankly, under qualified) engineers, just wants them to get on with the job - it’s very short-sighted and sad.
That said, in my previous job in a startup we hired very junior engineers and gave them plenty of opportunity and support for growth and several people did stunningly well. Pity the company didn’t do very well (IMHO due to focusing more or this sort of thing rather than making money).
>That said, in my previous job in a startup we hired very junior engineers and gave them plenty of opportunity and support for growth and several people did stunningly well. Pity the company didn’t do very well (IMHO due to focusing more or this sort of thing rather than making money).
Mentoring is a key part of technical leadership, way easier to help the talent grow into your requirements (even if they are under-qualified, for now)
I agree but there's also the extra difficulty to do mentoring remotely (we are a remote first company). I *really* like being remote first and provide the choice if you want to work on site or wherever you want. But it does come with some challenges.
This may be a hot take, but I don't think most juniors should be remote. You need some time face to face to understand the processes and you miss lot of passive knowledge when you're not navigating a workplace of people discussing matters.
once you get a few years under the belt, sure. You're probably fine doing everything online. I can't think of many remote only studios hiring juniors anyways.
100% agree and that's exactly what we do. Almost all of our juniors are near the office. Because they need to see what's working at a company means at least once in their life.
There's few exception when we don't have the choice, but really, I cannot imagine myself to be full remote without having seen a company "in the flesh" before.
