Hacker News Reader

Comment by DeBraid | Hacker News Reader

Very few firms want to hire juniors, while nearly all firms desire senior-level talent.

This manifests inflated job vacancies because so many firms have an evergreen job posting for "Senior Full Stack". Because talent is scarce these roles rarely get filled (hiring managers expect million-dollar candidates to accept $100-200k compensation).

Also, because lots of software requires specific expertise, there are vacancies that can't be filled because of a knowledge gap (novel industries / projects, etc). For example, how could SpaceX possibly fill all their engineering roles? Surely money is not a limiting factor, but rather the limited supply of qualified expert rocket engineers?

View on HN

Worse, many firms are put off by juniors for entirely preventable reasons. In their minds, juniors are undesirable because the moment they are trained up, they tend to jump ship for senior positions elsewhere. Why train your competition, right?

The reason they jump ship is because the firm refuses to re-evaluate them for what they are worth, and keeps them on work meant to free up the company's existing senior staff (i.e., dead-end grunt-work that results in burnout). If you, as a junior developer, want to be re-valued, you need to jump ship.

This creates a feedback loop. Companies view juniors as a cheaper developer you _might_ get 2 years of low-cost work out of (after training) before they'll leave, creating a self fulfilling prophecy.

I've watched (and experienced) this loop multiple times. It's utterly baffling how firms would rather go through the cost and drain of finding and replacing talent rather than re-evaluate and pay their existing, proven talent what they are worth on the open market.

Workers would rather not move around. Workers would rather have a stable position in a job they like, in a community where they can purchase a home and build lives and/or families. Once you get past 35, playing the required musical-chairs needed to advance your career is a real drag. It does not need to be this way.

> Workers would rather not move around.

I really disagree. These junior engineers you're talking about are mostly in their early 20's (even if they're older and switching from a different career track, they're by definition new to the industry and still have a lot to learn). In my experience, they definitely do want to move around. And even if there is a great track for internal promotions and the compensation is going to be the same whether they stay or leave, it honestly is usually in their best interest to move around every couple of years anyway early in their career. They'll meet more new people to grow their professional network faster, work on new problems, see different ways of how teams operate and what works better/worse, and gain more experience faster.

I do think that for the very top performers, most companies should probably be much more aggressive than they are. If someone is really crushing it, like in say the top 1-5% of performers, be ridiculously proactive and promote them from junior engineer to Staff Engineer within 18 months or something. I've seen a couple of people over my career that actually were performing at that level, and no external company is going to give them that big of a boost, so it's a good chance to use your inside information to be more competitive. Otherwise, for the majority of folks that are learning/advancing at a more normal pace, I don't think there's really much a company can do to keep them longer. (Not that you shouldn't even try, it's still a continuum and if you do a really bad job at career growth internally you'll lose even more people faster. But you shouldn't expect to be able to keep most people beyond 2-3 years).

Hiring Juniors is a positive externality that the company does not see a penny of. They only see a penny of that externality if they don't give a raise, and that Junior chooses to stick around anyway. You get to exploit that he made friends or is stuck in your part of the city due to a lease or otherwise makes a poor financial decision.

It's interesting that the worse the interview process, the less the Junior will want to go through it, the more the company benefits. You make your process painful so your competitors make their process painful so both of you hold onto your Juniors for more time.

If you can fix the externality problem this goes away, but that's not easy.

Isn't this what vesting cliffs are for? To incentivize employee to stay for at least a year or two?

Honestly, I think having engineers come and go is a net win for companies. I've worked at places where the "old guard" has been around forever and they are inevitably stubborn, obstinate, and convinced there is no other way to solve the problem. By changing jobs and environments, you get to see in practice that there are many different ways to implement a solution. Only seeing one set of systems (unless they are a FAANG, which is large enough to have the breadth to counteract it), would ultimately cause those architectures to stagnate, injecting new blood is also injecting new ideas.

I do however, agree with your sentiment, those junior folks that are getting all the work done only get rewarded with more work to do.

