Should I get rid of juniors that generate AI slop?

Posted by Leopatto@reddit | ExperiencedDevs | View on Reddit | 432 comments

We’re dealing with a problem at my company that’s annoying, but honestly, it's not that surprising. Out of ~70 devs, about 10% are juniors. Lately I asked a few of my mids/seniors to pair program with them to see where they’re at — and what we have noticed is that a lot of them, when they hit something hard or challenging, they instantly open ChatGPT (or similar) and start writing out the problem and copying the solution; without understanding the problem or how to solve it. Now I get that AI tools are part of the workflow these days, but the point of pair programming is to learn from the more experienced dev, ask questions, think through problems together — not to just offload the thinking to an LLM. These juniors are working on client projects, and the stuff they generate is often low-quality, barely-understood code that my more experienced devs then have to clean up, which makes them annoyed - circle keeps expanding. That wastes time, burns money, and adds no real value - I'm running a business, and I do expect value in some form being generated. So now I’m stuck. Is this a hiring problem? (Our process is: HR screen > technical test [not live coding] > culture fit stage > decision.) Should I put more structure into mentorship and training? Or should I just cut the ones who aren’t delivering and spend more money on experienced engineers (which I could easily afford)? Appreciate any real-world input from people who’ve been in a similar spot. What actually works here?

Reply to Post

Reply

432 Comments

[-]

high_throughput@reddit

> These juniors are working on client projects, and the stuff they generate is often low-quality, barely-understood code that my more experienced devs then have to clean up Don't let them commit slop and then ask seniors clean it up after. Do code reviews and stop slop from being merged.

Reply

[-]

dogo_fren@reddit

That’s a huge and wasted effort from Seniors TBH.

Reply

[-]

Schillelagh@reddit

Not if the juniors learn, or are weeded out. Not if it saves a client by catching an issue a junior introduced with AI. The issue is here is not AI, or even bad code per se. It’s management. They are not taking the time to provide clear instructions on correct behaviors, monitor the behaviors, and then hold them accountable when they step out of line.

Reply

[-]

dogo_fren@reddit

Checking the output of an LLM because the dev couldn’t be arsed to do it is waste, I stand my ground. The devs doing it will just feed the suggestions to the LLM again. I don’t need another person to do it.

Reply

[-]

Schillelagh@reddit

I don’t disagree. I’m not suggesting review all the code, just enough to establish that it’s unchecked slop. Then, document the issue, have management write up if necessary. That’s what’s missing.

Reply

[-]

dogo_fren@reddit

So just reject without comments? How to justify? I would need to point to some pre agreed policy or it would be very offensive to do this.

Reply

[-]

Schillelagh@reddit

No. You reject with comments, but you don't review the entire PR once you find glaring issues (e.g. not matching or missing requirements, doesn't pass tests). And if you know it's because it's AI slop, make specific note of that issue, and instruct the junior to avoid over-relaying on AI and review the AI's work. For example, my team does a fair bit of front-end work. If I open an PR and find their dev environment is missing fields, wrong brand colors, or doesn't even function, then I won't bother reviewing the code. The problem isn't using LLMs for code per se. The issue is the juniors aren't doing the most basic work to validate their code.

Reply

[-]

high_throughput@reddit

The code review feedback wouldn't be things like "stream the data from disk instead of reading it all into memory first". It would rather be "it's fine if you use LLMs, but it's your responsibility to vet the code and make sure it's production quality. If we wanted to review LLM code directly we wouldn't hire someone to copy-paste into ChatGPT, we'd just use the API."

Reply

[-]

Any_Masterpiece9385@reddit

Reviewing code a waste of time?

Reply

[-]

dogo_fren@reddit

Crap shat out by AI without any second thought? Yes, downvote me as you want, it’s a waste of time.

Reply

[-]

Any_Masterpiece9385@reddit

Saying "this is crap shat out by AI without any second thought" would count as a review. Ignoring pull requests entirely however, is bad.

Reply

[-]

bjenning04@reddit

That’s what I was about to say. It is never a waste of time to have a couple extra eyes look over code to catch defects and architectural issues before it gets released to customers. AI created slop or not.

Reply

[-]

bjenning04@reddit

This is the answer. And work on mentoring/coaching. A Computer Science degree is a lot like a black belt in Karate, you know just enough to finally begin training for real. Back when I was entry level 20 years ago, I didn’t know what I didn’t know, and am grateful for the mentors I’ve had through the years, and the development process like writing tech designs and mandatory code reviews that give instant feedback on what I’m doing wrong and how to address it. That goes both ways btw, senior guys (myself included) still learn a new trick or two occasionally from the junior developers, so definitely worth investing in.

Reply

[-]

submain@reddit

Exactly. If slop is being pushed to prod you have a review issue.

Reply

[-]

PragmaticBoredom@reddit

In other words: Close the loop with basic feedback, expectation setting, and performance management. OP speaks of these people like he’s observing them like animals in a zoo or something. Get in there and be a manager.

Reply

[-]

DaRadioman@reddit

But that's so <whiny voice> haaaarrrrddd :-(

Reply

[-]

takemetomosque@reddit

Original content: \~\~We’re dealing with a problem at my company that’s annoying, but honestly, it's not that surprising. Out of \~70 devs, about 10% are juniors. Lately I asked a few of my mids/seniors to pair program with them to see where they’re at - and what we have noticed is that a lot of them, when they hit something hard or challenging, they instantly open ChatGPT (or similar) and start writing out the problem and copying the solution; without understanding the problem or how to solve it. Now I get that AI tools are part of the workflow these days, but the point of pair programming is to learn from the more experienced dev, ask questions, think through problems together - not to just offload the thinking to an LLM. These juniors are working on client projects, and the stuff they generate is often low-quality, barely-understood code that my more experienced devs then have to clean up, which makes them annoyed - circle keeps expanding. That wastes time, burns money, and adds no real value - I'm running a business, and I do expect value in some form being generated. So now I’m stuck. Is this a hiring problem? (Our process is: HR screen > technical test \[not live coding\] > culture fit stage > decision.) Should I put more structure into mentorship and training? Or should I just cut the ones who aren’t delivering and spend more money on experienced engineers (which I could easily afford)? Appreciate any real-world input from people who’ve been in a similar spot. What actually works here?\~\~ Edit: After a short meeting with directors, we decided to replace the 7 juniors that we have, with 5 mid/senior developers, and change company policy to strictly not hiring graduates anymore. I'll leave the post up but won't be replying anymore. Thanks all.

Reply

[-]

kutjelul@reddit

AI or not doesn’t really matter. Before ChatGPT some people just took the first S/O result and copy paste it If your juniors are not interested in knowing why given code works or doesn’t, I wouldn’t bother. If they are interested and just need some mentoring; good

Reply

[-]

Whisky-Toad@reddit

I’m a senior and I still copy and paste code I don’t understand sometimes Can’t be an expert at everything, do you really want juniors to spend 3 days learning 40 lines of code deeply

Reply

[-]

chaitanyathengdi@reddit

>do you really want juniors to spend 3 days learning 40 lines of code deeply If it takes the whole application down when it fails, yes.

Reply

[-]

Whisky-Toad@reddit

if code that can bring your whole application down makes it into prod it's not the juniors fault

Reply

[-]

lupercalpainting@reddit

> if code that can bring your whole application down makes it into prod So someone has to understand the code, no? Why are you, the author, not responsible for understanding the code?

Reply

[-]

Ritter-Sport@reddit

Yes you could see it that way. But honestly why are you paying a senior much more money than a junior? Because his responsibility is a lot more. So yes I would argue that as a senior if you supervise some junior developers you take a look at software that you delegate to a junior which could break the system. If you have a leading role in any field you take partial responsibility for the things people do that you supervise.

Reply

[-]

Molehole@reddit

Of fucking course it is the juniors fault if he copy pastes code he doesn't understand at all and causes the software to crash...

Reply

[-]

Ritter-Sport@reddit

I mean a juniors code should be reviewed right. First so this doesn't happen but also for the junior to get some feedback from a more experienced dev. So I would argue that in most environments a junior should not be able to push code that could crash the system to prod.

Reply

[-]

Molehole@reddit

> I mean a juniors code should be reviewed right. That doesn't excuse the junior for purposefully missing the most basic level of competence he is expected to have. Like if you are a junior nurse and do a calculating mistake and someone dies yeah sure it is the senior nurses fault. If you just pump the patient full of random drugs you found in the closet without even looking then yes it is your fucking fault. I also haven't been in a single job where there was enough time to actually thoroughly review anyone's code. How chill software development jobs do you guys have?

Reply

[-]

Ritter-Sport@reddit

I mean how blatantly wrong do we expect the code of these juniors are? I am a junior myself and make mistakes from time to time. Not all of my code is reviewed it's more like I can request a review if I want to. And I usually do when I feel the code I wrote could break something major. But also like somebody else here said there is more than one safety net. There is tests there is a dev stage and so on. So even if I merge something that's causing errors it's not directly in production. And my lead never rewrites my code he comments on things to fix and I fix them myself. And obviously I am using ai sometimes and so does my lead. So how bad is the environment op is describing what kind of juniors are these that they just copy paste code without understanding it at all. To me it sounds more like they are expected to produce quality code right out of university which is just dumb, cause you won't really learn how to work on a real project there. So if you pay for a junior dev expect the quality of a junior dev.

Reply

[-]

Molehole@reddit

Do you seriously not understand the difference between making a mistake in your code and copypasting random AI generated slobber without checking or are you just trolling?

Reply

[-]

DaRadioman@reddit

All the safety systems are important or else none can be allowed to fail. We don't rely on individuals to produce perfect code as we have other checks to catch it. We don't rely on tests to be fully covering because we expect sufficient other checks to catch the scenarios, but if these fail.at the same time then things get missed. It's fine for any one of the safety systems to fail, but they can't all at once. If you don't start with expectations of normally functional code the rest of the systems stop catching stuff when they fail and you get crappy code or to production. "The devs write great code. Except when they don't, but that's ok because we have peer reviews to catch any blindspots. Except when they miss them, but that's ok because we have tests. Except when they don't cover that scenario, but that's ok because we do validation runs and have slow roll outs with Canary/rollback. Except..." Each check assumes best efforts up to that point in order to be successful.

Reply

[-]

Krackor@reddit

If a junior is making changes with AI faster than they can be reviewed, the only two options are to let the code deploy without being reviewed, or to stop reviewing and merging their work. If you pick the latter you may as well fire them too.

Reply

[-]

Iway2000@reddit

> I’m a senior and I still copy and paste code I don’t understand sometimes I can guess your TC!

Reply

[-]

Whisky-Toad@reddit

Go on then, its higher than average for my YOE in the UK and I could push for a lead role if I wanted

Reply

[-]

ndav12@reddit

If it takes a junior 3 days to understand 40 lines of code that they claim to have written, I would consider that a problem yes.

Reply

[-]

NoConcentrate7845@reddit

I take it that was an exaggeration

Reply

[-]

XenonBG@reddit

Yes, because if something goes wrong in those 40 lines of code or the functionality needs to be changed, you can't fix it without understanding those lines. You'll be again at the mercy of an LLM or the SO.

Reply

[-]

GroundbreakingOil434@reddit

You are not a senior, sorry. Seniors take direct responsibility for every line they write. If you don't understand it - you don't commit it until you do. "Senior" does not equate to "more than x years in the industry".

Reply

[-]

tetryds@reddit

Yes, absolutely, because they are juniors.

Reply

[-]

lexybot@reddit

That is weird.

Reply

[-]

thekwoka@reddit

> I’m a senior and I still copy and paste code I don’t understand sometimes This is only acceptable for ffmpeg commands. Otherwise you might not be a senior.

Reply

[-]

Andrew64467@reddit

Really? How often do you do that? What kind of code.

Reply

[-]

FlipperBumperKickout@reddit

As long as you link to where you got the code from, and have the code isolated and tested throughly with unit tests to ensure it actually does what you think it does... then sure. In all other cases I will personally pull you over during the pull review, and you get to sit there to figure out with me what your code does during the whole process even if it ends up taking 3 months.

Reply

[-]

NotYourMom132@reddit

not really you still need to read, understand, and cherry pick the answers, sometimes modify the code. ChatGPT is a whole another level of laziness.

Reply

[-]

magpie882@reddit

The effort to figure out the correct search terms and then Frankenstein together the partially functional/relevant comments was a pretty decent exercise in learning how to frame the issue properly and how to evaluate other people's code.

Reply

[-]

chaitanyathengdi@reddit

Hey now, at least call it "efficiency"!

Reply

[-]

ttkciar@reddit

I'm guessing you've asked them to not do that, and they persist in doing so regardless? Basic question, I know, but it needs asking.

Reply

[-]

PragmaticBoredom@reddit

It’s amazing how “What have you tried already to improve the situation?” is the most revealing question for so many Reddit advice posts. The way OP is dodging that question at every turn means the answer is “Nothing”. This feels like someone inexperienced who landed in a high ranking position at a fast growing company but never learned how to do basic performance management.

Reply

[-]

axyliah@reddit

Rich family moment

Reply

[-]

signedupjusttodothis@reddit

\> OP was asking basic Excel questions 3 years ago And says they’ve got 8+ YOE in their flair. Whew lad.

Reply

[-]

Middle_Ask_5716@reddit

Hahahahahahahha thanks for doing this research. “How to remove duplicates in excel” To God damnit juniors these days suck

Reply

[-]

TheAnxiousDeveloper@reddit

Add to that that their "solution" was to cut the juniors, get mid/senior levels and NEVER hire graduates anymore. As if the problem wasn't the fact they hired junior expecting to no be any type of real mentorship. Yes, having people that just copy paste code is annoying af, but that is why there is a screening before, a trial period and training. But by seeing the answers here, I'm more convinced of the fact they just wanted something/one to blame rather than looking for an effective solution to the mentorship problem.

Reply

[-]

Hziak@reddit

