Of course not.

I'm saying if it takes 6 months to train a worker to productivity, it's not unreasonable for a company to reject someone who's had 5 jobs in 5 years.

Maybe you've lost me, and I misunderstand your post.

Initially I replied thinking you were talking about getting training in a specific set of tasks or platform, you mentioned "Product X".

But it seems, now you're talking about training a worker "to productivity", which is a bit more oblique and not as specific of a regimen against what you initially posited-on this I have somewhat of an easier time giving you the concession.

Let me just ask, before going further: which position are you taking? Training an employee to use a specific tools set that we've established isn't widely used, or training an employee to be most effective and productive day to day?

Or have I misunderstood you altogether?

Imagine you need senior embedded programmers with QNX and safety-critical systems experience, or someone with strong skills at understanding poorly-documented code in a software-defined radio system designed by consultants.

You're in a smaller city, and when you run job adverts, you only get a handful of applicants who can code and they're mostly Javascript+Windows guys (that's what the other big employers in town use).

So you'll have to train them on new languages, new problems, new conventions, new tools, new platforms, new build systems, new ways of debugging, new quality standards, and so on.

Initially they'll need to spend a bunch of time developing those skills - which means they need the attentions of your existing team members - and their early code will reflect their inexperience. I know my early code did! It won't be until they've spent quite a while working on the new system that their productive contributions will outweigh the sunk costs of their training.

> ou're in a smaller city, and when you run job adverts, you only get a handful of applicants who can code and they're mostly Javascript+Windows guys (that's what the other big employers in town use).

> So you'll have to train them on new languages, new problems, new conventions, new tools, new platforms, new build systems, new ways of debugging, new quality standards, and so on.

I would scour the country for embedded engineers of any stripe before I would hire JavaScript or Windows devs for an embedded role. Hell, I would even hire freshly-minted EEs for that role before I would hire those experienced engineers.

I don't see any of these training challenges being any different hiring someone who job hops, these sound like very common things a team would likely encounter onboarding just about any contributor...and I think we're drifting off course from the main conceit of this whole discussion no?

The challenge is if employees aren't productive in the first 0.5 years, an employee who stays for 3 years produces 2.5 years of productivity, whereas an employee who stays for 1 year only produces 0.5 years of productivity - a much lower return on the same investment in hiring and training.