One of the reasons that I saw, is that training is very expensive for the company (both in terms of money, opportunity cost, time of other people, etc) which combined with people changing jobs often produces low, or negative ROI. By the time person is trained, they leave, before they start to meaningfully contribute.
More experienced folks also change jobs often, but you have higher chance of getting some productive time out of them before they move.
Personally, I think this is very dependent on the culture and work practices of the company in question. I agree that for the average company, training is very expensive. But I don't think it's universal.
If you have a strongly cross-functional, collaborative team, then a new person isn't nearly as much of a problem to bring on. As an example, Atomic Object is a midwestern software development shop that follows practices like pair programming, collective code ownership, short iterations, and a lot more. For them, interships and apprentices aren't a big problem, and have been key to their growth:
I also think it's worth looking at why people change jobs. I agree it's common, but I also believe that sucky jobs are common. If people leaving is such a problem, I'd like to see companies put more effort in to making them happy where they are. Not only would that be the humane thing to do, but it would make the ROI on investing in employees higher.
In my opinion everyone company likes to only benefit from experiences earned elsewhere but never like to provide folks a place to earn the same in their company. This is very unfortunate, I also see the same issue when someone is trying to even make lateral movement from one expertise to another. (Like backend to front end.) This whole process is a very lazy and unproductive way to hire. I have been thinking about an alternate approach. Where folks spend their own time to learn and build something in the common forum along in a team. Teammates can rate them, code can be available in open repo. That way folks can prove their skill outside their job and job interviews. Like I proved that I can build mobile app once and anyone can recruit me instead of starting from clean slate job interviews every single time.
> In my opinion everyone company likes to only benefit from experiences earned elsewhere but never like to provide folks a place to earn the same in their company
In Asia, it's not as cut throat as USA, where you shop around every 2-3 years. Japan they'll train you, and quitting isn't something that's easily done -- watch any Japanese netflix series about slice of life/normal life and you'll see the daily struggle or just read the news, or if you have the chance, go to Japan. Death by overwork is real and on the other hand, companies such as Rakutan will hire newly minted devs from schools that may know nothing and use the herd of workers to make them catch up.
Philippines and Indonesia is also similar with OJT training and filling seats.
Can't comment for anywhere else in Asia. But it is really 180 compared to USA.
Yes, this is common in India too. In fact, companies like TCS, etc are called 'mass recruiters' who recruit in bulk. There are satirical YouTube videos about them hiring by the kilogram. They hire indiscriminately, pay crap, in the the next 6 months people undergo on-the-job training. Some are kicked out, some are moved to better positions and offerings and the rest are contracted out to run-of-the-mill projects.
Back when I was graduating, we had TCS come to our Tier-I college. The recruiter started off by telling that the salary they will be offering was 250,000INR/yr (then about 7K USD/yr) and that those who found it too low were free to leave. About half the class walked out. The rest stayed, most were offered a position.
From my experience of outsourcing to India, they give those juniors a real, paid projects to learn on and do very little babysitting and quality control on the code produced, reducing their costs, so they're still making them money while learning - but that results in poorly written code and creates all sorts of problems for clients.
Oftentimes if the company is a USA startup, none of the experienced engineers have time to train or even mentor junior devs. A lot of startups want people who are "10x programmers" (however ridiculous that notion might be) or maybe it's less sarcastic to describe them as new hires that don't need any guidance or input, and will achieve maximum productivity after a short time adjusting to the new environment/toolset/workflow.
Also, you bring up an important point about time at the company. Anecdotal, but seems like a lot of devs spend 2-3 years at a company before moving on. That cycle is so short that the company doesn't think it's worth investing in junior people and doing so may even be considered counterproductive; the common view is that it's like investing in competitors. I'd like to think I'm wrong about that, but so far it remains a nagging impression.
"Not having the time" to introduce new engineers to the problem at hand, task, system or what ever is a recipe for wasting even more time in the future. It's very short sighted. Neither "10x programmers" or mere mortals can grasp a code base by reading it alone as by a thorough introduction.
I mean, a mediocre engineer that knows the system well is way more useful than an excellent engineers that just got his hands on it, for like half a year or more depending on complexity. If you give guidance you don't need excellent engineers. At least not as many. It's kinda surprising the way companies think of this.
Rather than officially allocating a developers time for introducing new employees or writing documentation for the system, Company 101 is to put 10 or 100 times the amount of dev time into catching up for the devs replacement when he quits, after he quits.
I agree wholeheartedly that it's shortsighted. Junior devs need training and guidance from experienced engineers. I view the problem as a failure to take the long view of progress.
At the same time, these startups find it difficult to hire people especially when they have money but hiring is expensive in terms of time for a small startup team. This must be changed for the benefit of all involved - job seekers, company.
It doesn't have to be expensive, either in financial terms, opportunity cost or other people's time. That's exactly the problem we've solved with Skiller Whale - we make good training easy.
As a Developer who was brought into the industry through this process, and now leading development of an online platform after leaving my last company, I feel there are definitely approaches my first company could have taken which would have kept me on for a lot longer.
Speaking with a CTO of a small web company recently I got to understand the issue from both perspectives.
CTO’s thoughts when hiring junior devs:
- Can be great for company but only if it makes economical sense I.e the developer stays with the company long enough after training
- From experience, the best devs from training move on to other companies soon after training
- Junior devs ask for frequent pay rises that aren’t viable for the company, holding the companies investment in the dev against them
Thoughts of a junior when considering other roles:
- How respected & valued will they be old vs new
- How interesting is the work, and will there be continued opportunity to develop themselves and learn new skills old vs new
- Salary old vs new
- The potential for future career prospects old vs new
Good junior devs will naturally be very enthusiastic and eager to learn, and the company needs to support this through and beyond the training to keep them motivated and engaged. On top of this, juniors will want to see regular progressions through the training process in forms of clear recognition and increases in pay and responsibilities as they progress. If these are not given, it’s likely the junior will feel under appreciated / taken advantage of.
Progression through a training course like this is motivated by success, and rewards, not unlike video games.
In my opinion the best way a company can keep a junior happy is to follow this and apply some of the proven methods researched and applied all over the video games industry.
- Progressively difficult but achievable tasks (missions)
- A sense of accomplishment from these (contributing towards real projects)
- Regular checkpoints ( targets and 2-3monthly reviews to support these)
- Regular rewards (small but regular pay increases, matched with greater responsibility and clear recognition of progression in the company; mutual respect is important!)
The list goes on.
If an approach like this is followed, the dev is much more likely to come out of training with a great sense of achievement and an attachment to the company for the support and rewards that were received. I think this massively increases the chances of a dev staying on, Provided salary, job title and sense of respect are matched with other members of the team in similar roles. I feel this is something many companies don't put enough thought into considering the large investment they're putting into the dev.
