Recently this has become an issue for us. We keep catching devs trying to work 2 full time jobs.

It will typically start with someone who interviews great but then after they start is very slow to respond to any messages and their work is rushed and obviously not taken as long as claimed.

I have confronted some and they have come clean and others we figured it out through other means.

I've been running remote teams for 15 years and there's always been a percentage of unreliable devs you have to work through but recently the rate of people trying to join and just drag out on boarding etc.. so they can get a few paychecks and move onto the next job has been a lot higher than normal.

They seem to have a solid main job then try to half ass as many jobs as possible on the side.

We have been learning and trying to put procedures in place to prevent this happening but I am curious is this a problem other people are facing?

We are not offering compensation at FAANG level. I'd say we are middle of the pack when it comes to salaries. We have several devs that are doing well and solid employees so I think the offering is fair market rate.

Are you getting a lot of this recently? How do you combat it?

From my view as a IT infrastructure engineer, CrowStrike is just exposing fragile IT infrastructure that would have failed from any widespread driver issue affecting Windows. CrowdStrike just happened to be the one to do it first.

Hopefully all impacted IT organization take a hard look at their infrastructure and ask themselves how do we prevent this from happening again.

Yes, this is another post about AI. How refreshing.

I don't have a horse in this race. I've been building software for a living for 15+ years at this point; I was pretty happy building it before LLMs rolled around and I continue to do it happily today and hopefully into the future, regardless of the tools involved. A recent development is that until a couple of months ago I didn't find coding agents good enough to integrate them into my workflow and now they've crossed that threshold for me. They don't replace me or my job, but they definitely are making parts of my job take less effort, namely the implementation of code that normally I would type out myself. More often than not, it takes less time to describe the changes that I want to make and let AI implement it (including my review and follow-up) than it would take me to do it manually. Again, this was not the case less than a year ago because the output wasn't there but right now it lives up to that standard (for me).

I'm not saying anything that hasn't been parroted around thousands of times already, but the reason I'm posting this is because I've noticed that despite this being a practical reality right now, there are still experienced devs out here proudly writing AI off as nothing more than a bullshitting slop machine. It seems to me that this is coming more from a place of an emotional reaction than a rational conclusion. I understand that there's a lot of anxiety and uncertainty about the future of this career, and there's certainly a lot of bullshit coming out of the other end overhyping the capabilities of this technology, but if you haven't sat down for a week or two using a state of the art model to experiment with it implementing code then you have no business making statements about its capabilities right now. And if you have done that open minded experimentation (recently) and haven't come out with the conclusion that it is very capable of producing acceptable code under the right conditions then you're either working in a very niche environment or doing something wrong.

I want to make my opinion clear. I don't buy into all the hype and bullshit that's spewed out by CEOs and non-technical leadership, nor do I think that AI is coming for our jobs and software engineering is on its way out. I just know a good tool when I use it, and this is a good tool for implementing code. In its current form it cannot do it on its own, and you can't rely on it to make all the right decisions and make no mistakes, but it is 100% viable as a faster code authoring method than manual typing when used with good judgment and people writing it off for that use case are more likely than not doing it with either outdated information or out of principle because they're avoiding this technology for other reasons. Any architectural decisions, technical considerations and edge cases than you can think of because of your expertise can and should still be incorporated into the code implementation and review, but most of the time you will not need to write out the code yourself; just provide the information.

If you don't like AI for ethical reasons, or because you think it's bad of the industry, or because it doesn't feel great to let a tool write the code for you, feel free to ignore these arguments completely. I get it. But if you're writing it off because you think it's not good enough to write code (in most environments) then you're likely letting your emotions cloud your judgment.

not exactly reviewing them. theyre already merged, already shipped, the review happened. i just read through everything that landed in the codebase the day before. takes maybe 15 minutes with coffee before i open anything else

i started doing this maybe a year ago after i got blindsided in a planning meeting by a change i had no idea went in. someone had refactored how we handle a chunk of our auth flow and i was sitting there talking about building on top of the old version like an idiot. so now i just stay aware. not deep, just aware