I work at a fairly small company that hires juniors. We pay them well, and give them more responsibility in pay as we see them improving.

Most of them still want to move on, usually to change technologies or gain more responsibility even faster.

Sometimes they want to move cities for almost random reasons, and they're willing to just find a new job and do it.

So while I somewhat agree that devs don't want to move jobs, juniors devs often do, and I think they're a lot more likely to move jobs than senior devs.

> Very few firms want to hire juniors

It's not that they don't want to hire juniors, it's that you need a solid ratio of mentors to mentees.

I've worked at a LOT of companies, and for the more well known one, the ratio of junior resumes to seniors was easily 1000:1.

We hired entire cohorts of juniors, often interviewing HUNDREDS of them in a couple of weeks, hiring dozens. That still meant that from all the resumes we got, only a few % made it through.

What choice did we have though? We can only train mentors so fast, and hiring them is hard and expensive. You can't ask someone with 5 years of experience to train 30 people at the same time.

People often underestimate just how many people are entering the field right now, vs how many were 10-20 years ago. Add in people who EXIT the field, as well as people who are poor fits to be mentors, and it gets really dicey.

To go in line with firms not wanting to hire juniors, I think generally firms do not want to invest heavily in employee training or education. I would, for example, happily make a shift from CRUD webdev and distributed networking to hardware and embedded and more lower level type work, but I doubt a firm would hire me near my current level and train me up.

I think you hit it on the nose. Companies don't want to invest in training their new hires. They just want someone to hit the ground running with as little hand holding as possible.

It doesn't help that, for a certain slice of the software industry, staying in a position for 18-24 months has almost been normed. If it's unlikely that your hire is going to be there for more than a couple of years, why on earth would you "invest" in them. It's not like you'll get a return on that investment.

And why would software engineers stay if you did invest in their training but in the meantime you're going to reduce or eliminate bonuses, make your health plan worse (or just plain switch to high-deductible with no PPO options), stop 401k matching, other key employees have left and you don't hire new people and instead dump that responsibility on someone else without promotion or raises, etc.

I've seen all of those things happen at a single company before (and relatively quickly, over two years), and several of those things happen at several companies.

This is often the case. Another factor is that in many of the areas with a persistent shortage of talent is that it would require 18-24 months of training to really become productive. That's a big investment and people tend to have short tenures at companies these days.

which I think I'm fine with. I can learn skills on my own time. But I expect compensation to be commensurate with that

that is true for firms that never hire juniors. For me, I have a small team, we can only absorb a small number of juniors at any given time, because I have to have people free enough to train them up. And now, having lost most my seniors in my team to attrition, I'm hiring more mid-level developers (and hoping to find seniors)

The problem is likely that most people are willing to learn on the job, but then take that learning and go get a better job. A large portion of this problem is companies not being willing to increase pay to match the value you add by learning that skill, but it does lead to the doubt about bothering to train.

Why would any company spend 2 years to train a junior, only for that junior to jump ship?

Oh and it's not that easy to even find a "trainable" junior. Even if you have a fairly strict hiring process, at least 1/3rds of the people coming out of the edication system will be draft busts if using sports terms

To answer your rhetorical question, because the alternative is spending five times as long trying to hire a senior engineer without the sort of budget that FAANGs have.

And because it doesn't take a full two years before that junior is a valuable contributing member of the team; because they'll likely refer other qualified and/or educable applicants; because they might not jump ship, but be happy to get promoted if you actually reward them comparatively to what another company would pay them.

But sure, if you're not willing to invest either time or money in your employees, then no, you shouldn't hire juniors.

Spending five times as long to hire a senior who doesn't leave in a year or two is then a much better situation.

A junior dev hire involves sifting through many resumes, and then interviews, onboarding, and then three to six months of lower productivity for the mentor.

All of that represents losses against the current status quo. The current status quo is predictable.

This completely discounts the "accept and renege" that also is common with juniors looking for a job which can reset the job search back to square one even when you do find a good candidate.

