I'm not sure I understand the logic that we wouldn't hire Juniors because now we have AI.
What jobs are Juniors doing that AI can now do? I don't get juniors to build me entire web sites or implement complicated agentic pieces of work. Most of the time, we hire Juniors to help fill the talent pool with the hope that they will be productive in a few months. If we think that we don't need to refill the pool now because of AI, then that is daft although I can understand a period where companies are deciding whether they still need 50 Developers instead of 20 + AI.
For me, the worst change for Juniors is remote working. I don't want the experience of newly qualified engineer being sitting in their bedroom all day chatting to people on Teams and not knowing when they can interrupt and when they can't. We used to have an office so we could at least do 2 days per week together but we don't any more. The banter, the office, the observation, the overhearing things is a critical part of both learning engineering and learning how to be part of a workplace.
I think it is less about junior engineers, and more just about the kinds of work inexperienced/cheap developers are often doing: assembly line, JIRA-ticket-taker type development.
This is especially impacting Indian tech workers in the US [0] since these are often the types of roles that InfoSys and other foreign tech consulting firms are staffing. The new $100,000 fee to sponsor an H1B visa has made it difficult to justify hiring foreign tech workers when most of the time they are just going to be using American LLMs to do their work anyway.
The $100,000 H1B fee is probably one of the only ambiguously good things the Trump admin did.
Genuinely need a skilled worker? Well $100,000 is quite a lot, but not absurd relative to US salaries.
Just trying to bring over an Indian to work as an indentured slave and undercut American workers? Not so fast.
It's honestly a much better model than what most European countries do, which is make the company do a massive amount of paperwork to prove they can't hire a local (also costs a lot, but in a much more annoying and inefficient way)
Well, maybe you've been blessed with a better pool of juniors than the ones I've worked with. The ones I've worked with require exactly what an AI would require -- completely defined tickets with no ambiguity, lots of deliberate review, no guarantees that what they produce is bug-free.
At least with AI if it's not working out you just shut it off and it's done. If it's a person's livelihood that process takes a huge burden on all involved.
I agree with you about juniors and remote work - but like everything else: just figure it out.
Your customers aren't sitting next to you several times a week, yet they have no problem paying you and expecting you to get your job done. Sure, you might need to meet in person a couple of times a year but if you're smart enough to use a computer you can figure out how to work with someone in a different location. The issue is probably not the distance.
> we hire Juniors to help fill the talent pool with the hope that they will be productive in a few months
The sad reality for smaller companies is that we cannot compete salary-wise, which means training juniors that will leave the minute they become productive
But mostly the issue is with the market, there are only so many things you need a junior to do in a body shop that is getting squeezed
Other companies are also cash constrained and need to pivot fast to "AI"-something, which juniors wont really help with on the short-term
FWIW, your pessimism isn't entirely well-founded. If you're in a hot, tech-centric market, then yes, staff will be far more inclined to job hop for comp increases. But if you're hiring remote or you're located outside one of the very few tech hubs, employees value quality of life and workplace culture/relationships much more highly relative to comp. E.g. If you're hiring a SWE in Nashville or Portland or Columbus they're going to behave differently than if you're hiring in the Bay Area, Seattle area, NYC, Boston or Austin.
I think those sorts of priorities come later. I've never known a junior engineer that prioritized anything much beyond "holly shit, someone finally gave me a job, and I'm making money!". Then, with something on their resume, they realize how they're currently being taken advantage of, and hop to a significant pay increase.
Depends on the field I guess. Some smaller companies I've seen have dramatically lower leadership costs, so ICs get more of the share of the gross revenue. Even with perhaps a discount to clients for choosing a small business, they can still come out on top
WFH is good or bad depending on what task you need to do. My first year out of college (roughtly 1998!) my boss looked at me one day and said "you are on a complex problem: don't you dare come to the office tomorrow as we don't want you distracted". However I only made it a few hours at home because I soon ran into a problem where I needed to talk to someone else (my code was working all along but there was a hardware problem and once the FPGA was fixed it worked - since I was just out of school and the FPGA engineer has decades of experience they blamed me first and this once that was wrong)
That example, if you never came in the only thing an observing boss would likely know of is that you failed to do a task. It's also super easy for that FPGA engineer to not tell others he made the mistake.
I notice a general problem of wfh is people have zero connection to each other. It's easy for everyone to get "corporate" with one another because they have literally no care or connection to each other. It's really hard to let your coworker look bad if you hang out and chat every day. Not a lot of people I know are willing to toss a friend under the bus but wfh makes it less likely to have a real relationship.
Old friends and long time coworkers that are good at their job have basically no problems wfh.
I used to use the new hires to hold expertise so that I can spend a weekend at the beach without getting paged. That was the true selfish incentive in spending negative productivity where it takes me more time to teach than to do.
AI absorbs knowledge that the company can keep when I leave.
This used to be a capacity and bandwidth issue, as well as a timing issue with spare time.
I couldn't spend 9 PM to 11 PM on an odd Thu doing this with a human.
I think you really want to look at this in terms of the fact that it was already getting difficult to convince companies to hire junior engineers. They already don't want to pay for the inevitable several months of training before they're working at full speed. They want someone to be productive for the money now. And senior engineers are probably more productive per $ than juniors, even if the seniors are getting paid more. It doesn't help that a lot of people in our industry like to switch jobs every two years (which is, of course, further not helped by the reluctance of companies to give raises rather than hire new), which means there's a good chance they'll do nothing but pay their training only for some other company to harness the benefits. And companies, especially publicly traded companies, want decisions to benefit the company in the next quarter, and while that may not be immediately on everyone's mind during the hiring discussion it does trickle down.
But the junior will do at least some real work that hopefully benefits the company while they are there. There is at least something on the "benefit" side of the cost/benefit balance to entice them.
The problem that AI creates is that it tends to eliminate even that benefit. The task I would assign to the junior as their first task, which I expect to take them some weeks on as they not only do the nominal task but acquire all the surrounding skills and knowledge to finish it, is now a prompt and the senior engineer intermittently checking in on the AI's completion of it. It's hard to justify hiring the junior and paying them for six months if the senior can do the task(s) they'll finish before they jet off to their next job in a fraction of a day or two.
I have written this from a point of view that is foreign to me to explain the problem from their point of view. I do not accept this formulation wholesale, though there are substantial kernels of truth in it that anyone who wants to convince a real person that they are wrong about this assessment will have to deal with. I'm a very long term oriented person and still believe that raising up talent within your organization is extremely important. After all, in the end, what even is your organization except the talent you have within it and the system you've built for it to operate? Unless you think you can operate without any people at all, people are a vital part of your organization and you'd better be growing the best people you can or you can expect to get beat in the long term by an organization that did invest.
But when I look out at the world, what I see operating in most people and companies is much closer to the point of view I described first. That "beat in the long term", however long it may be, is certainly longer than one quarter or even one fiscal year.
I guess a lot of this depends on whether you consider juniors to be part of your talent pool. Unless you are retaining them, it is just subsidizing industry at large to train them.
I stayed less than a year at my first two jobs. They bet wrong.
This is standard because after a year of experience, a fresh junior dev is worth roughly twice as much on the open market. Most companies won't give a 100% raise because it would upset the apple cart with other employees wanting similar raises. So the junior dev has to move on to get paid what they're worth.
> This is standard because after a year of experience, a fresh junior dev is worth roughly twice as much on the open market.
My internal Brandolini's Law alarm is ringing loud and clear on this one. Absolutely not. This is only true for the best junior devs in the most competitive markets. From my professional experience, it is very difficult to keep star junior devs. The "gravity" pulling them away is simply too strong.
Pre-AI juniors were valuable because on many tasks, it was faster for me (senior eng) to write a quick spec have a conversation with a junior, and have them go off for a few hours or a few days and write the code, and then come back with it for review. I could do that with several junior engineers and pretty reasonably paralellize the work.
Now a junior takes my spec, drops it into Claude, and submits a PR a few minutes later. So I'm back to being the bottleneck -- there's constant pressure to provide specs and review code, and ultimately that process is just me having an indirect conversation with Claude (em dash is mine).
The junior is probably providing negative value, since it would be more efficient for me just to talk to Claude, and they're not learning anything, because it's really hard to learn anything by skimming code that's being pooped out by Claude.
I'm not sure what the solution to this is, I still think we need to train junior engineers. I think my best advice to juniors right now is stop using Claude so much. Use it to plan and answer questions, but you should still be writing code even it's slower. Because that's the only way they're going to learn enough to effectively guide AI and review output and get past being a net negative.
Do you think that its possible to raise the bar for junior engineers such that "you have AI now, so I need you to own farther up the review chain yourself"? I feel like I could answer either way. No, you need reps on projects to have that kind of judgement, that's what makes a senior. But also yes, while it will take the junior way longer to do that kind of review, they have the time to do it now, and its now the bottleneck so it makes sense to put their effort into that portion.
> because it's really hard to learn anything by skimming code that's being pooped out by Claude.
I think this is pretty dubious. It's true that you have to do more proactive learning with an agentic workflow, but it doesn't mean you can't learn stuff. Software engineers forged in the age of AI are not learning the same things their predecessors did or thinking about code in the same way, but the more curious people will still be better at the job, which is I think how it's always been. It seems a little unclear how much "AI brain rot" will be a force unto itself that neuters even the smartest of the juniors, but I think it's still an open question.
I think AI is a great learning tool - I have learned a ton from it.
But when I just ask to do a thing and then read the code (typical in a professional environment when there’s pressure to get shit delivered), i have not found that be an effective learning method.
When I’m learning from it I typically go out of my way to have it explain how to do things and things are the way they are. And I often leave the actual typing the code to myself, since that tends to force an active understanding that’s not required when you’re just reading.
If folks have other ideas on how to get that active understanding, I’d love to hear them. Because telling people they should type code seems like it’s going the way of telling people to write cursive.
This, pretty much exactly what I've been noticing too. Feel for the juniors though, its rough trying to learn when the tool in front of you can just spit the whole answer out.
I still think they're worth it, but tbh I just don't have a good answer yet for how to actually use them well, maybe just takes time to figure that out.
The other challenge with real people is the emotional aspect. Easier and faster to tell ai the code it wrote is terrible and needs to be redone completely, or maybe you just end the session and use a new model. Trickier to do with a human.
I'm not sure what the article actually has to say about the topic it presents. It seems to want to be something about not hiring junior talent (something by the way not restricted to the tech industry) but instead it ends up more a critique about people wanting to use a waterfall pipeline.
I'm just staring at the title, wondering how this offensive, double-and-a-half-negative phrase made it all the way to the frontpage. I'm going to skip this one for that obvious reason.
I agree with the sibling comment and also don't understand how the title is "offensive". I literally can't think of anything that could be offensive about any term in the title or the title as a whole.
Okay, that's an interesting complaint and I can understand it. For me, the title is QUITE clear.
There's a very strong narrative in the zeitgeist that "no one" is hiring entry level jobs anymore because they're being replaced with AI. There's some pretty solid hiring data for CS grads, at least, that backs this up, even when controlling for the down economy as a whole.
So the first part "Not hiring junior engineers" is very clear. Whatever this blog post is, it's a message to companies that are making these hiring decisions.
Then, the rest follows: "<that thing you're doing> won't work". It won't solve the problem you think you have.
Now that I've got your perspective, it IS possible for me to force my brain to incorrectly parse the title in a way that produces word salad, so I guess I can get it.
I had all the context I needed to easily grok it at first glance. The intended audience of the article (people who are deciding to hire fewer junior engineers) ALSO probably have that context. But it's not hard for me to believe that there are lots of people even on HN that didn't!
The problem I have: The CEO (and the investors, or the whole industry) is obsessed with ARR per employee. That's the key metric (in their mind).
It doesn't matter how much the employee costs. Let's assume you can hire two Juniors or one Senior for the same salary. If you have to optimize for ARR per employee - you can only hire one person. And if you have the choice between hiring a Junior or hiring a Senior... you're going to hire the Senior.
When you say the "whole industry", which industry are you referring to? The entire technology sector? Venture-backed companies specifically? Growth-stage VC-backed specifically?
This claim is counterintuitive to me in many business contexts - ex. for an established privately-held company issuing dividends to the owners, what incentive do owners have to emphasize ARR per employee rather than net income?
I would have liked the article to address more specifically what skills will be needed in the future and how engineers of all levels will learn them. Senior engineers in my circle feel their own brainrot, and at the same time feel like super wizards combining our deep software knowledge with the amazing AI dev tools. How will the AI native engineers learn the things, do they need to learn the things, what does anybody need to learn anyway? Let’s talk about it.
I don't understand when he says "the job has changed to using agents but human judgement is still required" and then goes on with that assumption will remain true for our lifetimes basically. But the elephant in the room is that's going away very soon right?
Think back to 2024 and how your job has changed over the last two years. It went from science fiction to reality. And as engineers surely we understand the concept of expotential growth. It's not just us outsiders using claude to make our code but internal anthropic engineers are using it to make claude itself better. (Probably they also use openai and gemini to double check stuff!) And that's the expotential loop. Does anyone really believe in 2028 human judgement will still be the thing?
> Think back to 2024 and how your job has changed over the last two years.
The programming language became a lot more terse. I press the keys on the keyboard considerably less now. Otherwise, I don't see much difference. The human end hasn't changed. Neither I, nor do I expect anyone else here, was hired to be a monkey infinitely typing to produce Shakespeare in software, so the human end is what the job is and always was.
There are too many new grads and the quality bar outside of target programs has dropped nor never existed to begin with.
And the target programs graduate around 15-20k EECS adjacent majors a year.
It's hard to justify hiring a (choosing random college) CS@Ouachita Baptist University
grad for $140K TC (50th percentile for an entry level SWE) or even $100K TC [0] (25th percentile for an entry level SWE) unless they are truly an outlier.
For example, back in college I had a buddy who really didn't want to take our OS class because it was hard, so he used transferology and found an OS class offered by some random Christian university in Texas where the class assignments were either writing biblical analogies for system programming concepts like memory management or basic fizzbuzz level assignments. My alma mater's CS program ended up blacklisting that college when admin was working on transferring the credits for that class and began reviewing the class's curriculum.
While that is an extreme example, outside of target programs, the quality bar drops dramatically, and an entire generation of grads are truly unemployable at the current prevailing wages.
Well, this is the thing. I was talking to someone a few days back, someone in Academia, and the conversation around the table was about how can we make it so we don't have to resort to increasingly more sophisticated ways to surveil students so they don't AI slop their entire degrees.
The problem is that universities, seemingly on a global scale, decided to run on economic incentives instead of academic ones. There are way too many people just doing degrees they have no interesting in learning about because university is just a way to a better job, and guess what, that "better job" no longer exists... and yet, year after year we have more and more people that have no clue what their credentials claim they should know by heart.
There wouldn't be too many new grads if all the capital wasn't locked up in a few Death Stars. A robust job market needs
oodles and oodles of dumb, doomed small businesses and start-up companies chasing stupid products and services that will never succeed long-term
which employ
not just top-of-class grads, but also mediocre grads and people who taught themselves from a few library books and even that one guy who can't build anything but is amazing at point out flaws and potential stumbling blocks
who
learn from their mistakes at these companies and grow into knowledgeable and diligent workers from the experiences they have actually working.
Instead, all of the money is locked up in VC and passive funds that are chasing the same companies and technologies and applicants as everyone else. All at the exact same time, even; there's no one sitting on the sidelines, waiting for the model du jour to fail so that they can fund another approach later. This is beyond grads and schools. The entire ecosystem is a generational disaster, which is why we're seeing unprecedented bank bailouts and unprecedented monetary policy working at backstopping and sling-shotting into unprecedented capital market highs. In other words, we stuck one big egg in the incubator, and we're doing everything and anything to keep it from going bad, because we only have the one big egg.
There is a temptation to declare a conspiracy against Millennials and Zoomers, but it's probably more likely that our "job creators" are just that stupid and self-interested.
When I started as a SWE my TC was around $150K and that was in the early 2010s.
And the Levels numbers line up with new grad salary bands from back in 2019-20 as well.
Of course there is also a regional factor, but regional mobility has always been high at target programs (eg. It doesn't matter if you live in Seattle, San Francisco, or NYC but everyone will know UT Austin or Purdue).
Wouldn't the logic to only hire Junior engineers if AI could do the work, what do you need the Senior salary for if they're both just asking AI to do things.
This is obviously assuming the ideology of an organization that would consider something like "We shouldn't be hiring engineers anymore" in the first place so they obviously have absolute trust in AI.
For now that won't work, based on my experience with LLMs, you still need a very senior engineer to prompt and review what was produced by the agent. A junior wouldn't have the experience to identify the flaws/issues.
In the future, yeah maybe, when LLMs are not as dumb as they are today.
This blogpost didn't really address the elephant in the room that increasingly the bottleneck is no longer the part that jr devs could help out with.
Every startup I know that hired some level of jr's and encouraged them to use AI found themselves in a code review bottleneck for basic code quality and architecture decisions. Many startups I know are largely forgoing jr devs.
Code quality regarding evolvability, reliability, maintainability is still part of the development process. All of the people who claimed src code is just assembly on Twitter some months ago have started chiming in that they were wrong.
I do wonder what this does to the talent pipeline like mentioned in the post.
The "not hiring juniors" thing started before agentic LLMs were a thing, but it was close enough that it's easy to mistake it for causation. The fact that people retroactively attribute this explanation to an industry trend just reinforces it in people's minds, otherwise people might have tried to hire juniors again and realized that it's not such a bad idea. By not hiring juniors, you're putting mid-level work on seniors, who could otherwise be dedicating themselves to solving hard-and-expert-level problems. You're handicapping your company.
There’s an irony too, in that junior engineers are more likely to understand and use AI tools, and quickly become more performant than their senior engineers asking questions on stack overflow. It’s what’s happening at my company and it feels silly since certain projects are way behind and constantly hiring because the very senior lead refuses to use AI
Seniors don’t use SO anymore, it virtually died if you look at traffic. The reason the market is so tough for juniors isn’t because seniors are bad at chat or agent workflows, it’s quite the opposite of what you say.
Did they ever? SO wasn't around during my junior days so I never got to experience it from that angle, but it looked like it would have been an incredible resource for those who juniored in its heyday. However, I never found it to be successful in delivering to the problems I encountered as a senior.
Right, SO was always better at answering beginner questions then advanced ones, except if the complex question had a broad appeal. Part of it is because the format is not good for asking a context-heavy question. Another part because you were dependent on the pool of people answering, and the more niched the question was (using a library not very popular, for instance) or the more expertise it required, the less likely you were to find someone.
Back then library and framework authors were also less competitive. Now open source authors do the full court press with very beautiful docs for both humans and agents.
"junior engineers are more likely to understand and use AI tools, and quickly become more performant than their senior engineers asking questions on stack overflow"
Anything to back up this claim? SO is dead, senior engineers don't use it. Why are junior more likely to understand and use AI tools than senior? I would counter with "senior are more likely to properly use and keep AI in check than junior".
It mildly upsets me, because I think the impulse to denigrate that which we oppose is a harmful one which, if cultivated, we can all too readily turn on people who don't deserve it. But it's not a real slur for real people. (Note that in Star Wars, where many people got this slur from, droids are – or at least, have the potential to be – people, albeit they are usually enslaved, and subject to arbitrary mind wipes.)
However, I couldn't care less about the feelings of chatbots. What I do care about is the feelings of the people to whom the slurs were originally directed, and (generally) the kind of culture that this creates. The use of slurs is a symptom, rather than a cause, but complaining about slurs does get people asking the kinds of questions you're asking, which is a positive.
I would not have said anything if the word "clanker", alone, had been used. But if you look at GP's other comments, I think you'll see evidence to support my musings about the kind of attitude that the practice of slur use cultivates.
"Retard" is a forbidden curse (read: slur) that holds great power in the English language.
I understand the risks of using this sort of language, and yet still I have determined that it is prudent to use the harshest rhetorical weapons that we have available to resist the large AI firms.
"Clanker" much less potent, much less powerful. I want an anti-AI slogan that stays in people's minds after they leave this comments section, and I think "AI is for retards" is that slogan.
The literal meaning of the word is "delayed", which seems less descriptive than the words you rejected in https://news.ycombinator.com/item?id=49183728. Do you understand why this word is "forbidden"? What's the advantage over a more vulgar word like "fuckwit"?
So, you're trying to upset (former) bullying victims, while having the people you're trying to criticise dismiss you as a mere bully? I don't see how this is an effective strategy.
> “That movie was so developmentally disabled”.
Nobody says this, and it's been 14 years since this article was published. The euphemism treadmill continues up until people stop treating the attribute as slur-worthy – which was the primary goal of this campaign.
> For that reason I think these comments are going to stick with people once they leave this comments section.
No, this is going to stick with me, because it's an attitude that I find exceptionally annoying: constantly repeating "I have a noble cause, therefore I am in the right", when you've already said it once. I'm reasonably confident I'm going to forget the details of your message by the end of the week, because you are far from the only edgelord on the internet, and you all go into my mental bucket of "not worth listening to", but I will remember that you were obnoxious about whatever it is you were saying.
No, we're worried about contributing to a hostile environment for people who have nothing to do with this complaint. To illustrate: replace the slur with a racial or sexist one, and see how it reads. If you want to insult people, take the time to come up with a relevant insult: don't just fire your gun into the air.
Hiring seniors is a waste of money. You need someone who knows enough to drive LLMs, but not too much more. The LLMs are good enough to do the debugging, the coding, and a big part of the design work and system architecture.
Most of the work today is manual testing and feeding the bugs back into the LLMs.
I've been programming for 15 years, but I've never really taken the plunge into 3D work. Always wanted to. So I figure, now that coding agents are so powerful, let's see if I can make something!
I've tried 3 experiments so far, and have given it serious effort. They're all terrible.
The reason they're terrible is that it's a skill issue. I don't have 3D skills. I don't know the lingo, I don't know how to describe my problems, and I don't know when the agent is shooting itself in the foot.
Yeah, you need to learn the jargon, and then use that to ask the agent to debug its own output. Sometimes you can get away by asking the agent to do the web searches and get it to figure out the stuff on its own. Again, it's not zero effort, but it's no longer skilled work.
The point of my comment is that it's absolutely skilled work. If someone with 15 years of experience in programming can't simply make a lateral move into a different type of programming without falling on their face, then it means there's more than just jargon. Each problem domain has its own unique nuances that humans need to tease out, and that requires domain skills.
Yep. I'm a network engineer/architect- love the velocity LLMs give me in developing tooling around APIs- but if you don't know the problem domain and why you'd WANT the tools and the actual output that is useful, having the AI would be absolutely useless.
It's lived experience. My management is a lot happier when I move too fast to really pay attention to the problems and use my expertise, and the output is good enough that nobody really complains. Building most software is no longer skilled work; it takes minimal training. The industry just hasn't caught up yet.
Well. I own my business and I really hate this attitude that some startups executives have. I want quality. Not blind speed. I want speed to be a by product of a well built product and a system that builds it. Not a bunch of slop thrown over the wall that I have to then debug and fix.
The AI is pretty good at debugging and fixing it. It's quite a bit better at it than writing the code, to be honest.
And, you're right, I used to enjoy my job a lot more before AI. But in the end, the paychecks keep coming, and I can produce a lot of acceptable code quickly with little skill. Skill in coding no longer makes economic sense.
I'm not sure I understand the logic that we wouldn't hire Juniors because now we have AI.
What jobs are Juniors doing that AI can now do? I don't get juniors to build me entire web sites or implement complicated agentic pieces of work. Most of the time, we hire Juniors to help fill the talent pool with the hope that they will be productive in a few months. If we think that we don't need to refill the pool now because of AI, then that is daft although I can understand a period where companies are deciding whether they still need 50 Developers instead of 20 + AI.
For me, the worst change for Juniors is remote working. I don't want the experience of newly qualified engineer being sitting in their bedroom all day chatting to people on Teams and not knowing when they can interrupt and when they can't. We used to have an office so we could at least do 2 days per week together but we don't any more. The banter, the office, the observation, the overhearing things is a critical part of both learning engineering and learning how to be part of a workplace.
I think it is less about junior engineers, and more just about the kinds of work inexperienced/cheap developers are often doing: assembly line, JIRA-ticket-taker type development.
This is especially impacting Indian tech workers in the US [0] since these are often the types of roles that InfoSys and other foreign tech consulting firms are staffing. The new $100,000 fee to sponsor an H1B visa has made it difficult to justify hiring foreign tech workers when most of the time they are just going to be using American LLMs to do their work anyway.
[0] https://thefederal.com/category/news/h1b-visa-indian-tech-wo...
The $100,000 H1B fee is probably one of the only ambiguously good things the Trump admin did.
Genuinely need a skilled worker? Well $100,000 is quite a lot, but not absurd relative to US salaries.
Just trying to bring over an Indian to work as an indentured slave and undercut American workers? Not so fast.
It's honestly a much better model than what most European countries do, which is make the company do a massive amount of paperwork to prove they can't hire a local (also costs a lot, but in a much more annoying and inefficient way)
Well, maybe you've been blessed with a better pool of juniors than the ones I've worked with. The ones I've worked with require exactly what an AI would require -- completely defined tickets with no ambiguity, lots of deliberate review, no guarantees that what they produce is bug-free.
At least with AI if it's not working out you just shut it off and it's done. If it's a person's livelihood that process takes a huge burden on all involved.
I agree with you about juniors and remote work - but like everything else: just figure it out.
Your customers aren't sitting next to you several times a week, yet they have no problem paying you and expecting you to get your job done. Sure, you might need to meet in person a couple of times a year but if you're smart enough to use a computer you can figure out how to work with someone in a different location. The issue is probably not the distance.
Totally agree about remote work for juniors. Even as a senior I feel like it's diminished some of my skills, in spite of all the benefits it brings.
> we hire Juniors to help fill the talent pool with the hope that they will be productive in a few months
The sad reality for smaller companies is that we cannot compete salary-wise, which means training juniors that will leave the minute they become productive
But mostly the issue is with the market, there are only so many things you need a junior to do in a body shop that is getting squeezed
Other companies are also cash constrained and need to pivot fast to "AI"-something, which juniors wont really help with on the short-term
FWIW, your pessimism isn't entirely well-founded. If you're in a hot, tech-centric market, then yes, staff will be far more inclined to job hop for comp increases. But if you're hiring remote or you're located outside one of the very few tech hubs, employees value quality of life and workplace culture/relationships much more highly relative to comp. E.g. If you're hiring a SWE in Nashville or Portland or Columbus they're going to behave differently than if you're hiring in the Bay Area, Seattle area, NYC, Boston or Austin.
I think those sorts of priorities come later. I've never known a junior engineer that prioritized anything much beyond "holly shit, someone finally gave me a job, and I'm making money!". Then, with something on their resume, they realize how they're currently being taken advantage of, and hop to a significant pay increase.
Depends on the field I guess. Some smaller companies I've seen have dramatically lower leadership costs, so ICs get more of the share of the gross revenue. Even with perhaps a discount to clients for choosing a small business, they can still come out on top
Agreed wfh to me is just generally bad for any creative work but for a new person it must be taking aways years of development.
WFH is good or bad depending on what task you need to do. My first year out of college (roughtly 1998!) my boss looked at me one day and said "you are on a complex problem: don't you dare come to the office tomorrow as we don't want you distracted". However I only made it a few hours at home because I soon ran into a problem where I needed to talk to someone else (my code was working all along but there was a hardware problem and once the FPGA was fixed it worked - since I was just out of school and the FPGA engineer has decades of experience they blamed me first and this once that was wrong)
That example, if you never came in the only thing an observing boss would likely know of is that you failed to do a task. It's also super easy for that FPGA engineer to not tell others he made the mistake.
I notice a general problem of wfh is people have zero connection to each other. It's easy for everyone to get "corporate" with one another because they have literally no care or connection to each other. It's really hard to let your coworker look bad if you hang out and chat every day. Not a lot of people I know are willing to toss a friend under the bus but wfh makes it less likely to have a real relationship.
Old friends and long time coworkers that are good at their job have basically no problems wfh.
> What jobs are Juniors doing that AI can now do?
I used to use the new hires to hold expertise so that I can spend a weekend at the beach without getting paged. That was the true selfish incentive in spending negative productivity where it takes me more time to teach than to do.
AI absorbs knowledge that the company can keep when I leave.
This used to be a capacity and bandwidth issue, as well as a timing issue with spare time.
I couldn't spend 9 PM to 11 PM on an odd Thu doing this with a human.
The goal is prevent homegrown talent, and give a reason to import H2B of offshore.
I think you really want to look at this in terms of the fact that it was already getting difficult to convince companies to hire junior engineers. They already don't want to pay for the inevitable several months of training before they're working at full speed. They want someone to be productive for the money now. And senior engineers are probably more productive per $ than juniors, even if the seniors are getting paid more. It doesn't help that a lot of people in our industry like to switch jobs every two years (which is, of course, further not helped by the reluctance of companies to give raises rather than hire new), which means there's a good chance they'll do nothing but pay their training only for some other company to harness the benefits. And companies, especially publicly traded companies, want decisions to benefit the company in the next quarter, and while that may not be immediately on everyone's mind during the hiring discussion it does trickle down.
But the junior will do at least some real work that hopefully benefits the company while they are there. There is at least something on the "benefit" side of the cost/benefit balance to entice them.
The problem that AI creates is that it tends to eliminate even that benefit. The task I would assign to the junior as their first task, which I expect to take them some weeks on as they not only do the nominal task but acquire all the surrounding skills and knowledge to finish it, is now a prompt and the senior engineer intermittently checking in on the AI's completion of it. It's hard to justify hiring the junior and paying them for six months if the senior can do the task(s) they'll finish before they jet off to their next job in a fraction of a day or two.
I have written this from a point of view that is foreign to me to explain the problem from their point of view. I do not accept this formulation wholesale, though there are substantial kernels of truth in it that anyone who wants to convince a real person that they are wrong about this assessment will have to deal with. I'm a very long term oriented person and still believe that raising up talent within your organization is extremely important. After all, in the end, what even is your organization except the talent you have within it and the system you've built for it to operate? Unless you think you can operate without any people at all, people are a vital part of your organization and you'd better be growing the best people you can or you can expect to get beat in the long term by an organization that did invest.
But when I look out at the world, what I see operating in most people and companies is much closer to the point of view I described first. That "beat in the long term", however long it may be, is certainly longer than one quarter or even one fiscal year.
I guess a lot of this depends on whether you consider juniors to be part of your talent pool. Unless you are retaining them, it is just subsidizing industry at large to train them.
I stayed less than a year at my first two jobs. They bet wrong.
This is standard because after a year of experience, a fresh junior dev is worth roughly twice as much on the open market. Most companies won't give a 100% raise because it would upset the apple cart with other employees wanting similar raises. So the junior dev has to move on to get paid what they're worth.
You win some, you lose some. Maybe your coworker juniors became seniors and didn't negotiate higher pay.
[flagged]
You’re in a whirlwind of propaganda at the moment. The talking points and takes are mostly planted. Even the title has an inner circle nod to it.
what does this mean? can you explain? legit question not rhetorical
Pre-AI juniors were valuable because on many tasks, it was faster for me (senior eng) to write a quick spec have a conversation with a junior, and have them go off for a few hours or a few days and write the code, and then come back with it for review. I could do that with several junior engineers and pretty reasonably paralellize the work.
Now a junior takes my spec, drops it into Claude, and submits a PR a few minutes later. So I'm back to being the bottleneck -- there's constant pressure to provide specs and review code, and ultimately that process is just me having an indirect conversation with Claude (em dash is mine).
The junior is probably providing negative value, since it would be more efficient for me just to talk to Claude, and they're not learning anything, because it's really hard to learn anything by skimming code that's being pooped out by Claude.
I'm not sure what the solution to this is, I still think we need to train junior engineers. I think my best advice to juniors right now is stop using Claude so much. Use it to plan and answer questions, but you should still be writing code even it's slower. Because that's the only way they're going to learn enough to effectively guide AI and review output and get past being a net negative.
Do you think that its possible to raise the bar for junior engineers such that "you have AI now, so I need you to own farther up the review chain yourself"? I feel like I could answer either way. No, you need reps on projects to have that kind of judgement, that's what makes a senior. But also yes, while it will take the junior way longer to do that kind of review, they have the time to do it now, and its now the bottleneck so it makes sense to put their effort into that portion.
> because it's really hard to learn anything by skimming code that's being pooped out by Claude.
I think this is pretty dubious. It's true that you have to do more proactive learning with an agentic workflow, but it doesn't mean you can't learn stuff. Software engineers forged in the age of AI are not learning the same things their predecessors did or thinking about code in the same way, but the more curious people will still be better at the job, which is I think how it's always been. It seems a little unclear how much "AI brain rot" will be a force unto itself that neuters even the smartest of the juniors, but I think it's still an open question.
I think AI is a great learning tool - I have learned a ton from it.
But when I just ask to do a thing and then read the code (typical in a professional environment when there’s pressure to get shit delivered), i have not found that be an effective learning method.
When I’m learning from it I typically go out of my way to have it explain how to do things and things are the way they are. And I often leave the actual typing the code to myself, since that tends to force an active understanding that’s not required when you’re just reading.
If folks have other ideas on how to get that active understanding, I’d love to hear them. Because telling people they should type code seems like it’s going the way of telling people to write cursive.
This, pretty much exactly what I've been noticing too. Feel for the juniors though, its rough trying to learn when the tool in front of you can just spit the whole answer out. I still think they're worth it, but tbh I just don't have a good answer yet for how to actually use them well, maybe just takes time to figure that out.
The other challenge with real people is the emotional aspect. Easier and faster to tell ai the code it wrote is terrible and needs to be redone completely, or maybe you just end the session and use a new model. Trickier to do with a human.
SAT for junior developers; questions are code snippets and architectural decisions.
I'm not sure what the article actually has to say about the topic it presents. It seems to want to be something about not hiring junior talent (something by the way not restricted to the tech industry) but instead it ends up more a critique about people wanting to use a waterfall pipeline.
Double negative title implies clickbait :)
I'm just staring at the title, wondering how this offensive, double-and-a-half-negative phrase made it all the way to the frontpage. I'm going to skip this one for that obvious reason.
I agree with the sibling comment and also don't understand how the title is "offensive". I literally can't think of anything that could be offensive about any term in the title or the title as a whole.
It's the logic that is offensive. Mimically restated - The title isn't incorrect but it won't be misunderstood by few.
A synonym for offensive is disgusting.
Okay, that's an interesting complaint and I can understand it. For me, the title is QUITE clear.
There's a very strong narrative in the zeitgeist that "no one" is hiring entry level jobs anymore because they're being replaced with AI. There's some pretty solid hiring data for CS grads, at least, that backs this up, even when controlling for the down economy as a whole.
So the first part "Not hiring junior engineers" is very clear. Whatever this blog post is, it's a message to companies that are making these hiring decisions.
Then, the rest follows: "<that thing you're doing> won't work". It won't solve the problem you think you have.
Now that I've got your perspective, it IS possible for me to force my brain to incorrectly parse the title in a way that produces word salad, so I guess I can get it.
I had all the context I needed to easily grok it at first glance. The intended audience of the article (people who are deciding to hire fewer junior engineers) ALSO probably have that context. But it's not hard for me to believe that there are lots of people even on HN that didn't!
Thanks for clarifying
It's not really a double negative as the negations are in different clauses. If you remove both negations, you get a completely different statement:
> Hiring junior engineers will solve the problem you think you have.
Clause change doesn't rescue the logic. If anything it makes it harder to process.
Fixed. I would click that.[dead]
The problem I have: The CEO (and the investors, or the whole industry) is obsessed with ARR per employee. That's the key metric (in their mind).
It doesn't matter how much the employee costs. Let's assume you can hire two Juniors or one Senior for the same salary. If you have to optimize for ARR per employee - you can only hire one person. And if you have the choice between hiring a Junior or hiring a Senior... you're going to hire the Senior.
Goodhart's law fully applies here.
When you say the "whole industry", which industry are you referring to? The entire technology sector? Venture-backed companies specifically? Growth-stage VC-backed specifically?
This claim is counterintuitive to me in many business contexts - ex. for an established privately-held company issuing dividends to the owners, what incentive do owners have to emphasize ARR per employee rather than net income?
I would have liked the article to address more specifically what skills will be needed in the future and how engineers of all levels will learn them. Senior engineers in my circle feel their own brainrot, and at the same time feel like super wizards combining our deep software knowledge with the amazing AI dev tools. How will the AI native engineers learn the things, do they need to learn the things, what does anybody need to learn anyway? Let’s talk about it.
This is a great example of a blog post that isn't obviously AI written, but that also doesn't make much sense.
> Not hiring junior engineers won't solve the problem you think you have
No payoff, what is the problem they think they have and why is it wrong?
> The junior engineer question rests on a few assumptions, and all of them are flawed.
No payoff, what are the assumptions and why are they flawed?
I don't understand when he says "the job has changed to using agents but human judgement is still required" and then goes on with that assumption will remain true for our lifetimes basically. But the elephant in the room is that's going away very soon right?
Think back to 2024 and how your job has changed over the last two years. It went from science fiction to reality. And as engineers surely we understand the concept of expotential growth. It's not just us outsiders using claude to make our code but internal anthropic engineers are using it to make claude itself better. (Probably they also use openai and gemini to double check stuff!) And that's the expotential loop. Does anyone really believe in 2028 human judgement will still be the thing?
Maybe if hypothetically all stakeholders express all of their concerns and desires clearly in channels AI can pick up constantly.
> Think back to 2024 and how your job has changed over the last two years.
The programming language became a lot more terse. I press the keys on the keyboard considerably less now. Otherwise, I don't see much difference. The human end hasn't changed. Neither I, nor do I expect anyone else here, was hired to be a monkey infinitely typing to produce Shakespeare in software, so the human end is what the job is and always was.
very hard for junior engineers out there now.
There are too many new grads and the quality bar outside of target programs has dropped nor never existed to begin with.
And the target programs graduate around 15-20k EECS adjacent majors a year.
It's hard to justify hiring a (choosing random college) CS@Ouachita Baptist University grad for $140K TC (50th percentile for an entry level SWE) or even $100K TC [0] (25th percentile for an entry level SWE) unless they are truly an outlier.
For example, back in college I had a buddy who really didn't want to take our OS class because it was hard, so he used transferology and found an OS class offered by some random Christian university in Texas where the class assignments were either writing biblical analogies for system programming concepts like memory management or basic fizzbuzz level assignments. My alma mater's CS program ended up blacklisting that college when admin was working on transferring the credits for that class and began reviewing the class's curriculum.
While that is an extreme example, outside of target programs, the quality bar drops dramatically, and an entire generation of grads are truly unemployable at the current prevailing wages.
[0] - https://www.levels.fyi/t/software-engineer/levels/entry-leve...
Well, this is the thing. I was talking to someone a few days back, someone in Academia, and the conversation around the table was about how can we make it so we don't have to resort to increasingly more sophisticated ways to surveil students so they don't AI slop their entire degrees.
The problem is that universities, seemingly on a global scale, decided to run on economic incentives instead of academic ones. There are way too many people just doing degrees they have no interesting in learning about because university is just a way to a better job, and guess what, that "better job" no longer exists... and yet, year after year we have more and more people that have no clue what their credentials claim they should know by heart.
There wouldn't be too many new grads if all the capital wasn't locked up in a few Death Stars. A robust job market needs
which employ who Instead, all of the money is locked up in VC and passive funds that are chasing the same companies and technologies and applicants as everyone else. All at the exact same time, even; there's no one sitting on the sidelines, waiting for the model du jour to fail so that they can fund another approach later. This is beyond grads and schools. The entire ecosystem is a generational disaster, which is why we're seeing unprecedented bank bailouts and unprecedented monetary policy working at backstopping and sling-shotting into unprecedented capital market highs. In other words, we stuck one big egg in the incubator, and we're doing everything and anything to keep it from going bad, because we only have the one big egg.There is a temptation to declare a conspiracy against Millennials and Zoomers, but it's probably more likely that our "job creators" are just that stupid and self-interested.
At least in 2020 when I was in this pool, the rate for recent grads from an average program was $75k-$85k
You were at the lower end of the TC scale.
When I started as a SWE my TC was around $150K and that was in the early 2010s.
And the Levels numbers line up with new grad salary bands from back in 2019-20 as well.
Of course there is also a regional factor, but regional mobility has always been high at target programs (eg. It doesn't matter if you live in Seattle, San Francisco, or NYC but everyone will know UT Austin or Purdue).
Wouldn't the logic to only hire Junior engineers if AI could do the work, what do you need the Senior salary for if they're both just asking AI to do things.
This is obviously assuming the ideology of an organization that would consider something like "We shouldn't be hiring engineers anymore" in the first place so they obviously have absolute trust in AI.
For now that won't work, based on my experience with LLMs, you still need a very senior engineer to prompt and review what was produced by the agent. A junior wouldn't have the experience to identify the flaws/issues.
In the future, yeah maybe, when LLMs are not as dumb as they are today.
This blogpost didn't really address the elephant in the room that increasingly the bottleneck is no longer the part that jr devs could help out with.
Every startup I know that hired some level of jr's and encouraged them to use AI found themselves in a code review bottleneck for basic code quality and architecture decisions. Many startups I know are largely forgoing jr devs.
Code quality regarding evolvability, reliability, maintainability is still part of the development process. All of the people who claimed src code is just assembly on Twitter some months ago have started chiming in that they were wrong.
I do wonder what this does to the talent pipeline like mentioned in the post.
> The AI version of this argument is not a new insight. It’s an old (and mistaken) preference, wearing new clothes.
Everything sounds like AI now when you squint just a bit.
The "not hiring juniors" thing started before agentic LLMs were a thing, but it was close enough that it's easy to mistake it for causation. The fact that people retroactively attribute this explanation to an industry trend just reinforces it in people's minds, otherwise people might have tried to hire juniors again and realized that it's not such a bad idea. By not hiring juniors, you're putting mid-level work on seniors, who could otherwise be dedicating themselves to solving hard-and-expert-level problems. You're handicapping your company.
There’s an irony too, in that junior engineers are more likely to understand and use AI tools, and quickly become more performant than their senior engineers asking questions on stack overflow. It’s what’s happening at my company and it feels silly since certain projects are way behind and constantly hiring because the very senior lead refuses to use AI
Seniors don’t use SO anymore, it virtually died if you look at traffic. The reason the market is so tough for juniors isn’t because seniors are bad at chat or agent workflows, it’s quite the opposite of what you say.
> Seniors don’t use SO anymore
Did they ever? SO wasn't around during my junior days so I never got to experience it from that angle, but it looked like it would have been an incredible resource for those who juniored in its heyday. However, I never found it to be successful in delivering to the problems I encountered as a senior.
Right, SO was always better at answering beginner questions then advanced ones, except if the complex question had a broad appeal. Part of it is because the format is not good for asking a context-heavy question. Another part because you were dependent on the pool of people answering, and the more niched the question was (using a library not very popular, for instance) or the more expertise it required, the less likely you were to find someone.
Back then library and framework authors were also less competitive. Now open source authors do the full court press with very beautiful docs for both humans and agents.
"junior engineers are more likely to understand and use AI tools, and quickly become more performant than their senior engineers asking questions on stack overflow"
Anything to back up this claim? SO is dead, senior engineers don't use it. Why are junior more likely to understand and use AI tools than senior? I would counter with "senior are more likely to properly use and keep AI in check than junior".
[flagged]
[dead]
[dead]
[flagged]
Please don't use human slurs for computer programs you don't like.
> Please don't use human slurs for computer programs you don't like.
Good point. We should use different slurs for machines than the ones we use for humans :-)
Why are we defending the feelings of chatbots? Does the word clanker upset you too?
It’s not about defending the feelings of chat bots but it does normalize name-calling for the person who is using the word clanker.
It’s not good for your mental health.
It mildly upsets me, because I think the impulse to denigrate that which we oppose is a harmful one which, if cultivated, we can all too readily turn on people who don't deserve it. But it's not a real slur for real people. (Note that in Star Wars, where many people got this slur from, droids are – or at least, have the potential to be – people, albeit they are usually enslaved, and subject to arbitrary mind wipes.)
However, I couldn't care less about the feelings of chatbots. What I do care about is the feelings of the people to whom the slurs were originally directed, and (generally) the kind of culture that this creates. The use of slurs is a symptom, rather than a cause, but complaining about slurs does get people asking the kinds of questions you're asking, which is a positive.
I would not have said anything if the word "clanker", alone, had been used. But if you look at GP's other comments, I think you'll see evidence to support my musings about the kind of attitude that the practice of slur use cultivates.
"Retard" is a forbidden curse (read: slur) that holds great power in the English language.
I understand the risks of using this sort of language, and yet still I have determined that it is prudent to use the harshest rhetorical weapons that we have available to resist the large AI firms.
"Clanker" much less potent, much less powerful. I want an anti-AI slogan that stays in people's minds after they leave this comments section, and I think "AI is for retards" is that slogan.
The literal meaning of the word is "delayed", which seems less descriptive than the words you rejected in https://news.ycombinator.com/item?id=49183728. Do you understand why this word is "forbidden"? What's the advantage over a more vulgar word like "fuckwit"?
[dead]
So, you're trying to upset (former) bullying victims, while having the people you're trying to criticise dismiss you as a mere bully? I don't see how this is an effective strategy.
> “That movie was so developmentally disabled”.
Nobody says this, and it's been 14 years since this article was published. The euphemism treadmill continues up until people stop treating the attribute as slur-worthy – which was the primary goal of this campaign.
> For that reason I think these comments are going to stick with people once they leave this comments section.
No, this is going to stick with me, because it's an attitude that I find exceptionally annoying: constantly repeating "I have a noble cause, therefore I am in the right", when you've already said it once. I'm reasonably confident I'm going to forget the details of your message by the end of the week, because you are far from the only edgelord on the internet, and you all go into my mental bucket of "not worth listening to", but I will remember that you were obnoxious about whatever it is you were saying.
[dead]
If it’s so necessary make sure to use your real account next time
[flagged]
you can be critical without being abraisive or demeaning about it.
a professional opinion includes some professionalism
Are we worried about offending the machine?
No, we're worried about contributing to a hostile environment for people who have nothing to do with this complaint. To illustrate: replace the slur with a racial or sexist one, and see how it reads. If you want to insult people, take the time to come up with a relevant insult: don't just fire your gun into the air.
If someone said ChatGPT was a whiny bitch, I'd think them a bit odd, but I wouldn't start complaining about sexism.
[flagged]
There's no need to use slurs.
[dead]
[flagged]
it’s not necessary, you can just say you don’t like it. not everything has to be vulgar
[dead]
Hiring seniors is a waste of money. You need someone who knows enough to drive LLMs, but not too much more. The LLMs are good enough to do the debugging, the coding, and a big part of the design work and system architecture.
Most of the work today is manual testing and feeding the bugs back into the LLMs.
I've been programming for 15 years, but I've never really taken the plunge into 3D work. Always wanted to. So I figure, now that coding agents are so powerful, let's see if I can make something!
I've tried 3 experiments so far, and have given it serious effort. They're all terrible.
The reason they're terrible is that it's a skill issue. I don't have 3D skills. I don't know the lingo, I don't know how to describe my problems, and I don't know when the agent is shooting itself in the foot.
Yeah, you need to learn the jargon, and then use that to ask the agent to debug its own output. Sometimes you can get away by asking the agent to do the web searches and get it to figure out the stuff on its own. Again, it's not zero effort, but it's no longer skilled work.
The point of my comment is that it's absolutely skilled work. If someone with 15 years of experience in programming can't simply make a lateral move into a different type of programming without falling on their face, then it means there's more than just jargon. Each problem domain has its own unique nuances that humans need to tease out, and that requires domain skills.
Yep. I'm a network engineer/architect- love the velocity LLMs give me in developing tooling around APIs- but if you don't know the problem domain and why you'd WANT the tools and the actual output that is useful, having the AI would be absolutely useless.
Is this a poorly instructed llm? Or a poorly constructed thought?
It's lived experience. My management is a lot happier when I move too fast to really pay attention to the problems and use my expertise, and the output is good enough that nobody really complains. Building most software is no longer skilled work; it takes minimal training. The industry just hasn't caught up yet.
Well. I own my business and I really hate this attitude that some startups executives have. I want quality. Not blind speed. I want speed to be a by product of a well built product and a system that builds it. Not a bunch of slop thrown over the wall that I have to then debug and fix.
The AI is pretty good at debugging and fixing it. It's quite a bit better at it than writing the code, to be honest.
And, you're right, I used to enjoy my job a lot more before AI. But in the end, the paychecks keep coming, and I can produce a lot of acceptable code quickly with little skill. Skill in coding no longer makes economic sense.
This approach accumulates codebase-understanding debt and the call to pay the piper could come at any time
Maybe. Challenge for you: take the last 10 production outages, and paste the symptoms into Fable or Opus 5, and ask it for a diagnosis.
How many does it one shot in less time than your outage lasted?