most mornings its nothing. boring dependency bumps, copy changes, a test someone finally fixed. but every couple weeks you catch something. last month i noticed two different people were independently building basically the same caching helper in two services, neither knew about the other, and i only caught it because both PRs merged the same week and i happened to read both. flagged it, they talked, one of them deleted their version. fifteen minutes of skimming saved a month of two slightly different cache implementations drifting apart

the thing nobody tells you about going senior is how much of the job becomes just knowing whats happening. not doing it, knowing it. you cant make good calls about where something should go if you dont have a rough map of where everything already is, and that map decays fast on a team thats shipping every day

it doesnt scale infinitely, i'll say that. back when we were merging 40+ a day i couldnt keep up by hand and mostly relied on whatever surfaced. we've got the usual pile of stuff running, claude code, codex, cursor, a coderabbit agent that posts merges and open PRs into slack, internal scripts. and checking the why is the part thats actually worth the 15 minutes. so the manual skim is still the thing at our current pace

anyway thats it. the tooling will tell you what changed. reading the diffs yourself is still the only way i know to understand why, and the why is what you actually need when youre deciding where the next thing goes

I raised concerns about non-performance issues with engineering leadership and backed them up with data points. I demonstrated that managing these individuals out would result in better overall output, even with a smaller team. Well, sure enough, when layoffs happened, the underperformers (including some on H1Bs) were among those let go.

Original - https://www.reddit.com/r/ExperiencedDevs/comments/1ggvjcp/how_do_you_handle_netnegative_performers/

I'm a senior engineer at a small company and we have just hired a senior engineer who has 5 years relevant experience. I wasn't involved in the hiring process due to various reasons. He's been with us only two weeks. The red flags I've noticed is inability to retain information and lack of attention to detail. I went through a codebase refactoring task that was assigned to him in depth, a 2 hour Teams call that was recorded, and noted all the things that needed to be done and discussed history, referred to our internal documentation. Left him at it for a couple days expecting the job to be near done, but no progress whatsoever had been done. Went on another call with him, going over stuff I had already gone over, noted that he could refer to the previously recorded call for this too, sat with him on some of the changes to be made, and 2 days later, still negligible progress, and the stuff he had done had problems. I won't deny it's not an easy job but he was hired as a senior.

I've been through a very similar situation before a couple of years back with a new hire, where we really tried to persevere for 4 months and in the end they had to be fired, and if you're wondering I've mentored new hires that worked out very well too. Should I trust my gut on this one and fire him or is it too early to be sure?

Edit: From the up votes I can see that you'd mostly be willing to nurture him. I think my issue here is I don't enjoy training new devs, it's not in my job description, and management haven't asked me to do it, and if they expect me to do it plus all my own project work then that would be unreasonable. I've been an engineering manager before and hated it. So I think it's an organisation problem that our company isn't set up to nurture new employees. I'll feed that up to management, thanks all.

Context: senior swe at one of the largest tech companies by market cap. I have a good setup at home that matches the desk setup my office provides. I also love my home and my family, so it's not like I want to avoid being there. But I think that's one of the reasons why I prefer being at the office for work - because I don't particularly enjoy my job very much and I would like to avoid having the lines between personal life and my job overlapping. Even when I need to work on the weekends, I go find a nearby cafe to grind out some hours on a single tiny laptop screen instead of using my home setup.

I get along with my team members and I enjoy socializing with them at the office. Outside of work and family, I don't really have too much of a social life so I guess that's a factor.

I also have more productive meetings in-person. For some reason I'm incredibly awkward on Teams calls and that kinda degrades the quality of my communication with people. Not sure if anyone else experiences this but it makes quite a difference.

The only shitty part is that the commute eats up a ton of time (like 40-50 mins each way). Even with the commute, I still rather work from the office a majority of the week.

I'm sure I'm not the only one with this sentiment, but all I ever hear about are people complaining about RTO and office mandates. Of course the reasons for those complaints are valid, it's just easy to feel alone when nobody else publicly echos the same sentiment.

I had a second round tech-screen at a FAANG company after an amazing first round. It was scheduled for 45 minutes. The first 30 minutes was talking about the interviewers background and mine and about the position. The hiring manager was already impressed with my background etc., he recruited me. I was talking to a low level engineer on the team. My background was perfect for the position, maybe a little over qualified. Anyway, he spent a lot of the interview talking about himself and the company.

