Live data from Hacker News

Ask HN: Why not more hiring of junior devs, then on-the-job-training?

news.ycombinator.com

171–180 of 495 posts

Re: Ask HN: Why not more hiring of junior devs, then on-the-job-training?

#171

Earlier quoted context omitted.

A friend of mine runs a web dev shop and I have seen him train at least six people from zero-to-pro (very smart, fast learners with a math background) and what you described is exactly what happens. Once they become medium/advanced-level proficient they often quit and move on to other, bigger companies. If there was some formal, or informal understanding that candidates "trained on the job" would stay for a few years…

The other replies touch on this, but I'm gonna get straight to the point: Does your friend give them actual, meaningful raises as they grow? Is he actually paying competitively to begin with? Because I think if you have this pattern that consistently, it's really likely that either you're underpaying to begin with or your raises suck or are not even present. I love working at small companies. It's by far my preferenc…

That's the weird thing — they (because there are two cofounders) were actually paying very competitive salaries (for the local market). I was impressed to hear what some of them were making. So it's not the money.

I think what's going on is that after a year at any job you start to see the problems with the code base, and it starts to get repetitive. It will be like that both in big-co and small-co, but in a different way. In small-co you can have a much more freedom, but you reach a plateau of the new things you can learn. In big-co there are bigger problems and more challenges, but you're part of a soulless machine that just wants you to do your job and not ask questions.

Not having experience the soul-crushing big-co life, the brough-up-to-speed junior hires don't appreciate the deal they have, and want to explore their options. It's a rational decision, and come to think of it I'd probably do the same. The code is always greener on the other side... Who wants to be like "no I'll stay here and do 3 years of the same things that I'm really good at now and delivering value for my employer."

From the employers's perspective though was it worth it? Time/energy invested to train them vs. maybe 6mo or 1 year of useful coding contributions.

Re: Ask HN: Why not more hiring of junior devs, then on-the-job-training?

#172

Earlier quoted context omitted.

The other replies touch on this, but I'm gonna get straight to the point: Does your friend give them actual, meaningful raises as they grow? Is he actually paying competitively to begin with? Because I think if you have this pattern that consistently, it's really likely that either you're underpaying to begin with or your raises suck or are not even present. I love working at small companies. It's by far my preferenc…

One could argue that their "raises" were paid in training

Training was “paid for” by the low initial salary.

Re: Ask HN: Why not more hiring of junior devs, then on-the-job-training?

#173

I think the reason is simple: once the junior dev is trained, they will leave. To be clear, I am not saying that they are obliged to stay in the company that trained them or being ungrateful in any sense, I am simply implying this is a common outcome from such training. In software industry, the first job switch in 2 years seems pretty common and reasonable, and the dev by that time would be able to strike a better j…

I had a conversation the other day with some work colleagues where we were talking about a friends dad who just retired from working as an engineer at AT&T for something like 35 years. We made some jokes about how that would be unthinkable these days and the conversation moved on. Loyalty goes both ways. If you want someone to stick around, incentivize them to.

This only works in a monopoly or oligopoly, where you can’t easily switch careers. If you were out of AT&T, your experience there couldn’t translate easily to other companies. This works even today: there are few ex-Googlers, because experience inside Google is most valuable to Google; there are few other gigantic search-first companies to move on to (OK, you can go to Facebook or Amazon or Microsoft and that’s about it).

So, unless you want the economy consisting of a few dzaibatsu-style monopolies, the “loyalty first” approach to hiring is unsustainable.

Re: Ask HN: Why not more hiring of junior devs, then on-the-job-training?

#174

Earlier quoted context omitted.

On the contrary, I quit my job without having a job to move into, only $1000 savings and a credit card, and then moved to Australia. Everything worked out well and it was the best decision I ever made. Upon saying that, I knew that there were a lot of jobs available, and I was also willing to do any kind of job, not just software engineering. If push came to shove, I was willing to go back to working in construction…