I knew it was fiction when he said they’d replace juniors with seniors… I wish my company could just casually decide that we could add 5 seniors for literally any reason at all. Even when we fire a senior, we replace them with a junior because “talent is too expensive” as though we weren’t already paying for a senior. Only in la-la land could 7 juniors be replaced by 5 seniors. That’s like a roughly 50% increase in payroll using approximate salaries, lol.

Reply

[-]

TheAnxiousDeveloper@reddit

Or it's possible they really fired those 7 juniors and now they are waiting for the seniors to be hired. And they are going to wait a looooong time if they expect they are going to agree to get scammed to join at Little more than the salary of a junior (assuming they paid the junior fairly in the first place). Most likely they will complain for months that they can't find anyone to fill the positions

Reply

[-]

Leopatto@reddit (OP)

We have noticed considerably that what was generated for our client was AI slop - including comment(s) as well, lol. This was part of a broader measure to actually test these guys out, and frankly, I am disappointed.

Reply

[-]

TheAnxiousDeveloper@reddit

Disappointed in the way you select employees and foster their growth? Have you communicated clearly with them what should be done and what shouldn't? Did you lead by example? I find it's too easy to place the blame on them. What could have YOU done to improve their performance? As a manager that is your responsibility too

Reply

[-]

dendrocalamidicus@reddit

Doesn't answer the question

Reply

[-]

elementmg@reddit

Typical CEO, eh?

Reply

[-]

Leopatto@reddit (OP)

Money's good though.

Reply

[-]

elementmg@reddit

If you hallucinate as much as current AI, should probably just replace you.

Reply

[-]

SchonoKe@reddit

Rots your brain it would seem

Reply

[-]

TonyNickels@reddit

CEO (8yoe)

Reply

[-]

_hypnoCode@reddit

aka Daddy gave me enough money to start a company

Reply

[-]

PragmaticBoredom@reddit

OP’s post sounded suspicious for several reasons. I skimmed their post history. 3 years ago they were asking basic questions in /r/excel : https://www.reddit.com/r/excel/s/cl4d9GlRzy So I think this is a typical Reddit LARP CEO.

Reply

[-]

Leopatto@reddit (OP)

You can't really stop the moving train, though, can you? Sure, we could block off the websites and track what they access, but what's the point? For example, they could use their private mobile phone to answer their issue.

Reply

[-]

uppers36@reddit

Blocking AI websites is absolutely wild and you should feel bad

Reply

[-]

GrapefruitMammoth626@reddit

If they using mobile phone they can copy paste easily, they may actually have to finally read what it says instead of copy paste.

Reply

[-]

g0fry@reddit

Just send an email with the LLM output to a work email 🤷‍♂️ Annoying, but not that difficult.

Reply

[-]

GrapefruitMammoth626@reddit

Significantly slows down their work. They’d be pretty annoyed at having to start doing that.

Reply

[-]

g0fry@reddit

Definitelly. But it would not be slower than trying to understand what the LLM produced.

Reply

[-]

chaitanyathengdi@reddit

My company will flag that.

Reply

[-]

g0fry@reddit

How? Also, output of the LLM can be saved as online page/text and accessed simply by browsing there. Again, inconvenient but still better than having to understand to code. You could whitelist domains on the company router, but if you have to do that, there are bigger problems in that company 😅

Reply

[-]

chaitanyathengdi@reddit

They scan emails for source code.

Reply

[-]

g0fry@reddit

They can zip it. Or paste it into word/excel and pretend it’s a document. Or simply encode it in base64. Hell, I’m pretty sure there is a tool that will encode source code into a shakespeare’s play 😅 There are many ways how to circumvent any email scanner. Just asking ChatGPT itself must no doubt yield many useful results 😇

Reply

[-]

silence-calm@reddit

That was a yes/no question, will you answer it?

Reply

[-]

broccollinear@reddit

Hire this man to fucking Congress he deserves to be in the White House

Reply

[-]

GroundbreakingOil434@reddit

Fact. Dodging a direct question for 5 minutes is a rare skill. This man def congresses.

Reply

[-]

Additional-Bee1379@reddit

Not answering the question just means "no".

Reply

[-]

chaitanyathengdi@reddit

Not answering the question just answers it for you.

Reply

[-]

chaitanyathengdi@reddit

"We haven't asked 'cause why should we, and now I'm embarrassed to publicly admit we're removed from the people we employ."

Reply

[-]

dllimport@reddit

So is that a "no we have not told them to stop doing this?"

Reply

[-]

RegrettableBiscuit@reddit

"I've tried nothing and I'm all out of ideas."

Reply

[-]

chaitanyathengdi@reddit

love this one

Reply

[-]

MasterLJ@reddit

"Hey human beings, I'm noticing a pattern in your commits. I am excited that you are exploring LLMs and all of the amazing things they do. I still need you to please be accountable for the quality of your code and its consistency with the surrounding codebase. {insert\_specific\_instance\_that\_harmed\_the\_company} I'm happy to set up office hours if you don't understand what I mean, or you want to see how I make things coherent, sometimes even using LLMs myself. Please make this a priority, I'm available whenever you need". Then keep holding them accountable. "I didn't see you reach out yesterday, my expectation is that you please set aside a time so we can discuss how your work affects the team". Blah blah blah, until they improve or they fire themselves. But you have to have the courage to give them a chance. I can't promise people turn it around, but most human beings respond to empathy and a helping hand. You can still hold them accountable but you must first have provided a way out for them.

Reply

[-]

chaitanyathengdi@reddit

OP is too busy making €9 mil to do this.

Reply

[-]

West-Code4642@reddit

the solution isn't to ask them to not use AI. the solution is to ask them to deeply understand the code. AI in its current form is way too unreliable for many tasks obv.

Reply

[-]

chaitanyathengdi@reddit

People with your mindset are the ones who install time tracking software on company laptops.

Reply

[-]

Leopatto@reddit (OP)

I'd never do that. It hasn't even crossed my mind. Hell, my guys can watch porn on their laptops if they want to i don't give a fuck lol.

Reply

[-]

No-Intention554@reddit

>i don't give a fuck lol. Now that part, i believe.

Reply

[-]

grimonce@reddit

That still makes it hard for them to use it. They have to go through the effort of rewriting it from a small screen or pasting it through some unblocked channel like mail or private git repo.

Reply

[-]

benjhg13@reddit

No way this guy CEO

Reply

[-]

Evinceo@reddit

They are your employees. You're allowed to tell them what to do. You don't have to be their parents and install website blockers.

Reply

[-]

AccountExciting961@reddit

You still aren't answering the question. Are they ignoring your explicit request or not?

Reply

[-]

UL_Paper@reddit

lol still not really answering the question

Reply

[-]

cicamicacica@reddit

You really dont get the point. Your issue is not ai usage. Your issue is that they are miss-using it. They should not commit anything they dont 100% understand. Easy to measure. If anyone - regardless of seniority - cant keep this after warnings, let them go.

Reply

[-]

dendrocalamidicus@reddit

What the hell? How about respecting them and talking to them? Jesus Christ

Reply

[-]

goldiebear99@reddit

the answer is no, he knows that asking people not to use AI in 2025 makes you look like a luddite especially for someone who’s a data scientist type

Reply

[-]

dendrocalamidicus@reddit

Using AI is different from pushing vibe code slop to code review tho. He doesn't have to ask them not to use AI, nor should he. The important things are taking responsibility for the code they push, understanding it, and that code being of a high quality. Whether AI is involved in that is besides the point.

Reply

[-]

lupercalpainting@reddit

I don’t care if you use AI. I care if it’s bad. And if I can tell just by looking at your code that it’s AI then it’s _bad_.

Reply

[-]

Lucenia12@reddit

This is a leadership failure through and through. You have the power to encourage better practices and individual growth (as all of our jobs are as experienced devs) and instead your first instinct is to get rid of them.

Reply

[-]

chaitanyathengdi@reddit

OP doesn't have the maturity and vision to do the right thing, though I am seeing that a lot of people in the comment section do and are even much MUCH more experienced than him. Well, you know what they say: it's your funeral 🤷‍♀️

Reply

[-]

iamakorndawg@reddit

This comment makes it clear that your goal has always been to fire the juniors. You clearly haven't even taken the time to explain your expectations of them.

Reply

[-]

chaitanyathengdi@reddit

They are lucky to be leaving this place. Blessing in disguise I'd say.

Reply

[-]

ttkciar@reddit

Okay, but have you asked them to not do that?

Reply

[-]

g1rlchild@reddit

You can't just go around communicating with your staff. The best way to run an organization is to fire people without ever letting them know they're doing anything wrong.

Reply

[-]

kbielefe@reddit

Juniors have been disappointing since the beginning of time.

Reply

[-]

ZeroLegionOfficial@reddit

What a lame CEO, who would work for that ? One frank question, you doing some of your work AI gen too ? Should they replace you too ? Don't lie, we on the internet :)

Reply

[-]

VisibleExplanation@reddit

Garbage in, garbage out.

Reply

[-]

chaitanyathengdi@reddit

This is actually what is called the CEO algorithm: ignore what the other person is saying (or better, handpick some choice keywords from their input), then deliver something that the shareholders and legal department will not object to. Relevance to the subject matter not mandatory.

Reply

[-]

blahajlife@reddit

Does your process have pull request reviews?

Reply

[-]

BElf1990@reddit

This comment was AI generated for sure. Because it's a bunch of lines that don't do what they are supposed to do.

Reply

[-]

humanCentipede69_420@reddit

Something tells me OP doesn’t even know what a PR is…

Reply

[-]

ExperiencedDevs-ModTeam@reddit

Rule 1: Do not participate unless experienced If you have less than 3 years of experience as a developer, do not make a post, nor participate in comments threads except for the weekly “Ask Experienced Devs” auto-thread.

Reply

[-]

McN697@reddit

I used to think the skill of writing code on a whiteboard was silly. Now, I can’t hire a junior engineer without it.

Reply

[-]

zaibuf@reddit

Its so easy to choke under pressure compared to when you actually work. Like Google and AI is part of your tools and you use them daily to help you solve problems. Whiteboarding is like asking a carpenter to build a table but you remove their toolbox.

Reply

[-]

TeeeeeFarmer@reddit

Nope, if you do something regularly - its not easy to choke under pressure unless you are judging people competitively. You ask whiteboard or anything to understand their thought process not offload that thing to chatgpt.

Reply

[-]

deer_hobbies@reddit

Please recognize that not everyone is you. Interview situations are pretty awful for many - I regularly choke on stuff in interviews that I’ve done a hundred times, even recently. I have to take a beta blocker just to get thru an interview hour, and it can drain me for hours after. Being asked to perform what is often an exploratory and creative job, on a clock, with little context, with a total random person determining your value or not value is something that many people find difficult inherently.

Reply

[-]

Krackor@reddit

You are a worse candidate than people who are competent enough to perform well in interviews. Being different doesn't guarantee you are just as valuable.

Reply

[-]

Sporkmancer@reddit

I didn't think software devs generally rated peoples competency as software devs based on how well they interview. I interview very well myself, but some of the devs I've looked up to over the years (and still do) are bad at some styles of interviews because of social anxiety. There are frankly amazing people that don't do well if you suddenly spring a leetcode hard or sudden whiteboard problem with limited context on them, which isn't surprising when that isn't at all how they actually work. You're doing the whole interview process a disservice by pretending that part of developing better interviews ISN'T to figure out how to filter for people that are good at software devs rather than to filter for people that are good at interviews. A big problem with leetcode for example is that you're filtering for people who study leetcode if you use leetcode hards or expect a perfect solution for even a medium that covers all edge cases in unreasonable time contraints. I say this as a person who finds programming challenges fun (including hard leetcode problems). As a full-stack dev for over a decade, I have more YoE than I have times I've needed an algorithim of the robustness needed for a leetcode hard. It's wild to me that as software developers who have SEEN how useless the interview processes most companys have in place are, there are still people who would say interviewees are definitively the problem.

Reply

[-]

Krackor@reddit

Regardless of how good or bad the interview process is, an engineer who can engage in a conversation with a stakeholder and negotiate requirements in an uncertain situation is far more valuable than an engineer who is only good at coding and has a panic attack when they need to perform in a social situation. Let's stop pretending like social and emotional fragility isn't a liability.

Reply

[-]

TeeeeeFarmer@reddit

I just checked your profile out of curiosity - dude, you've a 4 year career gap, that will obviously impact your interview performance. Don't compare yourself with people already working in industry and prepping at same time for interviews. Don't argue for the sake of arguing & yeah anyone will choke on interviews after 4 year career gap.

Reply

[-]

deer_hobbies@reddit

I was choking before too. Anxiety exists! I’ve just got a ton of trauma around it. I actually handled it the best I ever have recently and got 2 offers but it’s almost always an awful experience that I needed to do major mental health work to overcome

Reply

[-]

TeeeeeFarmer@reddit

Please recognise everyone goes through this shit. I have had my interviews of complete panic that my brain froze & panicked, I took cold shower to reduce stress and got my blood cortisol levels checked. I overcame my fear of interviews by "letting go" of final outcome even though I couldn't afford that risk. I switched twice in this market (an year ago and quite recently) for similar pay. In my previous workplaces, I've conducted interviews to reduce as much stress as possible for candidates & get them into flow state - some of them did pretty well & some failed in onsite. Interviews aren't meant for everyone, it takes time & effort to get good at anything in life. Sadly, in this market - everyone is looking for perfection in every round - 1 screening / 2 coding / 2 system design / 2 behavioural rounds. I practised multiple adhoc / random system design problems with my friend + gave as many "screw up" interviews at places that I don't want to work. It took me 6+ rounds to figure out my system design / behavioural round "way of doing" things. Get your anxiety or panic or stress stuff resolved - you can talk with a friend or partner or someone first. Why do you choke on interviews ? Ultimately people on other side are humans as well - if you clarify expectations beforehand in first 5 minutes, you should know if you can pass / fail interview in those minutes itself. That's my metric man or else I just chill out.

Reply

[-]

zaibuf@reddit

>if you do something regularly - its not easy to choke under pressure unless you are judging people competitively Guess I've been influenced by all the leet code talks. Where peoply actually practise algoritm questions specifically for whiteboards. I've yet to had s single whiteboard interview. I've had some take home tests, I find those more suitable. I get to bring back the code and walk through my thought process, not forced to solve it without assistance.

