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