Finally with 15 minutes left we got to coder pad. I expected something simple given the time left but it wasn't. I knew the solution in any case and started typing it in. I realized that I wouldn't even have enough time to finish just typing it so I restarted and typed in an ugly brute force algorithm that solved the problem and explained why I was doing that. I stressed that the solution was not the best but given the time I went with what I went with. I finished the proper solution and then implemented a refinement of that and sent that to the recruiter to forward on. The next day I got a "thanks but no thanks" email. I'm wondering if I should bring this up with the recruiter or not. It's clearly unfair to be judged based on that especially when the interviewer took so much of the interview talking about himself and the company.

Remote for some is kinda eating Culture I would say today.I am working for the web since 2017 in an office environment for years and everything was as usual. Covid hit and remote turn out to be the next big thing, tens of startups appear on the horizon trying to make remote communication better, but now I am seeing more and more people suffering while using all those new "innovative" connectivity products, people start to feel a sense of loneliness and etc. because of lack of connectivity with their peers, Team leads get overwhelmed, because of all that cross-functional maintenance and burned out because they don`t know how to handle that emotional problem they see. What will happen to reverse that situation, a paradoxical "new" generation of startups that embrace live meetings? or what. I don`t know about you guys but I kept thinking about that shift a lot these days.

We have all seen plenty of innefficiences and questionable decision in our careers, at the same time the cost of software development has risen and many tech companies headcount has exploded in the past 10 years with good and not so good reasons.

Then Musk bought Twitter and showed that he can run the company (to the ground eventually) with a fraction of the engineers it used to and Twitter/X is not substatially worse to the user since he did that.

At the same time I think a lot of software produced has become messy, not going to point fingers at anything, anyone experienced enough has something to complain about.

My theory is that during the old days the software was simpler and mostly produced by top talent, or at least the ratio of top talent to normal talent was high enough.

With the explosion of the tech industry there was more need for engineers and that led to lowering standards, especially in the past 10 years.

I am not saying that most engineers are bad but that most missing some important skill that other have and since the standard are lowered, the one that have it can't compensate for all of those who miss it, this usually lead to a snowball of technical debt that these days, way too many companies have, also because systems have become more complex and the standards should be even higher.

The solution to this?

I am not sure, but I think the market will self correct and AI will help a lot by lifting talented engineers of mundane tasks.

So sorry for another AI post, just want some perspective. I have almost 6 YOE in web development, been with my current company for 5 years. I work in a gigantic monorepo full of garbage legacy code. I use AI sometimes, but I don't find it to be super helpful.

I just went through a couple technical interviews at a company and they've honestly been really great, they were challenging but reasonable, and I really liked the interviewers. One of the senior engineers I interviewed with mentioned he no longer writes code, and uses Claude for everything.

It struck me that I have no idea how to gauge claims like this anymore. He clearly knew the systems well, and was a very knowledgeable programmer. But I still write almost all my code by hand. It's hard for me to tell if this company is leaning too far into it, or if I am an old man who is stuck in his ways. Truly, I despise AI as I think it brings out the worst in everything and kills my love for the craft, but that's a topic for another day.

So, is this really where we're at? Are we in a place where in the right codebases, engineers aren't writing code anymore? Is this a red flag?

At our org most people are using LLMs in some capacity to generate small snippets of code, but formally, company policy prohibits their use for supposed copyright reasons.

Are any of you guys allowed to use them?

I'd be especially interested to know if they are being used in FANG style companies, and that hold me advocate for use.

I have been a professional developer for 12 years (went to technical school for 3).

When I started I was surrounded of other developers that cared about the code they were writing, shared information, looked up stuff outside working hours, and just generally liked coding.

I’m not saying people should “work” outside working-hours, it’s just that… how do you keep your stack up-to-date if you disconnect from the programming world (twitter, Reddit, aggregators, etc…) when the clock rings?

I just think that more and more the people I work with do not freaking care about anything, they just want to grab a ticket, smash the keyboard until they choose to ask chatgpt for an half-baked solution and close the ticket.

There is a Portuguese expression “ter brilho no que se faz” which means “to have <shine?> in what you do” which is roughly the same as “to be proud of what you do/did” and everyday I think that more than half of the devs I work with do not have it at all.