Reply

[-]

TeeeeeFarmer@reddit

I had given leetcode style (medium to hard problems), feature development (api or json parsing) and multi-threaded problems. I had more success rate in leetcode & multi threaded problems. Most of feature development problems asked in interviews felt like tutorial based ones - I can whip them out any point in time without effort. Those feature development problems were boring ( our work is generally complex that it can't be solved in a hour) & simple that it demanded more of syntax / coming over language barrier across folks from different countries. Man, if you aren't able to code simple for loops with recursive functions - that's on you. If you spend 30mins a day for a week, you should be able to solve majority of interview problems. If you aim for faang then lc hard is bound to be there due to competition.

Reply

[-]

zaibuf@reddit

>Man, if you aren't able to code simple for loops with recursive functions - that's on you. If you spend 30mins a day for a week, you should be able to solve majority of interview problems. Its not a matter of being able to do it. Its a matter of doing it while under pressure by the potential employee. You dont often work on a new feature while someone else is constantly staring at your screen and asking what you're doing.

Reply

[-]

bjenning04@reddit

Spoiler alert: that’s part of the point, seeing if you can think critically under pressure, and how you react to that. If you do just ok but don’t crack, you’re still in the running. If you do excellent, but fly off the handle, that’s probably not a good culture fit.

Reply

[-]

thekwoka@reddit

> Its not a matter of being able to do it. Its a matter of doing it while under pressure by the potential employee Well, figure it out.

Reply

[-]

TeeeeeFarmer@reddit

See, pressure is relative and there are people who can do both lc problems or multi threaded stuff or crud development with / without pressure. Yes, majority of web apps devs don't get paid good money either if it's easy problem, competition will always exist if there is good money. I worked in crud development for an year of 6 years in my career & I hated it. It was just converting domain specific business logic into code. It felt like learning business & not at all engineering. Then remaining 5 years - were spent in building games (some randomisation or threads or scheduling etc), distributed system internals, migrations (hated this but fine), etc. I spent last 4 years in faang , then another faang, then another startup now - that competes with faangy things, etc. So, yeah it's relevant to me. As of now, only uber or google or salesforce can pay that much - so I don't have a choice than to grind lc whenever needed.

Reply

[-]

TeeeeeFarmer@reddit

Btw carpenter toolbox doesn't go around screaming random stuff & doesn't hallucinate .... that would be hilarious ... similar to "whats my purpose" from rick & morty.

Reply

[-]

bjenning04@reddit

“You pass butter.” 😂

Reply

[-]

GlitteringAttitude60@reddit

in a whiteboarding situation it is the responsibility of the interviewers to create a situation in which "choking under pressure" does not come up, and this is a skill that I as an applicant am interviewing a new company for, quite frankly. So, don't put your juniors in front of a whiteboard and look at them in a "swim or sink" tone of voice. Create an atmosphere of collaboration in which it is okay not to know things, and where the junior will be assisted in arriving at the correct solution, and where the entire "team" (interviewers and interviewee) will find a solution together.

Reply

[-]

Wattsit@reddit

Whiteboarding is like asking a carpenter to draw a design, and I guarantee any carpenter worth their salt does that regularly. Software engineers should be able to whiteboard a design in pseudocode at a minimum.

Reply

[-]

bjenning04@reddit

I’m the same. All of the interviews I’ve done for years now have been virtual, but concept is the same. I have them pull up their IDE of choice and write code. And I don’t even care if they write only pseudocode, I just want to see if they can critically think through the problem and write “code” to solve it.

Reply

[-]

CmdrSausageSucker@reddit

Writing pseudo code on a piece of paper or on a white board (with the first being the preferred option IMO), and letting the candidate explain the whys and hows afterwards should give a good measure of ability and potential, actually.

Reply

[-]

Leopatto@reddit (OP)

Maybe that's not such a bad idea. Problem is, is that my company offers 100% remote within EU. There isn't really any sort of office.

Reply

[-]

Cobayo@reddit

There are plenty of "workshops" cafes or such that offer a job environment rented by the hour. It's comfy and fairly cheap.

Reply

[-]

chaitanyathengdi@reddit

Coworking spaces, we call them.

Reply

[-]

Cobayo@reddit

Right, sorry I couldn't recall the name D:

Reply

[-]

rithem1@reddit

Makes sense, since there's no whiteboarding tools out there.

Reply

[-]

thrynab@reddit

How the hell is a guy CEO that can’t think a single step further than what he’s spoon fed by other?

Reply

[-]

Leopatto@reddit (OP)

Because it's not my job to hire anymore. I delegate that to others, how hard is that to understand?

Reply

[-]

thrynab@reddit

If you defend saying „We can’t do whiteboarding tests because we have no physical whiteboards“ by saying you delegate hiring, then it sounds like you’ve probably also delegated thinking to someone else. I just wonder, who actually runs your company?

Reply

[-]

chaitanyathengdi@reddit

ChatGPT, aka his "directors"

Reply

[-]

Cube00@reddit

The clients and juniors apparently run based on the other comments. Rather then pushing back on either clients or juniors they choose to squeeze their seniors to bridge the gap.

Reply

[-]

nimshwe@reddit

Spoiler: AI does the thinking instead

Reply

[-]

Ready_Anything4661@reddit

Gonna need you to take responsibility for your own company, bro

Reply

[-]

Schillelagh@reddit

Precisely. You still need to manage the people you delegate responsibilities.

Reply

[-]

LengthPersonal6302@reddit

Would be easy as the CEO to give out the requirements when delegating tasks.

Reply

[-]

Repulsive_Zombie5129@reddit

Typical CEO

Reply

[-]

RevolutionaryGain823@reddit

The problem is AI cheating solutions are extremely rapidly becoming more and more advanced. Modern hiring now requires almost as much effort for AI detection as for evaluating technical ability, culture fit etc. Not to mention the time-wasting of complete slop candidates (who are very obviously just putting the question your ask into ChatGPT then regurgitating the answer). The result is companies will go back to in-person whiteboard interviews which is a giant pain in the ass for remote companies

Reply

[-]

ClearGoal2468@reddit

yep and the eu doesn’t have the best developed internal transport networks of any major economy

Reply

[-]

Spider_pig448@reddit

I've been an engineer for over a decade and I would walk out of an interview that requires writing code on a whiteboard. Unless you ship your code to clients via a whiteboard, you are testing useless skills. It's pretentious and a red flag.

Reply

[-]

valkon_gr@reddit

And we are back to leetcode. There is a reason it's industry standard.

Reply

[-]

chaitanyathengdi@reddit

Can't use Copilot there, can they?

Reply

[-]

dutchman76@reddit

I'm going to make that part of my interview process

Reply

[-]

allKindsOfDevStuff@reddit

My team has seniors that generate AI slop

Reply

[-]

CompetitiveSubset@reddit

YOE is not a real measure of people’s abilities. People could be employed for many years but know shit.

Reply

[-]

t-hrowaway123@reddit

I see that a decision has already been made, but still think my answer is relevant for others who may consider they have the same challenge to overcome. I think the most productive route for everybody, is to teach them how to use AI properly & integrate into their workflows without blatantly copying & pasting. I am a senior data platform architect, and I use AI every single day. I never just copy & paste the results, I typically use it for either (1) figuring out how to make something more efficient (less lines of code for readability, computationally more efficient, etc.) or (2) how to solve a technical problem that would take me much longer to figure out (regex matching patterns, complex SQL query building problems, IaC questions, etc.). A huge nuance here is that I never copy anything into the prompt search either. I paraphrase my problem or question, or turn my code into a question, and let AI do some thinking to help me arrive at a question faster. Without having copied code directly in, this forces me to translate the AI output back to my own code and business requirements. AI is here and everywhere, and it is objectively is more efficient than even you at some tasks. So as a senior / lead / manager, it is your job to guide your juniors how to learn & do their job better, accounting for evolution of technology that can be helpful. Cutting off AI altogether is contradictory to that mission given valuable it can actually be when used correctly. Before StackExchange, i'm sure there were plenty of senior devs who thought that searching for answers there was bad practice, but regardless this became a globally-used tool for technical problem solving. Some people copied code directly from blog-answers (bad), others used it as reference for improving their solution or figuring out how to solve problems (good) - AI is a new evolution of this process. So I would suggest looking at your own leadership style & thinking about how you can become more adaptable to evolving technology & amend your training process to walk juniors through how to get the most out of AI without generating slop (or unnecessarily over-complex code), rather than just strictly cutting out a super helpful tool and firing junior developers or eliminating all job opportunities for them. We all start somewhere, keep that in mind.

Reply

[-]

Gyrochronatom@reddit

You shouldn’t give juniors hard problems. But yes, AI slop and laziness is the new fashion on all levels.

Reply

[-]

throwaway_0x90@reddit

Super subjective. Is the slop so bad that it's slowing seniors down because they have to keep correcting horrendously bad code? I'm leaning towards a more upstream issue, maybe during interviews it needs to be made clear that: - _"While the future is inescapably A.I., leaning too hard on it and trying to send purely/mostly A.I. generated without understanding the core issue you're trying to solve and consuming senior review time repeatedly will reflect negativity on performance reviews. Ultimately this could lead to certain HR decisions."_

Reply

[-]

CompetitiveSubset@reddit

Tell the juniors they are not allowed to use AI anymore until X months have passed and a senior dev, who mentored them and will personally sign off that they are able to use their brain to produce code that has more positive value than negative. “Effective immediately” those who push back.

Reply

[-]

chicknfly@reddit

Shameful plug: I’m a mid-level full stack who loathes AI. If you need someone to fill the void, I’m available! (Seriously, the market sucks and I’m desperate 🤣😭)

Reply

[-]

sarnobat@reddit

Same for me

Reply

[-]

chicknfly@reddit

I got my Canadian Permanent Residence just as all of the big names in the industry started their mass layoffs in 2022. I couldn’t find a job at all, especially in my rural neck of the woods. I scored my last software job after posting onto a local facebook group that I’m looking for work in any field, white or blue collar, and am willing to learn whatever it takes. A guy who co-owns a company in Vancouver had just moved to the remote location, saw the post, and took pity on me :P

Reply

[-]

MrLowbob@reddit

I have tried working with AI a lot lately, a serious tryout and with some actual framework around (like templates with some kind of rules that always get pretended to queries n stuff) they are actually pretty decent. That said, its obviously extremely important that the people generating stuff also understand it. For the period where we were working with it extensively, every review was with an actual interview requiring the dev to explain the solution to someone else. After some time and when we noticed that no one struggled to do so over a test period, we stopped the interviews and as they took time too obviously. But when a new member would join, we'd do such a trial period with them. For a junior, I'd do the exact same: make them explain their shit in their own words to you face to face in every review and only after a certain period of _no_ issues to do so allow them to continue with less supervision (reviews are still always mandatory to ensure code quality though)

Reply

[-]

shadow_x99@reddit

The seniors reviewing their PRs should give no mercy.

Reply

[-]

vom-IT-coffin@reddit

This isn't going anywhere, need to learn how to integrate it appropriately.

Reply

[-]

herothree@reddit

If you had engineers that made low-quality, barely understood code without AI, would you keep them around?

Reply

[-]

angrathias@reddit

To be fair, this was the case with many / most juniors without AI - now they just do it quicker.

Reply

[-]

Intelligent_Water_79@reddit

Ahh but there's a difference. Usually the junior understood their own sloppy code even if nobody else did

Reply

[-]

mizdev1916@reddit

As a junior I often did not fully understand the sloppy code I copy / pasted then tweaked

Reply

[-]

RegrettableBiscuit@reddit

Yeah, as a junior, I did not know what the right solution was, but I did know how my wrong solution worked, and when somebody showed me the correct solution, I'd get why my solution was wrong because I knew how it worked.

Reply

[-]

CardboardJ@reddit

I'm I'm only a senior because I've done it the wrong way more times than most people have tried.

Reply

[-]

avoral@reddit

Amen

Reply

[-]

remotewebdeveloper@reddit

There are dozens of us!

Reply

[-]

TheOnceAndFutureDoug@reddit

As a lead... Bow before my ability to fuck it up and learn from it! Muwahahaha!

Reply

[-]

becuzz04@reddit

You must be luckier than me. I've seen plenty of juniors submit code for PRs that was a straight copy paste from Stack Overflow or some blog article. When you'd ask them anything about the code they'd have no clue.

Reply

[-]

misterguyyy@reddit

Even then it's one distinct function that you can discuss, as opposed to a big plate'o spaghetti cooked up by an LLM.

Reply

[-]

battarro@reddit

Did it work? Nothing wrong with a straight copy paste from stackoverflow

Reply

[-]

becuzz04@reddit

It compiled, ran and sorta did what it was supposed to. It also left security holes big enough you could drive a school bus through them.

Reply

[-]

battarro@reddit

Meehh. The security problems are always an after thought. That is normal. Copy pasting or redoing things from stack overflow was how i have programmed before the copilot age. Nothing wrong with that ro be honest. Plenty of times i even included on the comment where i got the fix from, meaning the exact url of the question.

Reply

[-]

prescod@reddit

Did they though? Or did they just tweak it until it seemed to work and then call it finished? That’s what I did at first.

Reply

[-]

SnooKiwis857@reddit

Speak for yourself I definitely did not as a jr

Reply

[-]

SadTomorrow555@reddit

lmao. That's so accurate. The insanity that they came up with was half the learning process. And hey I've been there.

Reply

[-]

misterguyyy@reddit

Yeah, but then you can walk through the individual lines, ask them what their reasoning was behind that, and walk them through more elegant/solid logic or best practices. It's a little extra effort that pays giant dividends. Here it's like "IDK ChatGPT wrote it"

Reply

[-]

SideburnsOfDoom@reddit

Yes, but it was a learning experience. Which cutting ansd pasting from ChatGPT is not. Like, the point of writing that essay or solving that calculus math problem isn't to find the answer to a mystery. It's for a person to get experience at doing it.

Reply

[-]

RedditIsBadButActive@reddit

This is the main difference - the expectation for juniors is that they make crap, but they show signs of improving/learning, so they become useful in other ways later. I don't think this has changed. If AI is leading to juniors that don't grow, then you may as well put a senior with AI on it, then cut the junior. I think we should be encouraging juniors to show us they're capable of meeting expectations AI or not - and to be handling bigger and bigger things without messing up. Right now, AI doesn't seem to be able to handle the second bit so my advice for juniors would be to lean less or outright stop using AI for their own sake if it means they can't meet these outcomes. But, if they're succeeding in these outcomes then absolutely keep using it.

Reply

[-]

chaitanyathengdi@reddit

>my advice for juniors would be to lean less or outright stop using AI for their own sake if it means they can't meet these outcomes The strictest outcome at times is meeting deadlines. Juniors don't have time to learn, and eventually they also lose the inclination.

Reply

[-]

RedditIsBadButActive@reddit

Ideally, as seniors we'd be mentoring them through this instead of demanding delivery. But this is the state of the industry now, I suppose.

Reply

[-]

chaitanyathengdi@reddit

>put a senior with AI on it, then cut the junior. That's a great way to screw yourself over in 5 years, when the seniors have left and there is no one to train the replacements. Basically the seven monkeys experiment.

Reply

[-]

Shingle-Denatured@reddit

I thinkt that's the issue here: the expectation from the manager is that pair programming is to teach the juniors. The junior's expectation is to show what they're made of. The right setting isn't created by the people doing the mentoring, which says a lot about the culture that's been created as a whole.

Reply

[-]

JollyJoker3@reddit

Teaching **should** be the reasonable expectation from everyone involved but >Lately I asked a few of my mids/seniors t**o pair program with them to see where they’re at** \- and what we have noticed is that a lot of them, when they hit something hard or challenging, they instantly open ChatGPT (or similar) and start writing out the problem and copying the solution; without understanding the problem or how to solve it. I don't understand what the senior is doing here; just sitting there taking notes and going "uh huh"? They should be teaching the juniors and working out how a beginner can use an LLM to learn and to verify their work in that specific workplace. I'd say the senioirs are the ones failing hard here.

Reply

[-]

oskaremil@reddit

Agree. Did anyone think of asking "can you explain the code you just pasted there?"?

Reply

[-]

Simke11@reddit

Before ChatGPT became a thing, plenty were just doing copy/paste from stack overflow. ChatGPT is not the problem here. Lack of willingness to understand the problem and work towards the solution is.

Reply

[-]

Krackor@reddit

Any problem that requires more than just a few lines of code won't be solved with straight copy paste from stack overflow. That means a junior will have to do some adaptation work to fit what they find into the context of their current problem. With chatgtp they get the appearance of a solution that fits their exact problem, which removes any obvious need to think about what the tool has given them.

Reply

[-]

Simke11@reddit

The point is there were lazy / bad devs before ChatGPT came along, the fact that they had to do a bit more leg work didn't make them good. I've seen plenty of slop when doing PR reviews before AI spitting out code was a thing.

Reply

[-]

SideburnsOfDoom@reddit

I loved StackOverflow, both for "quick fix to this error" and for "Deep dive into how this works" essays. I even contibuted a few of both. To be sure SO can be used for insight or to skate on. I don't think it's directly equivalent to ChatGPT though. Even if ChatGPT is "more of the same", an order of magnitude more of the same is a step change.

Reply

[-]

Simke11@reddit

I agree that ChatGPT makes it even easier, at least with SO you had to know what to search for and filter out things that don't address your problem to start with. But my point is that lazy devs who don't want to put in an effort to understand problem / solution always existed.

Reply

[-]

Normal_Fishing9824@reddit

Tem years ago it was copying and pasting from stack overflow without understanding now it's LLM it's not a new problem.

Reply

[-]

tetryds@reddit

That's a problem tho, because now they add significantly more burden to others while learning less

Reply

[-]

MonochromeDinosaur@reddit

But they don’t improve because they offload the learning opportunities to ChatGPT.

Reply

[-]

Comprehensive-Pea812@reddit

had a coworker who even asked what is nullpointerexception when I was still junior... I honestly blame college for not preparing workforce enough

Reply

[-]

boredjavaprogrammer@reddit

True. But with teaching and learnings these juniors start to know what not to do. Also they understoon what they’re getting at. Asking chatgpt for answer and blindly copying them is like going to stack oveflow and copying the answer. Just that now the answered given by chatgpt tailored to the problem.

Reply

[-]

thekwoka@reddit

Which makes it more of a problem, especially since they aren't putting in the effort to eventually get better.

Reply

[-]

nagai@reddit

Yeah but when they just paste your review comments into another prompt they don't learn, they are effectively just a useless level of indirection between you and an LLM.

Reply

[-]

herothree@reddit

That's true, I could have written a more nuanced comment. They will need some guidance, but they also should show improvement (not make the same mistakes over and over again, ask for help when they get stuck, that sort of thing). There might not be enough info in the original post to answer that for this particular situation

Reply

[-]

OK_x86@reddit

I'm a bit baffled. Them writing awful code is one thing but how is awful code getting through the review process?

Reply

[-]

xXxdethl0rdxXx@reddit

Bingo. IMO, this is an already solved problem. Good code review filters out StackOverflow already.

Reply

[-]

TheAnxiousDeveloper@reddit

To be honest, if I look at my code from 5 years ago I ask who is the brain-dead idiot that wrote that shit. We all grow. We need to have the chance, the mentorship and clear feedback in order to improve - something that OP clearly didn't bother to provide in an effective way

Reply

[-]

herothree@reddit

Honestly, I suspect you're being pretty hard on yourself? I don't doubt that you've learned a lot, and maybe you've had to make some terrible hacks to meet a deadline (I know I have haha), but I suspect (even years ago) one could tell that you had an understanding of programming and the domain based on your code. If you were truely writing terrible code and the company kept you around until you became a strong developer, you were more fortunate than many

Reply

[-]

pizza_delivery_@reddit

That’s a different story. They could be working on improving. Not the case when they just dump everything on AI.

Reply

[-]

herothree@reddit

Well, sure, if you see someone improving, that's great, whether or not they're using AI to improve. If they're consistently writing terrible code, that's bad, whether or not they're using AI

Reply

[-]

maigpy@reddit

low quality / barely understood.. doesn't fully capture what AI slop is. it might even be high quality, but not the right thing to do. unnecessarily high-quality. and zero understanding of it.

Reply

[-]

prescod@reddit

If it’s not the right thing to do in the context then it’s not high quality in the context.

Reply

[-]

maigpy@reddit

yes we can agree on "high quality in the context". Some of the stuff I've seen from AI does pass as high-quality from a very initial perspective, without having placed it in the current context. Among the things that get produced there is definitively also some "high quality in the context" stuff - that's what makes it even more insidious (I'm not sure what percentage is that, you will hear all kind of numbers for that) Finally, the other things that I don't see mentioned enough in the post is QUANTITY. The difference with the old "copy paste bad developers" is that this stuff can now be generated at faster than it can be reviewed... it becomes exhausting. One thing is to review genai output after YOU YOURSELF experienced developer have guided the process. But the "second-hand, noob developer, at large scale" ai slop is absolutely bonkers.

Reply

[-]

CandidateNo2580@reddit

It actually changed my viewpoint on the subject the first time someone reframed it like this to me. Whether it's copy/pasting bad code from stack overflow, ChatGPT, or another part of the project. Bad code is bad code.

Reply

[-]

Beginning_Basis9799@reddit

Spend time training them maybe that will help

Reply

[-]

Alpheus2@reddit

Netflix Directors use a Keeper test: if the person quit, would you fight to keep them? If not, it’s a hard decision you’ll need to have. Better sooner than later. Doom and drama aside. Training your juniors is a responsibility of your EMs and Seniors. They’re the ones that need to set an example, share the knowledge and police each junior to learn. If that’s not happening, or ineffective then you have a huge gap in your culture which you can capture as a learning and reward opportunity.

Reply

[-]

angrathias@reddit

Op isn’t running Netflix

Reply

[-]

TheOnceAndFutureDoug@reddit

The Netflix thing is also considered to be pretty fucking toxic... So there's that... This industry would be a whole lot better off if we looked at what most FAANG-like companies do and just went "OK, not that."

Reply

[-]

Alpheus2@reddit

OP also isn’t running a functional team devoid of toxicity. If you see his edit they’re firing the juniors so it’s not all roses and unicorns where they work.

Reply

[-]

TheOnceAndFutureDoug@reddit

I mean, if you read his other comments it became pretty clear pretty quickly that they hired juniors to save money and not because they understand what hiring juniors entails or requires of you. So, basic tech bro CEO bullshit, basically.

Reply

[-]

Alpheus2@reddit

Sure, but I can't verify any of that. Let's hope they're okay whatever's going on.

Reply

[-]

angrathias@reddit

I agree it’s toxic, but if people go into it knowing the stakes and benefits from it, I don’t mind the range existing. It’s not for me though, I’d settle for substantially less to not put up with that BS. But lots of real high performing grinders might dig it

Reply

[-]

chaitanyathengdi@reddit

Not the point.

Reply

[-]

angrathias@reddit

Well yeah it is, Netflix can get away with that behaviour because they pay so much. If you’re paying typical junior rates at a small company you can’t be so demanding

Reply

[-]

vinny_twoshoes@reddit

Just to add my voice, it sounds like a fairly straightforward performance problem that only incidentally involves AI. If you set expectations and the employees can't meet them, you do performance management and eventually let them go. The expectation here could be "submit high quality code that you can understand and justify". They're juniors, they probably feel insecure and are naively trying to submit as much code as possible to "do a good job". Given your comments, that insecurity is perfectly justified. They need to internalize the values of software development, and setting clear expectations is a great way to support them as they become more valuable and productive employees. You're not the direct manager, performance management of junior ICs isn't your job. If the people managers aren't doing it, that's a problem, and you need to talk to them about it to make sure they're on top of it. It sounds like you decided to cut the junior positions. That's your decision to make, if you don't think the investment is worth it. But I don't think it has anything to do with AI.

Reply

[-]

Data_Scientist_1@reddit

At my company a really bad dev was let go. He often wrote really bad code that broke different things in prod. It took management to over a year, and a lot of headchaes to let him go. Why? because some seniors/mids were clearing the garbage code themselves. When mids/seniors started moving somewhere else, then it was clear we had a lot of bad devs. It's not AI it's the lack of accountability they have. I'd follow some advice given here: 1. Review if deadlines are too tight. 2. Review the kind of work you're trusting them with. 3. Have a chat with them and HR, and a clear path towardss being better. 4. Check if there is some cultural stuff, or backlash going on (It's your responsibility as a CEO to provide a healthy work environment). 5. If you are mentally exhausted then outsource work you cannot, and are not capable of doing to another company.

Reply

[-]

TheOnceAndFutureDoug@reddit

Given OP's final response to all of this, and the comments they've made along the way, it very much sounds like a management issue to me.

Reply

[-]

Data_Scientist_1@reddit

Most likely yeah.

Reply

[-]

therusho0@reddit

As a person who has experienced my code getting rewritten without any explanation, I would have loved the opportunity to learn why my code was subpar. I think the first solution, as others have pointed out, should have been to teach the juniors. That’s kinda the reason to hire juniors in the first place. Seeing that the decision to remove them was made is actually indicative of the culture at this company, and most likely people don’t grow here anyways.

Reply

[-]

entropyofdays@reddit

“Edit: After a short meeting with directors, we decided to replace the 7 juniors that we have, with 5 mid/senior developers, and change company policy to strictly not hiring graduates anymore. I'll leave the post up.” And this is why the hiring market for Juniors is ostensibly all but dead. Sometimes I feel like a got the last chopper out of Nam.

Reply

[-]

TheOnceAndFutureDoug@reddit

And it's fucking insane because I've had some amazing juniors come through. And people misunderstand how getting the right junior can be amazing for the team. But the team has to be on board with the idea.

Reply

[-]

FineHairMan@reddit

thisn is a great way to lose your seniors

Reply

[-]

JaySocials671@reddit

yea

Reply

[-]

TheOnceAndFutureDoug@reddit

So, the issue isn't inherently AI. Shitty juniors have always existed, AI just makes it easier to be lazy. The issue is the quality of work they're delivering. This is a management issue and these juniors need to be properly managed. The plot goeth thusly: 1. You tell them it's not OK, tell them what is expected, give them the resources and support to improve. 2. If they don't improve you pull them into a meeting with HR and put them on a PIP. They now have a clear timeline to achieve a clear goal or there will be consequences. 3. If they fail the PIP they're gone. The important part is ***a PIP is not just a step along the path to firing someone***. You're giving them a real chance to improve and there is a realistic path forward that results in them keeping their job and place on the team. You need to make it clear you expect them to ask for help and get feedback, that you are going to check in and you want them to raise their concerns and difficulties. They are in the learning stage of their career. It is expected that they will need help. If you give them a proper chance with real support and they still don't do it? OK, well, at that point it's fully on them and it's time for them to go. This is the same for any dev at any level. Just the expectations get higher the more senior the dev.

Reply

[-]

Sporkmancer@reddit

I'll stress that regardless of intent, never place someone on a PIP if you're not planning on being able to replace them. A lot of people, either through first-hand or second-hand experience, have good reason to not trust PIPs as anything other than the joking title Paid Interview Period. Fully expect them to only do the bare minimum to require you to let them go at the end of the PIP and for them to be job hunting the whole time, as standing advice for getting a PIP is to expect to be fired no matter what and to start job hunting hard.

Reply

[-]

TheOnceAndFutureDoug@reddit

There is that too. A PIP is an ultimatum: Get better or we're going to fire you. Ultimatums only work if getting fired is a possible outcome you're prepared for. And some companies 100% use it as a "we're going to fire you we just need to make sure there's a process so you can't as easily sue us." Also, fuck those companies.

Reply

[-]

angrynoah@reddit

> Now I get that AI tools are part of the workflow these days, No. This is *not* inevitable. Your org is _choosing_ to allow it and suffering the predictable consequences. Don't do it. Just don't!

Reply

[-]

son_ov_kwani@reddit

This is sad. 😢

Reply

[-]

dendrocalamidicus@reddit

They are juniors, they need guidance on their development. Get rid of them...? Help them improve. If after repeated warnings their quality doesn't improve then maybe get rid but that doesn't differ from any other kind of repeated bad choices despite guidance to the contrary. This is not a new problem requiring new and extreme measures. It's an old problem with a new twist.

Reply

[-]

Leopatto@reddit (OP)

I'm running a business. It's not a charity workshop or a summer bootcamp where we dance in a circle and hold our hands together.

Reply

[-]

Sporkmancer@reddit

You don't sound like you should ever be responsible for employees, much less software engineers. The purpose of juniors is not immediate payoff. It's getting someone who has the starting knowledge required and shaping them into the senior developers on your team...and it's largely using the same continuous education that should be already present with the senior developers, i.e.: * Mentor down (more junior developers AND more recent company additions are given a mentor who is more experienced at the company and already in a senior role) ** The mentors shouldn't be allowing incorrect usage of AI by juniors period, and should be empowered to stop junior developers from using it if necessary. * Have continuous education courses available, encouraged, and incentivized in some way * Have some sort of goals based on personal learning and development set by each engineer The person(s) in charge of the development teams should be managing all of these, and that alongside quality controls on the code base (automated builds and tests, pr requiring those as well approval by a reviewer who is empowered to deny bad prs, actual quality assurance and user access testing, etc) pretty much solve the problem for you. Any developers trying to get by on just AI slop after this should be stopped by: 1) their mentor 2) potentially by the continuous build and test process 3) the pull request reviewer 4) quality assurance testing the feature/bug fix 5) user access testing of the feature/bug fix If the problem gets through all five of those, are you letting all bad code through, or are they actually not writing especially bad code?