Taking six months or a year to hire a senior has fewer resumes to sort and fewer interviews to conduct. When the person is hired, they've got a much shorter onboarding and has the necessary skills to be able to become familiar with the codebase without causing a hit to the productivity of the rest of the team (or other seniors).

In this situation, hiring a senior is likely a much better outcome with fewer seen and unforeseen negatives and an eventual positive.

> Spending five times as long to hire a senior who doesn't leave in a year or two is then a much better situation.

yes - assuming the senior also doesn't leave.

Senior devs tend to be a bit more stable in terms of "looking for a place to settle down" rather than switching jobs frequently as they've got a better idea of what they want to do and how to judge if an origination is one they want to be in.

Additionally, even if it is the case that they leave in a year or two, the org has likely spent less time on going through resumes (fewer resumes applying) and overall interviewing (individual interview may be longer, but again - fewer overall being done) and less time on onboarding.

You're likely able to have productive contributions from a senior in 3 months rather than 6-12 months for a junior.

So even if the senior does leave in a year or two - the org is still better off trying to hire a senior than a junior.

---

It really boils down to "if you can't compete with big tech salaries, there likely isn't a way to hire a junior dev that will be a net positive to the organization.

If you hire a junior at $X/year, and two years later, the "junior" jumps ship because the two years experience qualifies them for $X * 1.5/year, then the problem isn't disloyalty on the part of the junior, it's with the company that hasn't kept up their salary.

Junior salaries are low because they're a huge gamble. If after two years you know they're a decent engineer that has learned a lot, then you need to pay them like it.

It's something I see a lot of. Your "junior" that has been there for 2 years should be getting the salary you'd be paying a new hire that has 2 years experience. If they've been there for 3 years, and you've only been giving them 3-7% raises every year, you deserve to lose that engineer for someone that will pay them 50+% more.

The problem is that nobody wants to pay you intermediate/senior salary for junior ability until you learn their field. More than that, even if you volunteer to take the pay cut, they may be afraid you'll jump ship quickly, or that it's just not worth the risk of doing something unconventional.

Most software positions at SpaceX, even those working on critical flight code, do not require aerospace knowledge. And SpaceX is not a great example as they hire a lot of interns and junior people willing to grind.

I find this insane and terrifying.

This is pretty standard in all industries. Most people who work at a bank aren't financial experts. Most people who work at a hospital aren't medical experts.

Thats because most roles aren't the core of the business. Most are supporting the core. You don't need to be a flight engineer to build the system that tracks parts during manufacturing. You don't need to know how swaps work to build an order management system for traders. You don't need to know how to do surgery to build a scheduling system for the surgeons.

What do you work on, and how much prior domain experience did you have? (And if you did have some, was it necessary?)

I currently work for an agtech company, the domain-specific stuff is just context for the generic numbers and equations, or a reason to choose one over the other, to the extent that I need it it suffices to have a colleague who's a domain (but not software) expert.

You might say that's the other extreme, aerospace is different, but I don't really see that it is. I don't think anybody's claiming SpaceX doesn't have or need aerospace engineers, but once they've, idk, specified a formula for a parabola representing a flight path say (yes, I don't know what I'm talking about!) then the domain doesn't (needn't) matter to the software engineer implementing it.

Flight paths and what not are crafted by GNC engineers who hand them over to software engineers to implement. Really the only domain expertise needed in software is for space-grade fault tolerance, which is a couple people per vehicle.

Where are they going to find strong software engineers who also have aerospace engineering qualifications?

Iv'e worked with aerospace sims, grid-level protection products, financial products for banks and safety-certified industrial control software (even nuclear in some cases) that will result in great property damage and even death upon failure.

Basically nobody in any of those places had any domain knowledge outside that which was learnt during the act of developing and, in some rare cases, some "familiarization" courses during a day or so.

they hire a lot of interns and junior people willing to grind

Is this a euphemism for an employer overworking and underpaying their talent?

Overworking, but probably not underpaying. I remember hearing about how much a SpaceX intern was payed and being shocked (it was several X my scientist pay)... Then she told me how many hours she was working, and it made some more sense (but it still seemed high -- scientists often also work 80+ hours)

