Hacker News Reader

Comment by dimitrios1 | Hacker News Reader

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.

View on HN

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.

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.

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 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.

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

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.

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.

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

Reply on news.ycombinator.com