Reply

[-]

Smok3dSalmon@reddit

Then manage them. jfc

Reply

[-]

Leopatto@reddit (OP)

My job is to ensure the company grows and earns fat margins. It's not my job to babysit and see how my engineers are performing. That's the job of my directors and their managers.

Reply

[-]

UrbJinjja@reddit

imaginary career lmao

Reply

[-]

Floyd_Ostertag@reddit

Then why TF are you here asking these questions? Literally a hundred of good suggestions, all shot down by "it isn't my problem to solve"... Excuse yourself and let your dev team lead solve this, ffs

Reply

[-]

verzac05@reddit

I run a non-technical firm in a non-technical industry (used to be an eng manager, now I'm just doing software as a hobby). > It's not my job to babysit and see how my engineers are performing. If you think this issue is important enough that it warrants a quite lengthy Reddit post from your end, why don't you figure out the problem by getting directly onto the ground? Interview your team members: are the juniors just stupid or is there some broken process in the middle? I think - and do CMIIW - the issue is that you're delegating the resolution of this problem, yet the people you're delegating to can't solve this either (presumably, since you're here after all). Investigate the problem. Or don't, but don't complain about the problem persisting afterwards. It's a decision _you_ have to make. > That's the job of my directors and their managers. Actually, that's _your_ job. You just delegated that job to your directors and their managers. And it's fine if everything is going smoothly, but it's not - at least not for you (such that it warrants this post). If they're negatively affecting the company, it's _your_ head on the table. So _you_ have to do something about it. From your parent comment, you mentioned: > I'm running a business. Then why did you hire juniors if hiring them doesn't give you the outcome that you want? You either fix your team to make "hiring the juniors" work, or you get rid of the juniors. I get it, everyone here is basically saying "OMG you're so stupid," with their tone, and it does seem that those comments made you a bit defensive. What they're saying, however, does hold some truth: juniors are stupid, and if your team can't handle it then get rid of those juniors. PS: my company, which is not in tech, can't handle juniors as well - that's why we don't try to hire them in the first place. Again, juniors aren't for every team. Useful reading: https://paulgraham.com/foundermode.html

Reply

[-]

WarthogConfident4039@reddit

That's the job of my directors and their managers. Then manage them FFS. They hopefully don't need their hands held.

Reply

[-]

Smok3dSalmon@reddit

Then get rid of the juniors and let your seniors continually demand more salary because you're ineffective at training up young, cheaper replacements.

Reply

[-]

dendrocalamidicus@reddit

I don't think you understand what the employment of junior developers entails They'd be better leaving and finding a better employer if that's what you have to say

Reply

[-]

kitkatlynmae@reddit

Srsly like this CEO ass attitude is what makes being a junior so dreadful. Why not just employ only experienced devs then? Is it cuz you have to pay them more lmao

Reply

[-]

i_am_bromega@reddit

The response was phrased like a dickhead, but if you look at the update, that’s the conclusion they came to (no more fresh grads). The problem is real, though. I am thinking eventually our team will try to advocate for juniors not to get access to the AI tools we have available until they hit some development milestones. The AI slop PRs we are getting these days are out of hand and wasting senior dev time in the review process.

Reply

[-]

kitkatlynmae@reddit

I think your plan is more realistic and fair than the ops to just cut all juniors but yk his company his decisions ig. The way AI has come in and changed the field and how people learn is new to everyone and senior devs with 7+ YOE aren't gonna be in the field forever if no one tries to train some of the juniors.

Reply

[-]

chaitanyathengdi@reddit

I was absolutely gobsmacked reading that too.

Reply

[-]

callmejay@reddit

You sound truly awful. I hope you are just trying to parody CEOs in this thread period

Reply

[-]

Slayergnome@reddit

Then you are getting the exact quality of employee you deserve. They are giving you the exact same level of investment you are giving them

Reply

[-]

Enesce@reddit

YTA, OP.

Reply

[-]

PorkChop007@reddit

This. He says he runs a business but 10% of his engineers are juniors, people who everyone knows don't produce anything for months and are a net expense for the company for at least a year, but when he's reminded of it turns out that those juniors have to be productive.

Reply

[-]

GlitteringAttitude60@reddit

the don't hire juniors. juniors aren't just cheaper labour, they are apprentices. if your business model doesn't support taking the time to \*teach\* juniors, then you have no reason to hire juniors!

Reply

[-]

Andrew64467@reddit

The business case for hiring juniors is that, with the correct mentoring, they become more senior and can be a bit cheaper than hiring seniors directly. Juniors are expected to need mentoring before they are actually contributing to the company. So if you didn’t understand why you were hiring then maybe a more qualified ceo is needed.

Reply

[-]

opakvostana@reddit

Then why have you hired juniors? Do you think a junior developer's primary responsibility is to be a highly productive IC? That's what Seniors do. But to get to Senior, your Juniors must learn first, and that's their primary responsibility.

Reply

[-]

PeachScary413@reddit

This guy most likely thought he found a cheat code, "Hah I'm just gonna hire juniors instead and expect them to produce like seniors but for much less money # justceothings 😎🤌"

Reply

[-]

Leopatto@reddit (OP)

I think it's fair of me to expect some form of knowledge and business value that an employee brings once I hire them? Sure, you have... I don't know, data-science degree, I expect you to at least understand how to create a database? How to GROUP BY? I know a freshly baked junior will never be equivalent to a dev with +5 years of experience but I'm not asking them of impossible, I just want these guys to use their brain a little.

Reply

[-]

vicblaga87@reddit

Not sure why the downvotes. Probably cause reddit commenters never had to run a business and don't know what it looks like from the other side. Totally agree that juniors should have a minimal understanding of basic concepts like a table view etc. If they don't, that's an indication that your hiring process is leaky. I'd try to analyze that. What's the expected skill level of the candidate what questions are asked to ascertain said skills is it working / delivering the right candidates or not? In my experience most companies don't really design or debug their interview process and just improvise. This needs to be addressed.

Reply

[-]

Leopatto@reddit (OP)

I mean /r/experienceddevs is mostly grads from college. Some form of background check should be necessary, but hey. I specialise in data/engineering, so for a junior, it's some simple form of creating CTEs based on the business case, some basic Python, bit of their past experience if they have any. Nothing too complicated.

Reply

[-]

vicblaga87@reddit

My advice is that you sit down with your managers and figure out why the hiring pipeline is leaky.

Reply

[-]

LePhasme@reddit

I don't know if you realise but these juniors are being told by a huge chunk of the industry that AI is the future and its a mandatory skill to learn and because they don't have much experience they will embrace it, specially with all the hype around it. They are juniors, they need guidance, if you fire them because of that either don't hire juniors or let someone else manage them because you're a shit manager.

Reply

[-]

chaitanyathengdi@reddit

You don't really get the level of current juniors. Be ready to train them from scratch, and expect them to have forgotten most of what they learned in college. The only real skill you need from them is that they grasp new stuff quickly.

Reply

[-]

Academic-Egg4820@reddit

That's why you have the interview, to filter out those candidates which lack the knowledge you consider necessary for the job...

Reply

[-]

opakvostana@reddit

Those expectations have to be more than just a verbal "I expect you to do X, Y, Z". What are the consequences if they don't deliver on these expectations? Are they communicated well? When it comes to quality of output, in engineering circles we have whole suites of tools to do this with, but the most important one is the code review. If a project has some requirements on code quality, someone else's ( preferably more experienced ) eyes need to have confirmed that quality is there. And even before AI we had tools like SonarQube, but always in addition to manual code review, never as a replacement of it. Nowadays there's even AI code review tools, but having used some of them, the reviews they make are garbage most of the time. Manual is still the way to go imo, and it's an excellent way to teach juniors what is and isn't acceptable in your codebase.

Reply

[-]

thrynab@reddit

That’s a sweatshop mindset. You know what you get when you apply that mindset to your business? The absolutely lowest qualified, lowest skilled, lowest trained, lowest motivated employees possible. Everyone else leaves for other companies. That’s fine for sweatshops because their product and process requires no higher skills, but it is absolutely cancer for a technology company.

Reply

[-]

normalmighty@reddit

Junior devs are typically a net-negative for a least the first month or 2, while they learn the ropes and get an understanding of what real world workshops are like. The important part is not the fact that they are relying too much on AI without understanding it, what matters is whether the more experienced devs peer programming with them are giving them clear feedback to change this, and whether they're improving as a result. If they are getting clear and useful feedback to improve, and are still not improving, then it makes sense to let them go. That _should_ be a rare case though. If you're finding that the juniors are all failing to speed up, then something else is going wrong. I would guess either the other devs are not training them well enough, your standards are too high for a junior and you shouldn't have hired entry level, or there are issues in your hiring process and you're letting completely incompetent people cruise the the application process unabated. Hard to tell which, if any, of those scenarios you're dealing with from a reddit thread alone.

Reply

[-]

PM_ME_FRIENDS_@reddit

I think you're looking at it the wrong way, helping juniors to improve is not charity because "charity" implies that you get no material returns. It's an investment, if you support juniors ability to grow they will grow into competent high-value seniors that have an intimate knowledge of your domain, some of them might even stick around if you treat them fairly and maintain the balance. It's charity in the same way that buying equities is charity to the liquidity providers or that gardening is charity to insects.

Reply

[-]

Organic-Remove8095@reddit

Oh, I understand, you are slow. If you want better talent hire mid level developers not juniors. If you want to nickel and dime your workers that’s ok it’s just more work on your part. Turnover + a sloppy code base + rewrites galore…

Reply

[-]

dutchman76@reddit

Agree, there's a big difference between helping people grow with their job, vs needing to teach them the bare minimum.

Reply

[-]

Organic-Remove8095@reddit

Oh I understand you are slow. If you want better talent higher mid level developers not juniors. If you want to nickel and dime your workers that’s ok it’s just more work on your part. Turnover + a sloppy code base + rewrites galore…

Reply

[-]

TheOnceAndFutureDoug@reddit

Then don't hire junior level engineers. Juniors aren't a cheat code to cheep labor. You basically hired someone who just learned to drive and then told them to drive a semi.

Reply

[-]

thashepherd@reddit

You are running a business, and employee retention is a core part of making that business successful. Hire a manager or VP Eng in between you and the team if necessary. These are people that YOU hired, right? I'm not saying that getting rid of the underperforming juniors is necessarily the wrong move. I'm just saying...

Reply

[-]

GuyWithLag@reddit

Then don't hire juniors, as they do need guidance. You have seen the results if you don't offer them that.

Reply

[-]

opakvostana@reddit

How do your more experienced devs "clean up" this messy code of the juniors? Shouldn't the juniors themselves be cleaning it up, after feedback from the seniors? That's kind of the point of a code review process. And no matter how lazy of an engineer you are, if your AI slop generated code keeps getting destroyed at code review, at some point you've gotta figure out that just copy-pasting slop is just making more work for you, not less.

Reply

[-]

chaitanyathengdi@reddit

Except it's not, because the person cleaning up is not the same as the person writing the code.

Reply

[-]

GlitteringAttitude60@reddit

why not? I am mentoring a junior right now. She submits a PR, I add comments, and she fixes the issues. If she doesn't understand my comments, she calls me and I explain it in more detail. When the code is up to my standards, I hit "approve". The two of us have been doing this for two years now, and I can count on one hand how often I committed code to one of her branches.

Reply

[-]

chaitanyathengdi@reddit

I agree. But the way it's happening here, the junior does not clean up after himself, the senior does.

Reply

[-]

bjenning04@reddit

That’s a problem that needs to be fixed. I’m sure that’s super frustrating for your seniors, to the point that I’d be concerned about retention.

Reply

[-]

GlitteringAttitude60@reddit

yes, and this process is wrong and will make sure that the junior doesn't learn anything :-/

Reply

[-]

SideburnsOfDoom@reddit

>if your AI slop generated code keeps getting destroyed at code review, In my limited experience of "AI slop generated code" what it targets is "looking right". It has all the superficial markers of being correct. But often it isn't. And that's why it's worse than useless, it will waste more of your time than gibberish that's instantly recognisable as wrong.

Reply

[-]

bjenning04@reddit

If that’s the case, a new step in the process needs to be added. Maybe have the juniors run a more official engineer testing? Or possibly have the seniors run quick peer testing to find the issues before they’re merged? Or have QA test it (if you have a QA team anyway). There’s tons of ways to handle it while still pushing the actual work of fixing issues back on the juniors so they can learn, just might have to add some minor annoying red tape to get there.

Reply

[-]

LeftMove21@reddit

But surely it shouldn't pass tests if it only looks right? And if the tests are bad then shouldn't that come up in the review stage?

Reply

[-]

Krackor@reddit

If the tests are written by AI they can also be superficially correct in a way that matches how the AI production code works, but subtly fails to match how the system needs to work in production.

Reply

[-]

binarycow@reddit

I think you just convinced me of something. AI should never be used to generate the system under test *and* the tests. If humans write the tests, then AI can write the code. If humans write the code, then AI can write the tests.

Reply

[-]

Krackor@reddit

I frequently have realizations about corner cases when I'm writing prod code and when I'm writing tests. Skipping either of those activities would likely lead me to miss thinking about some aspect of my problems that I also wouldn't think to include in my llm prompt. Humans should write both.

Reply

[-]

prescod@reddit

AI can also spark realisations about corner cases. The other day AI was really insistent about adding a line of code which if took me a few minutes to realize I really needed. And having AI do the easy stuff gives me more TIME to think about the hard stuff.

Reply

[-]

binarycow@reddit

>Humans should write both. I agree. But if that wasn't possible, then humans should write one.

Reply

[-]

chaitanyathengdi@reddit

I would say humans should write half of each. Do the hard part yourself, then use it as a baseline and automate the boring and repetitive stuff via AI.

Reply

[-]

Cobayo@reddit

It's fine to use it to write tests, it's even where it performs best. You gotta remember it's a tool and how it works, you cannot provide the implementation as context, but every detail of the design and a generalization of the interface. I.e. your prompt ends up having so much information that it sounds redundant because at that point you could do it yourself. But that's kinda the point, it saves time on the implementation.

Reply

[-]

DaRadioman@reddit

Honestly more than that, AI should only write tests without having the context of the implementation at all. Because otherwise it just telegraphs the existing implementation details anyways. You can do that by generating tests off an interface, or simply doing it before you do the implementation.

Reply

[-]

binarycow@reddit

>Because otherwise it just telegraphs the existing implementation details anyways. Yeah that's a problem with humans writing tests for the code they wrote themselves too

Reply

[-]

DaRadioman@reddit

Sure, but humans can guard against it. AI (Modern day LLMs) lacks true reasoning at all. Aka it's solvable with humans but not with AI.

Reply

[-]

binarycow@reddit

I'd say that humans are more susceptible to it. If you (a human) wrote the code, you're going to have a bias when writing tests. It's unavoidable. You can't just forget the code you wrote (at least not voluntarily) AI (in theory) could be told to ignore the code it wrote. The question is - is the risk of that happening worse than the risk of AI slop? ---- I'd say, that for me, the options are (in order of preference, highest preference first) (note: I don't like AI, so there's a bit of bias in my preferences) 1. Human A should write the code. Human B should write the tests 1. Human writes the code. Same human writes the tests, paying special attention to ensure they write tests to the specification, not to the specific implementation 1. Human writes the code. LLM writes the tests 1. Human writes both the tests and the code, not caring about testing the specification vs. the implementation 1. LLM writes the code, humans write the tests (against the specification) 1. LLM writes the code. LLM writes the test, but is instructed (somehow) to ignore the implementation 1. LLM writes everything with no safeguards in place

Reply

[-]

DaRadioman@reddit

Lol you overestimate my short term memory. The exact details of edge cases are lost to me well before I am done coding. But also you can just write the test scenarios ahead of time to make sure you cover the right cases. The outputs should be mostly obvious and you don't need the full tests. Just "GivenXThenY" sort of details. A human can easily do that, even assisted by AI. As long as you stay abstract and not concrete it can all be very scenario driven/high level.

Reply

[-]

ToThePastMe@reddit

Also in my experience it is more verbose. In python for example you get type hints, docstrings, so many comments, over the top error handling. So sometimes 3 lines of code get turned into a 50 lines function. So it is harder to see when wrong, and now you have so much more stuff to update. Or you have to just replace the whole thing. I do still find value in LLM generated stuff. Maybe 20% of my code is. But never chunks so big that I can’t quickly check their sanity myself

Reply

[-]

svachalek@reddit

If you have true senior devs they can tell the difference between “looks right” and actually correct. In the age of LLMs, developers are now more code reviewers than code writers and they need to be very very good at it. Set standards for what a code review consists of and do trainings if you have to. Priority 1, all code reviews should include tests.

Reply

[-]

SideburnsOfDoom@reddit

I agree that "deep review" and "has good tests" are going to be more important than ever. Because you're going to be swimming in slop. And that these are the hardest skills.

Reply

[-]

PanicSwtchd@reddit

Mans out here playing at being a LinkedIn Guru at this point while workshopping posts on reddit. Posts 10 hours ago talking about how stuck they are, and then immediately has decided to remove 7 employees and replace them with 5 employees lol. Skipped the attempt to fix the problem phase entirely when the comments didn't go their way lol.

Reply

[-]

armahillo@reddit

A junior shouldn't be using LLMs because it's going to impair learning. An employer shouldn't be expecting a junior to use LLMs because it's going to impair their growth. If you've told the juniors "don't use LLMs to do your work" and they continue using it, then yes, get rid of them. If not, then start by telling them "don't use LLMs to do your work."

Reply

[-]

ElonTaco@reddit

Yes

Reply

[-]

sunshine_g1rl@reddit

Yes

Reply

[-]

CauliflowerIll1704@reddit

Typical upper management that lost touch with their workforce and refuses to take responsibility. Its obvious your experienced devs and yourself are neglecting the juniors, refusing to train them, and wondering why they are not performing as if they've programmed since they were 12. If your experienced devs were mentoring properly them the juniors wouldn't have to ask a chatbot for help.

Reply

[-]

ListenLady58@reddit

How positive are you that the leads and seniors aren’t just complaining because they don’t actually want to help junior devs because they don’t think it’s part of their job? How much you want to bet they are hoping you’ll just get rid of the juniors so they will be more valuable in the future? Seniors and leads many times do not have the best intentions.

Reply

[-]

SuperCaptainMan@reddit

As far as your hiring process goes, ours is similar but we have an additional pair programming round to filter out issues like this.

Reply

[-]

Dismal_Hand_4495@reddit

So I take it you are not a people person? Have someone that is, take a look at the situation.

Reply

[-]

Direspark@reddit

This post and OPs comments are why I believe most C suite executives are not human beings. Jesus christ.

Reply

[-]

nomiinomii@reddit

When auto complete and auto correct were introduced 15 years ago, did you not use them? When a better language framework or IDE came along did you not use it? AI is just the next good tool,there is absolutely nothing wrong in using available technology. Don't be a boomer

Reply

[-]

humanCentipede69_420@reddit

Gonna be honest with you man… you sound like kind of an idiot who doesn’t know what they’re doing. Regardless of whether it’s AI or whether the junior hired a chimp to write their code, it’s still their code. It’s not AI slop, it’s just slop and they have to take ownership and alter their code during PRs regardless. You do know what a PR is right? It’s a magical thing that exists to solve this problem.

Reply

[-]

sadFGN@reddit

If companies only value productivity over other metrics, that’s what we’ll start to see more and more often. Juniors are afraid as hell and will use AI as much as they can as an effort to keep their positions. Sad. 😢

Reply

[-]

Nilreboot@reddit

Please swallow your pride and use the backlash you’ve received as a learning experience. I am sure you’re a smart guy, but do not be too humble to take feedback that you wanted to hear. If you want an echo chamber you have a mirror. The fact that you’ve come to Reddit for help leads me to believe that we aren’t the first to give you an answer you didn’t like. If that is the case, you can still fix it. Realize that your intuition is off and rebound yourself. If we are all wrong, but you tried it, then you can still backup your reasons for why you decided to against it, but at least you tried.

Reply

[-]

lllama@reddit

I am generally an AI doomer, I think it will ruin codebases if you let the slop in, etc. That said, if your company allows AI tooling, isn't this what you would expect from a junior? It reminds of pasting code from Stackoverflow. People would copy in code they fully don't understand, there was pushback against this,but for better or worse it became industry practise. To some degree before this and parallel to this, overly relying on importing libraries caused the same discussion. We can joke about `node_modules` directory sizes, but it's only funny because it's often true. AI tooling will abstract developers further away from what they are doing, it will cause projects to bloat and make them less maintainable, it will take more time to get anything done over the long term (obviously this is common misconception AI) but it will require less skilled people. You can still work places now that run a tight ship and where every piece of external code is treated with suspicion, whether it's out of necessity (e.g. regulatory) or mistrust. And those places will continue to exist. But if you leave the slop gates open, slop is what you will get.

Reply

[-]

TheTyger@reddit

Companies need to have better guidelines on how much AI a given role can use. Jrs should be making very limited use of AI code, but can use it for rubber ducking. Srs should be able to use AI and not slopify the code base. But companies need to be super clear about the way AI is to be used, and they need to make sure that the Jrs understand *why* those rules are in place.

Reply

[-]

lllama@reddit

So my pushback against this is: - if you allow devs (juniors or otherwise) to paste large snippets of code without understanding - if you allow including outside libraries ad-hoc then you're going to end up with AI generated code regardless of your policies (if you allow AI tools to be used). AI is just another source of outside code. There are plenty of places where anything you include you are responsible for, in some cases with formal procedures around it. But places are in the minority. I've never really seen a place that managed a good middle ground here. It seems to you it's either this, or it's more or less a free for all. The problem is that if your in the latter category, and you allow AI tools, the floodgates are open, and this _will_ impact quality. Technically your proposal doesn't (necessarily) fully endorse this ("only rubber ducking until you get the senior badge"). For junior anyway. I don't think a caste system will work though. "Seniors" should be held to the same standards, or you'll just have the same problems.

Reply

[-]

TheTyger@reddit

Yeah, I am in a lot of discussions right now about how we manage to leverage AI (co-pilot) to get our work done better, but also make sure that the Jr devs are continuing to progress and learn at an appropriate pace. One of the problems is that the experienced folks are not generally jumping in on the AI side because they can just code it themselves since they know what they are doing, but the younger ones are ready to jump straight into AI assist coding (or I'm sure some straight up Vibe coding) without learning the actual things that we want them to learn. It's a new and difficult problem.

Reply

[-]

hatsandcats@reddit

Doesn’t strike me as an AI problem. Strikes me as: 1. Seems like something is causing them to rush - do you know what their workload is like? 2. Code standards - anyone can generate slop with or without AI, question is how are they deploying / submitting it? This should be getting caught by a review process.

Reply

[-]

nsxwolf@reddit

This post sounds like fiction.

Reply

[-]

akp55@reddit

Awesome, so now you're making it so these new grads have one less place to land. How about fixing your process and putting in something about responsible ai use for coding?

Reply

[-]

dijkstras_revenge@reddit

Don’t approve the PRs if the quality isn’t what you want. They’ll leave they need to reach a higher bar of quality/

Reply

[-]

SideburnsOfDoom@reddit

This is in my experience harder to tell with AI. Just like chat-gpt generated essays, the issue isn't typos, it's that the text doesn't really go anywhere. In other words, it has the superficial markers of quality, but will waste your time before you (if you) work out that it's pointless.

Reply

[-]

svachalek@reddit

Your review process needs to be more than “yup, looks like it has superficial markers of quality”. All code needs to have tests that clearly demonstrate it works as advertised. Make a checklist of other things that need to be done as part of a review. Every time someone is tricked by slop add something to the checklist. For starters check that the code is minimal. AI loves to write a 3 page essay when a yes/no answer will do and the code is the same, assume any big PR is slop until proven otherwise.

Reply

[-]

SideburnsOfDoom@reddit

agreed, but rather than repeat them, [I refer you to my comments here](https://www.reddit.com/r/ExperiencedDevs/comments/1lotbsm/comment/n0qlb37/)

Reply

[-]

Kajitani-Eizan@reddit

Is this post and your comments on the replies AI slop?

Reply

[-]

SpriteyRedux@reddit

I don't think there are juniors anymore. The "half-right, sometimes" machine provides the exact same quality of output and costs essentially $0 by comparison.

Reply

[-]

IceNorth81@reddit

Sounds like you need a reality check, I’m a senior dev/architect and use AI tools 95% of the day. It’s not about the tool, it’s how you use it.

Reply

[-]

Leopatto@reddit (OP)

But you **understand** if say something fails because XYZ happened. You have the knowledge and some form of experience.

Reply

[-]

Xsiah@reddit

I didn't right after college, and we didn't have ChatGPT back then. Understanding comes from experience, which you just denied these people without even trying to address the issue with them.

Reply

[-]

LanguageLoose157@reddit

I think AI slops is fine as long as there are test to convert changes 100% and test explain what the F the AI code is doing

Reply

[-]

steve_nice@reddit

Personally I would rather work with the new guys and train them up more to work specifically how you want. Have them speak up more so you and others can interject.

Reply

[-]

chaitanyathengdi@reddit

"no live coding" Why the hell not? Better waste your seniors' time in the interview room filtering candidates who know their stuff than waste it training juniors who don't. Who selects the people then? Some hiring manager who can't code a factorial function?

Reply

[-]

Leopatto@reddit (OP)

All of my PMs have technical background, they're the ones with the final say and decision. It really depends on what's the open position, could be back, front, cybersec, data, etc. Frankly, no live coding was my decision. When I was younger, I used to get stressed out during those live interviews because they were bullshit.

Reply

[-]

chaitanyathengdi@reddit

You should reevaluate that decision then, for the sake of your more skilled workforce.

Reply

[-]

Leopatto@reddit (OP)

I do have a meeting with my directors today. We'll most likely search for mid/seniors and let the juniors once suitable replacements are found.

Reply

[-]

chaitanyathengdi@reddit

You misread my reply AGAIN. Just have a more in-person screening process, will you? Hiring juniors is cheaper than seniors even if you are paying above market rate for them (unless you pay your seniors bottom-of-the-barrel rates, which is disgusting). Instead of having an experience cutoff (which I can tell you, doesn't work either) hire competent juniors who have a passion for the craft and invest money in training them properly (and I mean proper training, not a Udemy membership). You will be much better off in the long term.

Reply

[-]

Leopatto@reddit (OP)

We decided to let them go.

Reply

[-]

seabum18@reddit

I hope your company rethinks that decision. I don't see how cutting all your junior devs will play out well long-term when your seniors retire, quit, etc. Devs don't learn a company's codebase or clients' business processes overnight.

Reply

[-]

mattas@reddit

I don’t. Dudes an egomaniac (“my seniors” - what kind of fucked up language is that?) and sounds like a hostile environment for a junior to learn. They are better off not employed there.

Reply

[-]

ersados@reddit

pp

Reply

[-]

ijustmadeanaccountto@reddit

Ai slop will make me a senior. Cause the code and inconsistencies chat gtp produces, is so mindnumbingly annoying to clean up, that i end up learn a shitload of things. Tho my frustration levels are really high. Tbh the only decent usage is for brainstorming and glorified man pages for examples of usage. Thats all in doing nowadays. Its just slower debugging cancer, than spending some time to designing and prototyping your solution.

Reply

[-]

SpaceToad@reddit

Before they would copy and paste solutions from SO without understanding it, so this may be an improvement. The value in juniors is that they’re a fraction of the cost and you can upskill them to be useful contributors. With proper mentorship and training they shouldn’t produce slop, but you also need to make sure they’re assigned tasks appropriate for their experience level.

Reply

[-]

iamakorndawg@reddit

I think the solution described in your edit is unwise. If nobody hires new grads, how does anyone become senior? I think you need to have a frank conversation with the juniors and tell them they are at risk of losing their jobs. It is one thing for a junior to create suboptimal code themselves. But adding AI into it means they can create suboptimal code at scale. Consider banning AI, and if not outright banning, at least create some guardrails around its use.

Reply

[-]

ptrnyc@reddit

Great. Companies didn’t want people over 40. Now they won’t want people under 30 either. If developers now can only have a 10 years long career, like football players, maybe they’ll get the same kind of salaries ?

Reply

[-]

FredeJ@reddit

I’ve read some of your replies and I agree with what you’re seeing in large part. I think one part you could do is to set expectations. Most companies I’ve worked for recently are pushing AI, all the way from the board and the CEO. There may very well be an understanding from juniors that they _need_ to use AI to be viable. I think this is misguided, but I think it’s a very commonly held belief. And it’s being pushed by the entire culture. Everyone’s heard that they will be replaced by someone using more AI. I think that sharing your views on AI and your expectation for its use could be useful.

Reply

[-]

Leopatto@reddit (OP)

Perhaps I've paraphrased it wrong in the initial thread - I've got no problem using AI. I have a problem with my juniors using AI to solve a problem they don't understand and hope that the shit will stick and hold on for someone else to fix it down the future. Or just not willing to learn.

Reply

[-]

fragglet@reddit

Mentoring younger devs is an inherent part of the software development process and part of your job and responsibilities as a senior. I think it's a real shame that your "solution" to this problem is to just get rid of all the new grads. Be more selective in hiring, for sure (it sounds like your hiring process is broken in some way). But everyone has to start somewhere - you did too.

Reply

[-]

FredeJ@reddit

None the less, I still think expectation-setting is important. Let them know it’s not enough to be able to solve the problem. They need to be able to explain why they solved the problem that way.

Reply

[-]

Affectionate_Text_72@reddit

Other posters have made some good points about how you go about mentoring your juniors. I would just like to add that you should give them and indeed all staff guidelines about the best ways to use llms at work. Not how to prompt effectively (though that is imoortant) but this is what it's good for, this is what it isn't. How to use it to help you learn and grow and most importantly how to verify its output and this is what you are and aren't allowed to send regarding commercially sensitive information.

Reply

[-]

bsenftner@reddit

You need to be extremely rigid and not allow AI slop. It's a slippery slope, and you are on it. It may be painful it WILL BE PAINFUL, but in the end your team will have an integrity that others cannot match. The entire industry is going through this, this is a test of your management will and skill, and if you fail so goes your company into being an alsoran.

Reply

[-]

Equivalent_Lead4052@reddit

How many times does this question need to be asked?

Reply

[-]

irespectwomenlol@reddit

Have you thought about this from the perspective of some of the juniors? Have you put the juniors in a psychologically safe environment and tried to dive into their thought process here? For instance, the job market is bad right now and getting fired could be a big life changing problem for these people. Depending on your workplace, there might be immense pressure for the juniors to deliver results quickly rather than taking up more time to learn and do things right. Are you or higher ups giving them this time to learn and do things right? Or are you cracking the whip pressuring even juniors for rapid-fire results and then surprised that they do everything possible to hang onto their jobs including cutting a few corners with AI tools? This could be more on you than them. \> Edit: After a short meeting with directors, we decided to replace the 7 juniors that we have, with 5 mid/senior developers, and change company policy to strictly not hiring graduates anymore. I'll leave the post up but won't be replying anymore. What you posted as your solution is really subpar. It doesn't indicate any willingness to dig into the root cause of this matter. And where are the next generation of midlevel and senior engineers going to come from when juniors aren't given a chance? Not good.

Reply

[-]

StrayDogPhotography@reddit

Not a dev, but my father was a big IT project manager and he complained about this in the 90s and 00s. He said most new hires were useless, and their universities didn’t prepare them for real coding. What that means is one time most of you were once the useless hires. Companies have as much obligation to train their employees as universities do. In an ideal world universities would be good enough to pump out perfect workers, but frankly they don’t do that often. I know I spend most of time training graduates to do things that their degrees should have taught them.

Reply

[-]

hungryrobot1@reddit

We're in a transition phase where AI is not fully reliable to generate production grade code without significant effort by the user, so when low effort or inexperienced programmers don't know what they are looking at it introduces risks and as you say, incentivizes people to take the path of least resistance. Eventually AI will become good enough that we will be forced to reconsider what a developer is. Not only juniors but all developer will face this reckoning. today a skilled user who understands AI can get amazing production-grade code. But in the next 6 - 12 months we can expect continued leaps in capability that will allow others to achieve better results with less difficulty, and in the next few years we'll be in a different universe altogether with AI coding My point is that the non-technical things that differentiate candidates will become more profound at some point, where the limitation to achieving something in code is no longer technical but a function of the user's ability to reason and communicate. It might be helpful to formulate some of your assumptions around the likelihood that AI will continue to improve. For instance, what will your ideal junior developer look like 2 years from now? How do they differ from a junior developer from 2 years ago?

Reply

[-]

BmoreDude92@reddit

Are clients maintaining the code base after it’s delivered? If yes, than needs to be clean and concise. If clients want a working product than why does it matter what it looks like? Sr devs have a hard time reading it? Guess what use the tools at their disposal…AI. Us software engineers have a hard time separating the engineering from the business. With our jobs we are continually improving, we have that luxury. Unlike civil engineers. Our job is to create products and generate money.

Reply

[-]

rco8786@reddit

It’s incredibly telling that the introduction Of AI has made the people who know how to work *without* AI more valuable.

Reply

[-]

GrizzlyBusiness@reddit

My company has had large layoffs. I am a BI & Analytics Manager. I went from a team of 5 to a team of three, plus we lost contractors and other support staff. The only way we have been able to adapt is by abusing ChatGPT. It troubleshoots, can quickly edit code, can quickly create a wire frame for a solution. It has value and can be a teaching tool as well. It fills in skill gaps. Have your Jr devs prompt it to explain the solutions it provides as comments in the code, that way they can understand the outputs better as if they were coding in pairs. It’s not going away, the times they are a changing.

Reply

[-]

4iqdsk@reddit

It sounds like you're not doing your job to properly train your juniors, but instead you are trying to use them as a scapegoat for your own failures. Most people would reject the bad pull requests and ask the juniors to fix and not just fire the engineer without giving them an opportunity to improve. Also, it costs the company money to re-fill these positions and you'll just end-up with the same problem because you didn't resolve the actual issue which is proper training.

Reply

[-]

xt-89@reddit

You’d have to start giving them pop quizzes. Take 2 Junior engineers. Both use AI to enhance their productivity. How do you tell the difference between which is doing it mindlessly and which is learning after the fact? One of them might have a great memory and can immediately recall everything the AI did and why. One of them might be taking notes and studying them when they get home. There’s too much nuance to simply fire anyone that doesn’t pass your vibe check on AI use.

Reply

[-]

Adventurous_Bend_472@reddit

If you have told me 2 juniors are the problem but 7. Maybe guys you should check yourselves.

Reply

[-]

Dottore_Curlew@reddit

It's probably ok - but you must force them to actually understand the issue and the code. And then they can improve the slop ai made.

Reply

[-]

Organic-Remove8095@reddit

Make the deadlines longer and review their code as well as give the expectation for a higher quality of code being written then fire all the ones that fail to improve within 6 months. It’s a culture and management problem. Short term your company won’t see growth but in the long term it will

Reply

[-]

Leopatto@reddit (OP)

Unfortunately that's not how it works with clients. We can't just extend the deadline because we said pretty please.

Reply

[-]

DonaldStuck@reddit

I've read some other comments from you here. You don't "own" the business and you don't have agency. You're an employee inside your own company. You can call yourself CEO or whatever but seeing as you constantly blame others (clients, juniors) you need to realize that this role may not fit you. At this point clients run your business and juniors do too. You're the boss, act like it already!

Reply

[-]

Leopatto@reddit (OP)

I never blamed anyone. Come on, lol.

Reply

[-]

DonaldStuck@reddit

Let me guess: I'm wrong. Right? Right.

Reply

[-]

Leopatto@reddit (OP)

Nope, never said you were. *shrug*

Reply

[-]

DonaldStuck@reddit

Alright, that's true. But doesn't my first comment resonate with you? Not even a little?

Reply

[-]

Leopatto@reddit (OP)

I mean, the company made €9mil in profit in 2024, so I think I'm doing something right?

Reply

[-]

KokeGabi@reddit

Why you cosplaying so hard brah.

Reply

[-]

chaitanyathengdi@reddit

Wow, even my company stops at 1:5 and they pay garbage.

Reply

[-]

DonaldStuck@reddit

Your profit is impressive, congratulations!

Reply

[-]

chaitanyathengdi@reddit

Then suck it up and deal with it after the first prod deployment, phase-wise.

Reply

[-]

Academic-Egg4820@reddit

Based on your replies, this is a You problem. You have false expectations and you don't know how to handle the people. Think about what you expect from new hires, write it down. What you wrote down matches the junior level or is it more senior? Do you know what should be expected on a junior level? Google it. During hiring, whiteboard exercises can be made with gdocs or any shared IDE, it doesn't need to be in person. You can do it online.

Reply

[-]

Leopatto@reddit (OP)

Brother, I'm running a company of ~130 people in total. My question was whether I should let these people go or not because what's expected of them is not what my clients want.

Reply

[-]

opakvostana@reddit

[https://www.reddit.com/r/Construction/comments/1l4g9k1/comment/mw9d9o5/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/Construction/comments/1l4g9k1/comment/mw9d9o5/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) Is the construction company the one with the engineers? This is a sub for software development, sir, not laying mortar.

Reply

[-]

Leopatto@reddit (OP)

My dad runs construction business... he's a "client" of ours. And sure, I do know how to lay brick, build a house. I worked physically with him since I was 14 if you really wish to know my life story.

Reply

[-]

Academic-Egg4820@reddit

Busted...

Reply

[-]

Eogcloud@reddit

“ I’m the big boss but nothing is my responsibility and nothing is my fault”

Reply

[-]

Academic-Egg4820@reddit

Good for you, brother. If I would run a company of \~130 people in total with about \~70 engineers I wouldn't come to reddit for advice. I see that you expect short answers to your questions only and not any kind of input about the bigger picture, here is my 2 cents: **Is this a hiring problem?** \-> Do you mean, is it hiring problem that you hire people who you think are not good enough? My answer is yes. **Should I put more structure into mentorship and training?** \-> Juniors needs to be mentored. So this is also a Yes. **Or should I just cut the ones who aren’t delivering and spend more money on experienced engineers (which I could easily afford)?** \-> Depends on your goals. Do you plan long-term? Then you should create an atmosphere of learning. If you plan short-term, hire the senior guys who deliver the most value in short-term (since you could easily afford it).

Reply

[-]

entropie422@reddit

AI plays a part in this problem, but it's a culture thing, not an AI thing. It basically boils down to this: juniors generally feel like they're drowning to some degree, and the things that scare them the most are appearing incompetent, and being slow. Before AI, they would lean on SO to mitigate those existential risks. Yes, they would learn more that way, but it's the same dynamic: they're not learning from their seniors, they're basically treating the PR as their one and only point of contact, when it shouldn't be. If you have questions, the PR is not the place to ask them. But they're likely scared to *actually* ask for fear of looking stupid, and they're scared of taking too long to find an answer because they'll be seen as a drag on productivity. Hence GPT. You need to do two things to fix this: 1. Ensure they (and the seniors) understand that this dynamic of junior<->senior is not a performance review situation. If the junior is stuck, they need to be able to ask for help and not worry that their job is on the line. They won't learn and improve otherwise -- and any time you waste in this early revision cycle will be *more* than balanced out by not needing to rewrite all their code later. 2. Tell them that when using ChatGPT, to preface each request with: "help me understand how this works, and how to fix it, and don't give me the final code." Reading through the response will be more helpful than a final answer, and (weirdly enough) it tends to help LLMs suggest better answers, because they're having to systematically explain the logic, so hallucinations are harder for them to ignore. Basically, treat it like a hyper-targeted custom SO article. This is not a problem unique to you or your situation, because it's basically *always* been the case with juniors. You don't have a bad batch, they're just working around their fears with the modern tools available to them. Nurture them and reap the reward; shitcan them and I guarantee you'll just be playing this same game with the next set you hire, too.

Reply

[-]

Comprehensive-Pea812@reddit

This is why no one hires juniors unless you have a strong training program. they are barely able to do anything after they learn something and after 2 years and they become slightly productive, they leave. I know someone who does an internship training program for 2 months and picks the top 3 as employees. My previous managers absolutely despise fresh grad, just because company require each team to take 1 fresh grad. Honestly I am fine with with junior as long project is not on fire. most team operate on tight deadline and juniors are the salt on the wound.

Reply

[-]

Futbalislyfe@reddit

The problem isn’t AI. Juniors always wrote crappy code. Before AI most solutions were copy/pasted from Stack Overflow. The problem is the engineer who refuses to take time to understand their code. They are not going to grow and when they start moving up they will have no ability to refute whatever AI spits out. Even when I was fresh out of college, not once did I submit code that I did not know how it worked. There may have been 15 other ways to solve that problem that were objectively better than my solution, and my mentors would point that out. Maybe I missed some edge cases. But at least if someone asked me to explain how my code works I wouldn’t stare at them like a deer in head lights. That is the failure. AI can be a massive time saver, but if you don’t understand the code it produces you can’t fix the gaps. You will just produce garbage quality code for your entire career until you stop being lazy and start trying to learn. It should not matter how much experience someone has, if they cannot explain their own code they should find a new line of work because software engineering is not for them.

Reply

[-]

malthuswaswrong@reddit

You should ask your seniors what to do. The one that embraces LLMs as the future and says to build an SDLC robust enough to ensure quality is the one you should promote to manager. In fact, he should probably have your job.

Reply

[-]

SynthRogue@reddit

Maybe employ people like me then, who have spent the past 28 years programming, instead of having AI program for them. And yet still unable to find work after 2 years, since I was made redundant.

Reply

[-]

im-a-guy-like-me@reddit

You don't live in a world that doesn't have AI and you can't go back to it. I think that if you choose the route where you get rid of your current juniors and only take non-slop junior devs you're going to fail because you're sifting for gold in sewage water. I think you need to reorganize how juniors are onboarded and trained in this new AI world. If you figure it out, please let the rest of us know what the solution was. 😂

Reply

[-]

empusher@reddit

To be fair, everyone, including seniors, writes code barely understood by anyone, other than themselves, and even so only within about 3 weeks of writing it.

Reply

[-]

empusher@reddit

I think the best way to deal with unintelligible code (AI slop or otherwise) is to have the junior devs write clear documentation and, dare I say, tests. It’s win-win because not only will the devs now understand functionality (even if they just have AI describe it, hopefully they fact-check), it helps them learn, AND you’ll also end up with well-documented software!

Reply

[-]

travishummel@reddit

How does the code get merged? Sounds like you need a stronger code review process

Reply

[-]

haikusbot@reddit

*How does the code get* *Merged? Sounds like you need a stronger* *Code review process* \- travishummel --- ^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/) ^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")

Reply

[-]

dash_bro@reddit

I had a similar thing happen around 2022-ish, and then I made a policy that sorta fixed the issue to a large extent: - only hiring college grads who "have been" part of hackathons or similar short/focused periods of actual software building. - only slightly experienced devs go through the tech screening process you described. For fresh grads, I only bring them on as interns which may convert to a full-time position within 3 months of them being with us. Ofcourse, I'm pretty lenient with the definition of "fresh grads". Usually it's open to anyone in their final year of engineering/bachelor's degree, and can dedicate atleast 20 hours a week (preferably, in office). Being involved with the local scene for hackathons/mentorship etc boosted the type of talent pool I attract/my team attracts, and I think building culture by setting standards is important. My team has gone on to make multiple hires -- some work out, some don't -- but ultimately I'm very happy with the overall quality of work and the caliber of engineers I've got from them.

Reply

[-]

synaesthesisx@reddit

My company just stopped hiring juniors entirely. We can skip the humans and just have AI agents generate the slop directly.

Reply

[-]

Realistic-Team8256@reddit

Dont give LLM, Chatgpt access to the juniors, it should solve the problem

Reply

[-]

Londunnit@reddit

This hits close to home since I've helped a bunch of companies navigate similar issues with their junior hiring at NIAH Recruiting. Honestly? I think you've got a training/expectation setting problem more than a hiring problem. These juniors probably don't even realize they're doing something wrong. Have you actually told them explicitly that during pair programming sessions they shouldn't be reaching for ChatGPT first? Sounds obvious but you'd be surprised how many managers assume juniors just "know" this stuff. I'd try setting clearer boundaries first - like "during our pairing sessions, lets work through the problem together before looking at any external resources." Also your hiring process might need a tweak. No live coding means you're not seeing how they actually think through problems in real time. Maybe add a short problem-solving session where you can see their thought process? Before you cut them loose entirely, maybe give the ones who seem coachable a month with more structured mentorship and see if their behavior changes. The ones who keep defaulting to copy-paste after clear feedback? Yeah those might not be salvageable. But definitely don't just throw more money at senior devs without fixing the root cause or you'll keep having this same issue with every junior cohort.

Reply

[-]

Anythingbutpears@reddit

I think if you've only just started pair programming with your Juniors that's tge problem not AI. And if you have Seniors who are reluctant ot unwilling to work with Juniors and train them up that's also a problem.

Reply

[-]

thekwoka@reddit

If they were copying it from stack overflow and hoping and praying, what would you do?

Reply

[-]

johnwalkerlee@reddit

I agree, all my competitors need to stop using AI right away and hand craft everything using assembly. If you're not using assembly, you're not a real programmer and are just using compiler slop. Remember, it's more important to understand every nuance of every library than to make money.

Reply

[-]

Repulsive_Zombie5129@reddit

I don't think this guy genuinely came looking for advice. Moreso for validation and to bitch, based on the responses. Waste of time

Reply

[-]

Equal_Veterinarian22@reddit

"I haven't given these people any training, and they're not doing things the way I would prefer. Should I just fire them?"

Reply

[-]

YahenP@reddit

It doesn't matter who wrote the code and what tools they used. It's the result that matters, not the process. If the code meets the requirements, you accept the PR. If it doesn't, you reject it with a comment that it doesn't meet "such and such a requirement." This shouldn't be your problem at all. If the code requirements in your company are such that junk code is considered good, then you either accept it or change the rules for evaluating code. It's not the AI or juniors who are to blame for junk code, but the conditions that allow junk code to exist.

Reply

[-]

phil_lndn@reddit

> Is this a hiring problem? no, it is a staff management problem. just tell these junior devs that it is fine to use AI, *but that they must take the time to understand the AI output* because it is against company policy to commit code that you don't personally understand. that way, the AI will (hopefully) support their learning, rather than simply bypass it. note: keep them on their toes by occasionally asking them questions that check their understanding of the code they have generated!

Reply

[-]

Alarmed_Inflation196@reddit

What's your CTO communicated about AI usage? Encouraged it or discouraged it?

Reply

[-]

jhaand@reddit

What do you do with juniors that generate slop? Coach them, explain the limits, explain the slop or remove them.

Reply

[-]

anaconda_eagle@reddit

1. Ask each of them to have a session on the feature(s) they've worked. They can present about the logic and work flow they implemented. once in a month may be ? 2. You can set a policy on AI tools and what are expectations of using it. 3. Ask the leads to reject pr if found low in quality. P.S Invest and evaluate.

Reply

[-]

nio_rad@reddit

No LLM-usage at all for juniors! Or give them toy-projects where they can go wild with it, but for learning on actual projects it's the wrong tool.

Reply

[-]

Winter_Cabinet_1218@reddit

Whats the feedback loop look like? I mean AI is definitely here to stay and as Devs it's our jobs it's coming for first. I mean are your seniors talking through with the juniors why the code is sub par? Could you look to employ AI in a different way to maybe open a door for a conversation?

Reply

[-]

SearingSerum60@reddit

i understand using AI for hard algorithms or niche topics where it can save you a google. Using it for run of the mill features is fine if you clean it up. But “slop” committed to the codebase is a big no-no.

Reply

[-]

Revisional_Sin@reddit

Have an open conversation with the juniors and seniors about the problem, and ask them to solve it; they're the ones best placed to do this. I'd even suggest you stay out of the meeting so people are able to talk it through without fear.

Reply

[-]

divDevGuy@reddit

> when they hit something hard or challenging, they instantly open ChatGPT (or similar) and start writing out the problem and copying the solution; without understanding the problem or how to solve it. > ... > So now I’m stuck... > Is this a ____ problem?... > Should I... Oh the irony of the situation...

Reply

[-]

Eogcloud@reddit

What about talking to your employees, managing and doing your job? Oh right you’re a CEO who’s more useless at your job than they are at theirs.

Reply

[-]

rednoodles@reddit

Is the technical test just asking random coding questions or a take home project? I think you'd fix the problem by having a take home test/project. It'll let you see the code they output and you can have a senior dev do a 30 minute live code review with them instead of a technical test. Ask why they do stuff.

Reply

[-]

Majinmmm@reddit

This shit is going to get worse with AI.. lots of the AI services companies are shelling out for are either not used at all or are relied on to a fault.

Reply

[-]

ur_fault@reddit

you can swap them out, but you’ll just get more juniors doing the same thing. LLMs aren’t going anywhere and everyone will be using them. LLMs aren't the problem though... the real issue is that no one is teaching these juniors how to use them effectively. set some clear rules. most of them don’t know what they’re missing or how bad their habits are. they’re not being lazy on purpose, a lot of them are just trying to keep up with their co-workers and whatever they imagine everyone else is doing. they don't know any better. best approach (especially if you aren't AI coding regularly) is to figure out which seniors are actually using LLMs well and work with them to come up with some basic do’s and don’ts. once that’s in place, give it some time. the ones who improve are worth keeping. the ones who don’t, aren’t. but right now, without giving them any guidance, you can’t tell the difference.

Reply

[-]

compubomb@reddit

Which AI product are they using? If it's cursor, you should establish a standard ruleset that cursor uses ahead of any tasks they ask of it, this may help reduce some of the garbage that the LLM tooling can introduce when it doesn't take into account the complexities of existing projects. Also making new greenfield projects should have an established structural base ruleset.

Reply

[-]

summerloverrrr@reddit

Hire me sir

Reply

[-]

_MovieClip@reddit

Juniors are mostly potential. If they are not learning then that defeats the purpose of hiring a junior because they will never progress beyond the knowledge they have now.

Reply

[-]

jatmous@reddit

This is barely a question. Most shops already did this: \> Should I get rid of juniors

Reply

[-]

g1ldedsteel@reddit

Sounds like there’s an opportunity to coach your juniors on how to map problem spaces before just asking Claude to do so.

Reply

[-]

nath1as@reddit

the issue is never with juniors, they are juniors for a reason

Reply

[-]

MrDilbert@reddit

THere's a reason they're juniors - they don't know much. But having the AI as a tool in their toolbox makes them feel like they do. Take them on 1:1 meeting, explain how the things are, and that their output is unsatisfactory (and yes, as a junior I was also "speed over quality" until I learned better). See if they're willing to learn and get better in understanding what the AI tool wrote and realizing that someone else will have to maintain that code after they're not working on it anymore. After the talk give them a probation period (your call, could be a week, a month, 3 months, w/e), if they don't show signs of improving and listening to your feedback, recommend them to be let go. If they DO listen and get better, you will have a strong addition to your team, which might stay with your company, and you won't have to waste time searching for an already realized engineer - which can be a crapshoot as well - while your (reduced) team is gasping for air under the weight of tasks.

Reply

[-]

GiantsFan2645@reddit

Invest more in training/mentorship. Have KT on all parts of your system. Look at where documentation can be updated/improved or created. Show these juniors how to use AI to enhance their work, stressing the pitfalls of misuse

Reply

[-]

davearneson@reddit

AI is good at explaining what code for and refactoring code to meet coding standards. Can your seniors help your juniors use AI to do that?

Reply

[-]

Dry_Atmosphere_8029@reddit

Dear god. As long your code gets done stop crying

Reply

[-]

TeeeeeFarmer@reddit

Try everything - cut one, train few & see how it works.

Reply

[-]

GeekH4x@reddit

Your first step should be to ask yourself why you don't like them doing an action that bothers you. Your second step should be to ask yourself (and them) why they do that action. Your third step should be to mentor them and help them learn to stop doing that thing. Only then should you start thinking about getting rid of them. You asked the mid/seniors to recently start pairing? What was happening before that? Maybe they felt the mid/seniors were unapproachable before, and they learned habits such as asking chatgpt for help as a way to get past blocks. You should first try to explain to them that they should think through the problem and consult other members of the team before resorting to asking chatgpt if that's what you want. Juniors always have generally poor quality code that needs refinement from more senior developers (often through code reviews etc.). So that's kind of what you should expect from juniors, and I've often heard that at least for the first year you should expect negative overall value. A $70k Junior probably isn't producing 70k worth of value in their first year. As for should you stop hiring juniors and only hire more experienced developers? If you want to, that's definitely a solution. Plenty of larger companies do this (Netflix I think?) and certainly very small and lean companies as well. Mentoring isn't for everyone, and your ROI will definitely lag by a couple years when hiring juniors. Personally, I think teams are more enjoyable with a few juniors, it feels nice to be able to share your experience and help someone learn.

Reply

[-]

VanillaCandid3466@reddit

Hmm ... Crack out some firewall rules and block all the offending AI sites/APIs and see what happens? Lock down the Git dev branch and force pull requests with detailed comments? Get the juniors to talk through the code in their PR as prerequisite to it being merged.

Reply

[-]

dutchman76@reddit

My class mates used to do the same thing in college, when they'd get stuck, they would get someone else to fix it for them without understanding or learning anything. I'm not surprised

Reply

[-]

thatbobdl@reddit

That’s a real problem we experience as well. What helped (a little) is to make clear explanation what is expected from the junior engineers. Workshops on how to do debugging/problem solving, etc. But in reality, you can’t control what they use, but you can advise and mentor them. If their output doesn’t become better - yeah, I’d put in an improvement plan.. If it does become better, then I guess it’s a way. Not sure if this way would allow them to grow though, but it’s a different story.

Reply

[-]

Jmc_da_boss@reddit

Simple answer: yes

Reply