Getting paid what seems like a lot is not the same as getting paid what the work you're doing is worth.

i.e., did it seem like a lot "for an intern"? Did it seem like a lot when you take into account what was expected of them? I mean, if interns get hired to jobs that seniors (for the sake of argument) should be doing, and the interns are getting sub-senior pay, then they are underpaid.

I work in the same industry as SpaceX. They are in fact well known for pay that would be average-at-best in a sane work environment coupled with an absolutely insane work environment. When I was in college, my only goal was to get a job at SpaceX. After getting a few internships and talking to some people in the industry, my only goal now is to never be so desperate for work that I accept a job at SpaceX.

Their intern pay was also in line with this. I got paid a little bit less as an intern at NASA, but much more as an intern at a non-aerospace (also non-FAANG) tech company.

cool! thanks for the datapoint.

A friend's son is in Aerospace Engineering, attends UIUC in Central Illinois. "SlaveX" is the nickname colloquially used.

UIC is in Chicago. UIUC is in central Illinois.

Fixed, I get them confused. Thought it was the other way around.

When I worked at SpaceX I had one of the saddest comp packages I've ever had in a long career. I left for a competitor and got 35% more just walking in the door, plus I don't have to deal with an inhumane company culture. I honestly don't know what Elon is going to do when he runs out of people to chew up and spit out.

seems like a chicken and egg problem

how are senior engineers supposed to be created if very few companies are willing to train junior engineers? Why aren't these companies offering paid apprenticeships if they are so desperate for workers?

In part because you have to jave enough sr people able to mentor. There's not a great industry framework.

As a plumber, you pay your apprentice usually 60% sr/journyman salary with a 5% increase every 6 months to match the value of the skill up.

There are also industry standard, industry funded classroom settings, that teach things like building codes and industry standards and some adjacent trade craft.

Instead you just throw a Jr to an overworked mid/Sr and they can help with some design and questions and code review but that takes 10-20 hours per week so you have to pretty much have one or more per Jr. Position. Then, after 18 months when the Jr hasn't received a 15% pay raise to reflect the enormous amount of time an knowledge you've sucked out of a Sr position, they go elsewhere for a 20% raise and it looks like you've waisted your time.

In truth, it wastes the talent you've built to not be aggressively increasing their comp to match the skill increase you're providing.

one difference though is that varying levels of skill can be staggeringly different for SWE compared to a plumber. There are people that have been coding in basic since 12 and hacking their entire childhoods, and you have some people that coded for the first time in a cs program which they completed in an average fashion.

Not everyone is equally good of course but I would be very cautious about making hacking since 12 a requirement for a developer job. It certainly doesn't have its equivalent in any other branch of engineering or indeed just about anywhere else other than the arts.

And yet finding someone competent for the job is like a needle in a hay stack.

Having a base of expected/certified knowledge would take a lot of that away.

And yet every other technical field which has no expectation that this has been a passion since childhood and applicants should have personal projects in the field manages somehow to hire people.

That's what I'm saying. We could train a base of knowledge so that skills transfer and we don't have to find super specialized operators for every role. When you get a union plumber to the shop, you know that they passed their certification. You may not like working with them or they may do sloppy work or something but as a whole, you're going to get a competent operator once the apprenticeship is finished.

That will work once the world has decided upon a single web stack with standardized API design and security and every company uses that web stack. When that happened hiring web stack developers will be a standardized process similar to plumbers today as you say. But be are very far from that level of standardization.

I'm not sure about other industries, but for me personally, my competency is in large part based on my ability to quickly pick up domain knowledge and apply it successfully.

I'm not really sure how you test for a base level of that, besides proven demonstration on your resume and doing semi-correlated coding quizzes.

True, I started sorting parts in a plumbing shop when I was 12, you still have to get certified and to get certified you take the same classes as everyone else. That's the same for doctors, and lawyers and all that shit.

This is why we don't have a base of expected knowledge in the field and why we do strange coding tests to try to guess if someone is competent.