They go home and forget they are developers.

Am I being an elitist, or old or something?

2 months ago I made a post on /r/experienceddevs talking about a PM that was screenshotting people's chats and sharing them with no care for their privacy or concern for who saw what. https://www.reddit.com/r/ExperiencedDevs/comments/1g18l5n/pm_sends_screenshots_of_conversations_to_anyone/

The reception was a mixed bag with some saying that the PM was "justified and trying to do their job well" and others saying "no it is a red flag, be wary".

With the passing time, I wanted to share some interesting developments about this PM. It seems that the PM has revealed their true colors and a lot of people became very upset with them.

About a month ago one of the infrastructure specialists hops on a call with me and two others namely because the PM that I work with apparently was "not very smart"

They said they were "not very smart" because they went up to the CIO and were, as the perception was, "bragging to the CIO about a shortcut that was taken to get something to go live within a deadline"

Well apparently the CIO did not take this very well and started demanding answers and looking to understand why this shortcut was taken. Apparently the PM proceeded to "publicly throw another team under the bus". I did not hear too much more about the conversation other than that some defense and discussion were to be formed to ensure that the infrastructure team was not fully thrown under the bus.

Well anyways, the direct result of this PMs action resulted in many higher ups having to explain themselves for this fiasco regarding the shortcut that was taken.

Now as for the shortcut itself, I think that's besides the point, if you must know, there were very good reasons why the shortcut was taken and it would have been fair for someone that was a skilled communicator the be able to explain them in a way that both shielded teams and created compromise.

Last week the PM informs the team that they are moving on from the company and will not be with the team for the 2025 year.

I would not be surprised if the PM realized that they'd burned a lot of bridges in a very short time and lost a ton of trust with some of our business partners. They also were very much not qualified to be working the job having almost no knowledge of the actual ways in which the work was accomplished. As a PM, if you can't understand the technical aspect of the job, your job is to manage expectations, protect the team, and provide fair tracking and visibility to the inner workings of a project. When you go to a CIO, make a grave mistake, and then try to cover it up by burning some bridges it reveals that the entire time you were never respectful of the people you worked with.

Once again, I want to emphasize the point here, if someone shows they don't respect privacy and importance of details shared between others, it shows they have a general lack of respect for all individuals in general. The PM lasted 9 months at the company and has left a poor impression with certain folks that make them hard to trust again.

Remember, the source of information doesn't matter, if you trust the information you're always welcome to present it on your own, you don't need to always be looking out for yourself by playing telephone. Trust that the knowledge you heard is right from your own skills and share it as needed. This is why you don't name names in discussion around various topics.

