Hacker News Reader

Comment by josephg | Hacker News Reader

I don't know! Is it their job?

The attention of senior engineers is the single most valuable, expensive and scarce commodity of a modern software company. The incentives are absolutely not aligned for most companies to make it worth their time to hire junior engineers.

But obviously thats a problem - because as you say, where else will senior engineers come from? And I don't think we have a good answer here. The old school answer was apprenticeship - a company trains you up, and in exchange you work for them for a time. But most companies are loathe to do that because you're likely to quit and go somewhere else for a pay bump as soon as you have enough skills and experience that you're worth hiring.

For my money this, right here, is the real problem with modern programming / career development. Whiteboard interviews are the least of our problems.

View on HN

But most companies are loathe to do that because you're likely to quit and go somewhere else for a pay bump as soon as you have enough skills and experience that you're worth hiring.

This is only true in bad companies. Good companies understand that people move on, and don't assume that someone is hired in to a role forever. Once you realise that hiring is an expensive process that you will always be doing you then you can optimize it appropriately.

Some really good companies even use it as a point in job adverts. There are plenty of senior developers who actively want to teach and mentor juniors, and will be happier working in companies that encourage that process. It's a good way of retaining those staff.

After the Y2K-bust, where are these good companies?

> Good companies understand that people move on, and don't assume that someone is hired in to a role forever. Once you realise that hiring is an expensive process that you will always be doing you then you can optimize it appropriately.

Yes, they understand this, so they simply do not hire people who need to be trained for a year or two to be effective hires.

> The old school answer was apprenticeship - a company trains you up, and in exchange you work for them for a time. But most companies are loathe to do that because you're likely to quit and go somewhere else for a pay bump as soon as you have enough skills and experience that you're worth hiring.

One problem is that companies with the means to fund this- FAANG and the like- are also the ones are incentivized to gatekeep the most to maintain their elite status and engineering superiority that leads to business edge. Startups, being naturally less risk adverse, are less likely to engage in formalized apprenticeship programs for juniors.

What happens instead is that you get the half-hearted approach of hiring college students to be interns or co-ops. Not all students are able to intern. The ones who do have a leg up once they graduate. Hence the stellar reputation of U of Waterloo grads.

There is the part where you give junior pay raise after he or she learns enough to get raise elsewhere.

If you're going to end up paying what it would cost you to hire the trained person anyway to avoid having your staff leave for higher wages, that heavily reduces your incentive to put a lot of resources in to training. Training + market rate compensation is more expensive than just market rate compensation.

I think you also have to account for the cost of acquiring senior staff. If you train them and pay them, your pipeline becomes more predictable than plucking them ad-hoc from other companies. That makes planning (your roadmap) more predictable.

While this is true, it seems to me that most companies don't actually have both choices. Instead it's "training + market rate compensation" or "you will forever struggle to have enough senior devs to accomplish your goals". If you can't attract talent, you have to grow it and pay to retain it. Simple as that, no?

But is training + market rate more expensive than hiring + market rate ?

Also, it seems to ignore the fact that training people is actually an incredibly useful thing to do to hone your skills as a senior dev, and that having to teach forces you to cristallize, simplify and explain thoughts and processes that you possibly never challenged before.

Tbh, I think I'm more productive and learning more when I have a decent intern to coach in my team than otherwise. So it's really a win-win situation.

Even if your junior-turned-okish developer goes away, if you did a good job and part on good terms you now have a working advertisement in another company. And maybe a couple years down the line they'll come back.

Investing in your workforce for the long term: when you're big enough I think you should do it. Having a "reserve" is also useful. You don't have devs doing nothing: you have devs learning, teaching and ready in case a business opportunity appears.

Market rate for junior + training while he/she is junior is not more expensive.

A lot of companies struggle to match internal comp changes with what they'd actually offer on day one, for some reason.

But there are bigger problems. I've experimented with training people in various ways over the years.

Reality is programmers move around a lot. They are attracted by interesting new problems where they feel they're learning. Staying at one firm for 20 years isn't likely these days. There's nothing wrong with that, but it means if you spend a few years training someone then after that time period they may leave anyway, even if their comp is reset to be competitive, because the new place can offer them equal comp + new problems.

Another issue is that a lot of training junior-to-senior is about imparting experience, wisdom, beliefs etc. At some point they can code and it's about the decisions being made, rather than inability to do them. A characteristic of junior devs that are growing their skills is they tend to latch on to trends harder and quicker than senior people who have maybe seen it before, and can differentiate their CV without buzzwords. If a junior comes to work one day and says "We need to Kubernetize all our things" and you say "Actually, our server count is stable and low, we don't need to use Kubernetes, but we do need this new customer-facing feature implemented" then it's quite possible they'll get frustrated, want to argue with you. Of course replace Kubernetes with Haskell, Linux distro of the day, Rust, Go, whatever seems hip and new.

It can just end up being draining for everyone. Of course debating these issues can be teaching of a form, but often juniors don't see it that way. The student wants to become the master faster than sometimes makes sense.

> if you spend a few years training someone then after that time period they may leave anyway

If it takes years of training till the person is useful and worth it, then there is something wrong with the way training is organized. We give juniors easier tasks then to seniors and train them, but we also expect them to be useful from the start basically.

It really should not take years till they make enough work for for salary + training.

> If a junior comes to work one day and says "We need to Kubernetize all our things" and you say "Actually, our server count is stable and low, we don't need to use Kubernetes, but we do need this new customer-facing feature implemented" then it's quite possible they'll get frustrated, want to argue with you. Of course replace Kubernetes with Haskell, Linux distro of the day, Rust, Go, whatever seems hip and new.

There is no difference between senior wanting to change things. This sort of conflict is normal and final decision is not done by junior.

Most people actually can handle not being given their way all the time. If they have no zone for own autonomy or decisions then they will get frustrated. But that zone should be smaller then the massive architectural decision.

Moreover, portion of people pushing toward new technology and being willing to experiment is something that company should have to keep healthy. Otherwise you all will stagnate.

A lot of it is about opportunity cost. Do you take someone fresh out of school or someone who's been around the block a few times if the latter costs only 50% more? The cost of even a junior but basically able programmer can be quite high if their work has to be redone (heck the cost of a non-junior but bad programmer can be high), so you end up needing to assign tasks that aren't that important or for which large slips can be tolerated. It can be tough to find a supply of such tasks sufficient to keep people fully throttled.

There is no difference between senior wanting to change things

Seniors are more likely to have been through several jobs and environments, and learned that tooling choices aren't that big a deal at the end of the day. They've also already (hopefully) got some accomplishments under their belt and don't need to redo other people's work to have something to show - they're more likely to do higher risk strategies like trying new things as a consequence.

Reply on news.ycombinator.com