Remote work will make it worse. Having worked for a remote-first company for over a decade, one thing I noticed is that every position was effectively senior level. Because you need staff able to work mostly autonomously, and at a minimum you need people experienced enough to pick up what they need to learn quickly from peers at the other end of a text chat or phone line. I'm sure we will work out how to do this better, but I think it is still a work in progress.

I had an interview this week where the recruiter was flat out and honest when I asked them "what's one thing you'd change about this company?" (something I've been asking a lot lately and being very observant to how different company reps answer) and he told me that he lamented and would absolutely change the fact that his hiring managers aren't actively seeking out or even remotely interested in trying to hire more juniors.

Gotta say, I respect the hell outta that fella for being so honest about that, partially because I've observed the very same phenomenon.

My experience is that this is an ongoing problem. For years there have been relatively few junior positions. No company wants to train people.

This also means that if you can afford to hire junior folks, you can get some real go-getters for a great (read, favorable to the company) salary.

But even junior salaries are going up, I've noticed.

You can also end up with apps that report "not hot dog." Had a situation like that with a recent college grad and for some reason my colleagues approved an absolute trash PR (as I was trying to talk the junior through why her code was garbage).

Next PR, more of the same. Now we have a $150k AND a (hopefully not more than) $65k dev fiddling with a simple change.

I think junior average salary at my company is around $75k now. Seniors are around $115k. A $40k gap is pretty big.

I don't know. I feel like most dev compensation is kind of random. Like does that senior really produce $40k more in value per year?

It should be easy for a senior to provide $40k more value than a junior employee, especially considering that a lot of the value a junior employee creates can be due to mentorship and working with senior employees.

But how do you evaluate value on a multi person and even multi team project? Is the tester or security person valued as much as the senior dev? Without them the devs work might do more harm than good, right? How do we put value on those intangibles?

I wanted to add to this. How do we evaluate value for managers? They can be making multiples of what the devs are yet they are overhead.

> They can be making multiples of what the devs are yet they are overhead.

I used to think this way. Then I became a manager. (Now I'm an individual contributor/IC again.) Oh, how wrong I was.

Managers do coordination, which is far different than building, but typically more valuable. Why is it more valuable? Leverage.

If I as an IC do the wrong thing and it doesn't get to production, it typically wastes my time (and any time needed to fix the mess, if doing so is harder than `git reset`).

If a team of people do the wrong thing, then that's an entire team's time wasted. Managers exist to ensure that a team is pointed in the right direction. Figuring this out could include meetings (oh so many meetings) with other parts of the business or customers, discussing priorities and timelines and ensuring dependencies are understood and met.

You also need to foster intrateam communication so that Bob learns that Alice has already partway solved problem X, or Alice learns that Tracy has experience in technology Y. Sure, you could rely on ICs to do this, and good ones will, but I've seen communication short circuit big issues and save lots of development time.

Is the manager's effort overhead if, by their efforts (even partially, with the help of other team members), the team solves the correct problem, rather than the wrong problem correctly?

This explanation ignores the political aspect of management (protecting your team from budget cuts, layoffs and being pulled into extraneous meetings/other efforts). I've intentionally ignored this because it was minimal at most places I've been a manager, so I can't speak out of personal experience. But I've heard about other places where this was a large chunk of the value added by management.

If the IC does the wrong thing, that could screw up the coordination between all these other parts.

I don't envy the politics, but the coordination and meetings are easy. I'd rather be doing that, but you can't get there without moving up the ladder. I was a tech lead for a year and it was probably half coordination and meetings and the other half was troubleshooting and development. It was great... except they didn't promote me to that level.

Evaluating value is usually not straightforward, unless the person was working alone it is always a subjective thing. If a junior is given a project alone, then they may provide zero value to the company if they can't complete it, but if they were paired with a senior, then together they should provide more value than the senior alone. Similarly, a manager's value is more indirect by providing a direction for the team but it adds up since they may be enabling the work of 5-10 people.

For support roles, their value comes from the costs that they help prevent. A security expert is like insurance, where they provide value by ensuring the company's product has the minimum chance of being exploited as that could damage the business in multiple ways.

Yeah, but that's kind of my point - it's not easily calculated, so how can we say a senior easily provides an extra $40k. If we are saying the manager can make a lot because they're basically directing 10 people. If you have a security expert on a team of 10 people, should they be worth similar? After all, the tool is likely worthless if it's insecure, making all those efforts by others fruitless.

I guess I'm just skeptical and jaded based on my past experiences.

Just because it isn't easily calculated on an individual basis doesn't mean that it is impossible to figure out. If you know how much revenue your group provides to the company and then look at who contributes what relatively as a good enough estimate.

Since you bring up a security team, it absolutely can be estimated there as well, what other companies have had hacks and what did it cost them? How does that compare to the risk on your product and the damage to the business if you were compromised?

Not to mention a $40k salary difference means you should be providing multiple times that difference in value to the company. Just providing $40k of additional value is a rounding error for most reasonably sized companies, I've worked on projects where two people provided >$1M of ongoing cost savings per year.

You are being pedantic developer fixated on numbers as a measure of value across the group. The world does not work this way. The business makes a decision based on what it takes to get what they need and salary can easily vary based on social aspects afterward. The number tells you something, but not everything.

"You are being pedantic developer fixated on numbers as a measure of value across the group. The world does not work this way."

Then how does it work? It seems that senior devs should make the same as junior devs if the numbers aren't tied to value.

"The business makes a decision based on what it takes to get what they need and salary can easily vary based on social aspects afterward. The number tells you something, but not everything."

On an individual level that might be true, but that doesn't address it at the aggregate level.

Actually, to me that senior salary feels low. I am on a Colorado slack and check out the salaries in the job postings (yay, Equal Pay Transparency Rule). I see a range from 100k 175k for "senior" developer positions.

Yeah, my company is cheap and it's in the Philly region. I think the range extends up to about $150k. That's just base salary, so you could roughly estimate another 10-15% in other comp. Most senior devs seem to fall towards the low end, possibly due to the way they hire and perform merit increases.

Easily, most of the time. They can make decisions quickly that juniors aren't even qualified to consider.

You need senior engineers in order to scale training people, so it's a catch-22.

It's only a catch-22 if you don't have the senior people. At least in my experience, companies have 80%+ senior and midlevel developers. The issue is that companies want to be cheap by letting other companies do the training and then taking them.

Honestly at this point as a staff level eng, not having junior levels to work with is a big turn-off. I love being able to break down projects in to tasks and not have to carry out every single one of those. Convincing one of my senior-level peers to work on a project or task can be near impossible, while the junior level folks will jump on them.

Lol I've seen this in action, lots of staff devs being architecture astronauts or diving super deep on a hot new technology, and meanwhile some intern is building the stupid webapp that actually gets used and makes money.

I would love to be an architect. It's all concepts and not really implementation beyond proof of concept. Concepts and problem solving is right up my alley. Unfortunately I need to be at least a senior dev before they will consider me. Plus it's like double my salary. Oh well.

At Mozilla at least, the architects are all some of the best programmers I know. They implement huge swaths of the architecture they propose.

That's nice. The people who are architects at my company are generally very good developers since you have to be a highly regarded senior dev to even be considered to the position. They don't work on the implementation though.

> The issue is that companies want to be cheap by letting other companies do the training and then taking them.

It's not cheap if they are willing to pay for it. That's why senior salaries keep going up. It's a tradeoff--they are willing to pay more for the privilege of not losing the time.

I don't really see it that way. Training people is more expensive than hiring a senior dev for the simple fact that you have to use a senior dev's time to train the new person anyways.

> Training people is more expensive than hiring a senior dev for the simple fact that you have to use a senior dev's time to train the new person anyways.

For the first N months, sure, but then, you have a senior and a trained junior, who is hopefully on their way to being a mid. So it's less of an expense and more of an investment in my eyes.

But like any upfront investment, there is a time when the costs outweigh the benefits, especially in the early days.

The "investment" part of the equation is where I see that model breaking down and failing. There's a lot of poaching and job-hopping, especially motivated by total comp. You could say it's always been that way, but in terms of the senior/mid/junior spread it seems like in our industry, employers would rather hire another senior than hire a junior who needs investment.

"So it's less of an expense and more of an investment in my eyes."

Too bad companies don't see it that way.

Well, I've been part of companies that have seen it that way, so they're out there!

But I agree, too few companies have that perspective.

That's why I stopped looking for an engineering job and became a technician. Started at the top of the pay scale due to my degree, which was nice.

For my current job the posting said 4 years of experience. I had 1 at the time.

Officially, my company is only hiring seniors, but if a decent junior applied (at least a year of experience inclusive of internships), I could see us taking them, especially with the right tech stack.

So, apply anyway.

This bums me out. On two levels:

   * The company doesn't have a clear idea of what they want, so they fall back on 'years of experience'. Lazy. I've written job descriptions and I know it's hard, but c'mon.
   * This will turn off talented folks that might make great team members (esp folks who don't apply unless they have 100% of the qualifications).

It is a more a case of what they want vs what they are willing to/forced to take in the current market.

I doubt they would openly consider that person, but when there is a candidate in front of them who has reasonably passed some questions and is willing to accept, I would hope they would budge.

>esp folks who don't apply unless they have 100% of the qualifications

This group disproportionately including women and excluding referrals (people who have the same experience, hobbies and education as your current employees)

- got his last job via referral.

I work for a company that has been pretty strong on pipelining in people as junior engineers and progressing them within the company, but even the direction we had while working remote from covid is that training in juniors while out of office is something that higher ups don't want to deal with (even if they would have little involvement in the process, such is corporate bureaucracy), so they're reticent to open positions to more junior level developers, and grads are pretty much right out unless they've interned with us previously.

At least from my perspective. It is a combination of needing a certain number of senior level employees to mentor junior employees and to lead projects and we have a good pipeline of junior candidates through our co-op program such that there is no need for us to post a job when we have known good options.