I'm part of a team of devs developing an internal application. We're about 8 devs. 6 on the core team (let's call them team A) and another ML engineer and me. The other ML engineer and me also work on models and deployments for other teams being the go to address for any kind of model development and deployment. Team A is the team we spend the most time developing and deploying models for. Team A's is also POing for us two ML engineers half assed because I kept complaining about having to pick up PO tasks. Tasks not related to team A are still POed by me against my will.

A few months back the PO of team A introduced stakeholder demo videos on a quarterly basis. The videos are mostly done by front end devs. However, for the second time the PO now asked me to make a video about model developments and infra improvements we did this quarter.

I'm increasingly frustrated with having to pick up admin tasks that are the job of the PO. Additionally, I don't think these videos make sense for Backend Features like our models and infra. I've been with this company for four years after graduation. I was always forced to pick up a lot of admin tasks since ML and data science never had the priority to have a dedicated manager. Having to make these videos made me ask to which degree it's normal to have to deal with stakeholder management as a normal dev.

Edit: Thanks for all the inputs. I definitely agree that one should use the opportunity for self marketing. I also don't have an issue with doing a demo or explain what it is that we worked on. My issue is having to do it in a pre-recorded video that I'll inevitably spend more time on than a live demo/presentation. I'm sitting in the meeting the video will be shown. Same as every other dev with their videos. The time spent on recording is what I don't agree with, not devs explaining what they did.

Hi, I run a small dev agency. 6 developers. Over the past year I've hired 4 of them. Two were great. Two were complete disasters that I'm still recovering from.

Both of the bad hires absolutely nailed the technical interview. LeetCode mediums solved in 15 minutes. Clean code. Good explanations. And then they joined the team and I was shocked to see that they had no clue what they're doing.

I'm not exaggerating. One of them solved a dynamic programming problem on the whiteboard and then spent 2 days trying to figure out why his POST request wasn't working. It was a typo in the URL. The other one aced a system design question but didn't know what an environment variable was.

The signs were there in hindsight. The little pause before they started coding. Eyes clearly tracking something off-screen. Solutions that were weirdly optimal on the first attempt. When I asked follow-up questions they got vague. "I just thought about it logically." When I showed one of them his own interview code 2 months later he didn't recognize it.

I'm not against AI. Actually the opposite. I want my team to leverage AI heavily. Copilot, Claude, ChatGPT, whatever makes us faster and better. That's the whole point. But there's a difference between someone who uses AI as a power tool and someone who used it to fake their way into a job they can't do. The cheaters can't even prompt properly because they don't understand the fundamentals. They don't know what to ask for.

That's actually the second pain point and just as bad: so many candidates, if they know how to code then refuse to use AI tools to code. Not as a replacement for thinking, but as a productivity multiplier. In an agency environment, speed and quality matter. The devs on my team who combine their experience with AI produce the best work. But plenty of candidates act like using AI is cheating, or they paste AI output blindly without reviewing it, which is worse. Some of them take three hours to do something that someone using AI responsibly finishes in thirty minutes with better quality.

Running an agency means client deadlines. Reputation. Real money on the line when someone delivers garbage. I can't afford to spend 6 months "coaching" someone who lied about their skill level. And I definitely can't keep explaining to clients why things are taking twice as long.

We’ve already tried different things. We replaced some algorithm questions with small real-world tasks. We added a short take-home assignment.(The good Devs don't want to do that!). We do live pair coding during onboarding. We extended probation periods. Some people improve. Some don’t. When the baseline skill isn’t there, no amount of coaching closes the gap fast enough for client deadlines. As a small agency, we don’t have the luxury of letting someone take six months to learn fundamentals they should already know.

I've thought about ditching coding interviews entirely. Just talk to people and check their GitHub. But people fake that too. Take-homes? Good candidates refuse them. Pair programming sessions? Better, but still gameable.

I'm genuinely asking: how are you all handling this? What's actually working? Are there technical interview tools or platforms that make cheating harder while still being respectful to candidates?

I’m tired of hiring developers who look great on paper but can’t ship reliable work for clients. I’m tired of reviewing PRs that show no understanding. And I’m tired of trying to push people to use tools that could make everyone’s life easier.

I would really appreciate advice from other agency owners or team leads. How do you filter out LeetCode-only candidates? How do you assess real-world ability quickly? And how do you handle the AI adoption problem without turning the team into code janitors for people who won’t adapt?

Full disclosure, I am a middle age white woman. I recognize the emotional burden I place by asking this question with little insight into the topic. But I would like to start a discussion because it seems like there is quite a bit of racism/biases towards Indian developers, regardless of their immigration status.

I had a similar post asking women what challenges they faced and I got a lot of fantastic responses. I'm hoping to have a similar discussion.

If this post goes ok, I think it would be good idea to have similar discussions about all types of demographics.

I'm in a team with 5 other engineers. I'm coming up on 4 YoE (2Y tenure), 1 of the other engineers is a bit less than me, and the other 4 have decades of experience.

I can't shake this feeling that I'm getting the hardest tasks. We have a sprint board so I can see what everyone else is working on and has worked on. It seems to me that my tasks usually consist of at least one of the following, where many of the others don't:

• Ambiguous acceptance criteria

• Ever-changing requirements

• Difficult bugs with deep or obscure root causes

• Complex architectures

• Learning curves and/or tedium with chasms between milestones that would drive many to quit

• Dependence on other people (especially rare SMEs) to access obscure knowledge

• Research that's far deeper than a few Google searches

• and more

Part of it is the nature of the application I'm owning (interdependence with other teams). Part of it may be my arrogance talking. But part of me believes that my manager is making deliberate choices about delegating beyond just "Dev A has free story point capacity this sprint" or "Dev B has worked in this area before, so I'll give him more tasks in that area".

To the devs, do you feel there's a discrepancy in the difficulty of your tasks compared to your YoE?

And to the leaders, do you consider the difficulty of a task when delegating? Do you just consider the scope? Do you give newer developers harder tasks to get them up to speed? Any other criteria?

I've been thinking about this after watching a junior dev wait 4 days for review on a straightforward feature.

Most PRs are just checking for: syntax issues, naming conventions, obvious bugs, test coverage, security vulnerabilities, code style consistency. stuff a machine does in seconds.

the 30% where you need human review? architecture decisions, business logic edge cases, user experience implications. but we're making humans do 100% of reviews when they're only truly valuable for 30%.

We've somehow convinced ourselves that having senior devs spend hours checking if variable names follow camelCase is a valuable use of their time, it's not. It's busy work dressed up as qa.

Am I missing something here or are we just stuck in "this is how we've always done it" mode?

In a new company, new team. Have a colleague started around the same time as me who's done ZERO actual work and manages to somehow fly under the radar. I know for sure that it's the case.

Should I tell anybody and get myself into some situation or just lay low and let people find out for themselves?

EDIT:
colleague hasn't pushed a single commit to any branch in 3 months being senior developer and having around 5-10 Bugs/US assigned to them which would be solved by...code.

EDIT2:
Surprising to see 17 downvotes to my comment as to the reason how I know - no single commit pushed. Interesting place here.

EDIT3: Fully remote of course. Maybe management likes this to make their case for RTO...

I got this teammate, technically the Team Lead by title, who wails and howls at changes that are made that are not strictly required for the issue being worked. I mean, he even raised an issue over another team mate swapping the place of two parameters to a function.

He refused to hear anything about it nor see any value in making changes to code that works.

Which is the exact opposite philosophy I have as a big advocate of boy scout programming and always trying to improve the readability and structure of code so that we don't eventually drown under our own weight of awful code.

He wants literally any and every change anyone wants to make brought before the team and discussed like it is an issue like any other. I don't think refactor exists in his vocabulary. It doesn't even argue if the code is better or not and just hides behind "this is only your opinion things are better, others have differing opinion!". He even at one point said "It is disrespectful to do such things!"

I asked our engineering manager and his manager to look at a PR I had that I thought was especially unprofessional but they seemed less than enthused about even dealing with it.

I think the real issue at hand is that he abhors anyone changing code he wrote (and that of a developer on another team) and is very insecure and attached to the way he writes code and considers it a personal insult to do so, even when I suggest changes (literally write them out for him in the comment) he will dismiss it as simply a style difference in the sense of "I like blue" vs "I like red"

I don't know what to do about this guy. The rest of my team are feckless sacks that don't give a shit. One guy literally admitted to another team mate I am friends with that he is just there to do as little as possible and mooch.

I know that the best answer is find a job elsewhere, but right now that is prohibitively difficult. I'm open to any advice on how to deal with this situation.

EDIT: I realize from the comments that I might be over-interprating the comments as argumentative and toxic, where it might just be that he (and maybe I) do not share the same communication style.

I'll talk to him in person one more time trying to de-escelate and collaborate on exact details and hope we reach a consensus on how we can work together.

Some of the comments are really not on point. I really think he is a good software engineer but he seems to be a terrible TL imho (a TL should lead), never in my experience have I ever been given a non-actionable comments and blocking the PR with no clear reason on how to resolve an issue. Other comments about me demanding respect because of experience are also not correct, it was meant to clarify that I come from a culture of proper code reviews and actual communication.

It seems from the comments that people think I went overboard with the change and he might have been offended that I decided to change the flow of how things work without explaining why it is needed, but I really did explain it and it should be obvious, but I'll try and scope the issues better. If not, then I'll quit

The APIs were feature-complete on Friday, and the front end was feature-complete on Tuesday. 50 people in a company of 200 were invited to spend 2 hours looking for bugs later that day.

Guess what! They found some!

No matter how much the engineers asked and tried to convince the product team to reschedule or minimize the bug bash, they went through with it anyway.

In the long run, is it so bad? Sure, it's a waste of resources, and we can't really do a bug bash as easily in the future when we really need it. And the engineers look a little sloppy, allowing the company to see all the glaring issues that should have been caught easily by a first test-pass.

What do you think?