In Australia, you'd probably make more money in construction vs software engineering.

That doesn't necessarily mean you'll be happier, however. Most construction jobs are very hard on the body.

Re: Ask HN: Why not more hiring of junior devs, then on-the-job-training?

#175

Earlier quoted context omitted.

The other replies touch on this, but I'm gonna get straight to the point: Does your friend give them actual, meaningful raises as they grow? Is he actually paying competitively to begin with? Because I think if you have this pattern that consistently, it's really likely that either you're underpaying to begin with or your raises suck or are not even present. I love working at small companies. It's by far my preferenc…

One could argue that their "raises" were paid in training

If the only raise you give them is in training, then the only way they can turn that 'raise' into something tangible is by leaving. If this is your attitude and you're still shocked they're leaving you've missed something in your calculus.

Re: Ask HN: Why not more hiring of junior devs, then on-the-job-training?

#176
The “shortage” isn’t real, or could be described as caused by the industry itself. A cynic would say in order to hire cheaper folks on a visa. They also won’t hire women or forty year olds, or those that can’t code with a gun to their head, and certainly not anyone who needs four hours training. What do you think we’re morons? We’d rather sit on a job req for nine months waiting for a unicorn to walk in, because that’s how Spolsky did it in 2002, haha.

Re: Ask HN: Why not more hiring of junior devs, then on-the-job-training?

#177

Earlier quoted context omitted.

One could argue that their "raises" were paid in training

Training was “paid for” by the low initial salary.

I don't think the OP indicated anything about lowness/highness of the initial salary. OP did mention that the training they provided was exceptional. That's kinda rare.

Re: Ask HN: Why not more hiring of junior devs, then on-the-job-training?

#178
Generally speaking I'd say if the devs have to be there no matter what you want juniors. If you have a goal to complete use experienced devs. Have the experienced devs build a product and the juniors support it.

At the end of most 1-2 year projects I usually feel like I could turn around and duplicate it in a matter of months with the knowledge I have. If I do another similar project it just flies. Experienced devs are a better value for your money in general. You can be a 10x developer and barely get paid more than twice the average rate.

Re: Ask HN: Why not more hiring of junior devs, then on-the-job-training?

#179

Earlier quoted context omitted.

As everyone else has said, it's essentially just a fizzbuzz test without using FizzBuzz. I don't need someone to write an algorithm to compute max, but I DO need someone who can take simple verbal requirements and write a program to do it. Everyone understands max/min/mean/median (or can quickly understand if they are unfamiliar). If they can't take that concept and apply it to code, then I don't trust them with inev…

>One problem we just encountered in production that I'm trying to work into a prompt was our impression generation created a large amount of duplicates. Identifying the duplicates and eliminating them takes some simple verbal requirements but has a lot of depth. If they cant't do max/min/mean/median, they surely can't do answer that (which our least senior developer was able to do, with guidance (mostly on optimizati…

Reading this, one could be confused into thinking that you’re arguing that a developer shouldn’t have to prove they can write find max of a list. Is this task too below them? Does it not adequately demonstrate knowledge? What else?

I think what you’re might be missing is the basic fact that programming is so stupid lucrative, especially compared to the other jobs that are out there, people will do anything to get these jobs. I’m pretty sure you want your new hire to know HOW the magical library list.max is written. Writing code is surely more than piecing together other people’s utility functions and ideas?

By way of analogy, should your new EE hire be able to compute basic ohms law voltage drop over a resistor? We teach kids this formula. Is this knowledge too below a senior electrical engineer to still know? Of course not.

Finally, someone’s attitude towards answering these questions will tell you a lot about what kind of person they are to work with. If they are surely and refuse to implement list.max, well then, what will their attitude be when it comes to grungy code tasks?

Re: Ask HN: Why not more hiring of junior devs, then on-the-job-training?

#180
post #81

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…

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…

> 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, can't agree enough.

Post reply on HN