[tsywke44]

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

[Sohcahtoa82]

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.

[pavel_lishin]

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.

[shagie]

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.

[pavel_lishin]

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

[shagie]

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.