> In truth, it wastes the talent you've built to not be aggressively increasing their comp to match the skill increase you're providing.

The issue is that we don't quantify what hiring someone actually costs. We're willing to spend $20k on finding a candidate for 160k yet the people in the same position are sitting at 120k and getting a 3-4% raise.

The new person needs time so expect at least a month of training, yet no one quantifies that as well.

yes, the JR to SR path should be a methodical planned progress with expectations of big raises as they skill up.

I'm fine with an annual cost of living adjustment once I get to a SR level because I'm not increasing skill at a rapid pace, I'm exercising my skill in the expected way. For a Jr path, that doesn't make sense. getting a cost of living adjustment and being twice as good as you were last year means you're a flight risk and that will cost the company more than just paying people what they are worth.

When you say "industry funded", who specifically are you referring to? Tool / parts / consumables manufacturers? The individual plumbing firms?

All of them, you pay some for the classes, If I remember I paid 300/semester for classes which is nothing really. usually your firm will pay your share.

But industry standard groups, unions, people who have a vested interest in having a supply of quality labor so they can do business. Some of the classes are sponsored (especially in smaller places where there's not enough support) and in return, they get to train you on a specific product or just hang a banner and give you a 10% tools coupon.

A sufficiently fast growing startup hires a lot of juniors and then due to turnover, general chaos, etc. leaves them with outsized responsibilities and little supervision. Those who “swim” in that environment are the next generation of senior engineers. It is not like you’ve been supervised for N years, you’re senior now. You get thrown into independence first and if you can hack it, the title and comp follow.

> This manifests inflated job vacancies because so many firms have an evergreen job posting for "Senior Full Stack". Because talent is scarce these roles rarely get filled (hiring managers expect million-dollar candidates to accept $100-200k compensation).

At a lot of non-tech companies, the trick is to get hired as a consultant.

I take a different take here.

Juniors write a lot of code. Often significant amounts for a company's products and services. They're the ones who are implementing all the decisions that seniors spend their time making in all their meetings.

Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.

The seniors are valuable, making decisions, coming up with solutions, building frameworks etc, but it's the juniors who then take that and run with it and build everything on top of it.

So while some will still code, it's far less than what the junior engineers are creating.

Yes they require some more training, and clear direction, but they are the ones actually creating and executing the vision of the company informed by the seniors.

What companies really want, like others have said, are senior engineers who are willing to accept a junior salary.

While of course companies would love senior engineers willing to accept a junior salary I'd say

> Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.

Is actually a symptom of the shortage of senior engineers. Big companies that can afford to hire as much talent as they want actually will let seniors write code all day (my company does) because they have the economies of scale that lets them afford doing so; no one else can.

> (hiring managers expect million-dollar candidates to accept $100-200k compensation).

Wait, not even that.

Even if you are senior you can get that job (because, for example, you are from another country and suddenly you are "cheap" even if senior).

> because, for example, you are from another country and suddenly you are "cheap" even if senior

That's a red flag. Because we all know the top of the market, no matter where, is working at SV rates.

> Very few firms want to hire juniors, while nearly all firms desire senior-level talent.

Or many firms want to hire senior-level talent at junior-level prices.

> "Senior Full Stack"

Also why companies will hire someone with 3 years of experience into a senior position.

Had this happen to me at my first official dev job. Had 'junior developer' in bold at the top in my resume, application, and in several emails to the hiring manager. Got hired, and quit within 2 months. Manager would become upset at times over knowledge gaps I had as a result of being a junior, and the solution they came up with was for me to dedicate my weekends to unpaid, self-directed training.

At some point I actually reminded the manager that I was a junior, which resulted in them acting shocked and saying something to the effect of "well, let's hope that's not the case", and was basically flat out told they have no time for a junior. This was the manager who interviewed me, read my resume, and recommended me for the position.

I was replaced by a university undergrad student on summer break when I quit. I don't think people realize how the problem here often isn't you. Organizations with deep dysfunction are more common that you'd like.

Happy ending though. Got a new position the week I quit, and all turned out well.

Reply on news.ycombinator.com