r/ExperiencedDevs

I am in the industry for 5 years and I never was a top developer. I somehow survived a CS degree (in which I wasn't top or even average as well) and it never was my "true passion". But it was fine as the industry was flooded with people like me and we all managed to stay in the loop. The pay is great, the offices are nice and the flexibility to work from home is def addicting. But maybe it’s all a golden cage?

With the AI revolution I really enjoyed the fact that I didn't need to write code anymore and just focus on architecture.
But somehow it became even worse since my job shifted from writing code to code reviewing tons of garbage written by AI and I really hate it.

But what really is bothering me and is causing quite some anxiety is the fact that the market is shrinking and when this happens the strongest survive. I am definitely not a top dev in my company and I don’t know how long will I survive and what will be my chances to land a new job, since the interviews are absolutely brutal now and there are thousands of applicants per opening.

Basically I am thinking how to future proof my career and maybe even do something more interesting. Also I feel it’s not healthy to do something you are not passionate about and really great at.

Any thoughts? Are there people who feel like me?

This is something I've been thinking of lately, what are the benefits between going in-house vs outsourcing all your data processes to a third-party provider like Definite and others.

From what I was reading the only reason was to cut cost of running a data eng team, but are there other reasons.

Like what are the main reasons/motivations/benefit of outsourcing everything, a part from cutting cost ?

I'm trying to evaluate both options.

(sorry I'm not an expert in this)

I work as an SDET and have seen a number of AI tools cross my desk heralded as the second coming of christ.

A staggering number of these tools are around "automated regression". Giving some kind of prompt to an agent to reason with an image, or data, and have it answer questions. Has something changed? Has something broken? Do you see X?

To me, determinism is the single most important thing about doing regression. If I can't guarantee my inputs and outputs, what the hell is the point?

But, slap AI on the tool and management will tell you quickly, "use it".

Recently a new PQA lead(Process Quality Assurance lead) (I didn’t even know such roles existed) joined our team , they also participate with a bunch of other teams .Recently during an estimation call, they asked all the Frontend members of team to estimate Backend work. The FE devs are purely FE and the stories are purely BE .

Has this been a common practice in your organisation or is this some bs that I’ll have to just deal with ?

I noticed that in my career (several companies of every size and different industries) the only thing they have done is to show up n times per week for the scrum meeting, chasing people for (a poorly configured) Jira burocracy and nothing else.

What else they do? How many teams they follow in your company? have they ever been actually useful and if they are not why?

My first experiences with development, more than 10 years ago, has been as simple as creating plugins for Wordpress.

Nothing revolutionary, for example table reservation system for a restaurant, an interactive map for locals of a franchise, small things that made you plan and learn new stuff, aside development, on how business work and it needs.

After some time other types of requirements appeared, data management (learning about stored procedures was a pain), asynchronous functions, errors prevention, integrations with sharepoint and other third party systems which not necessarily rely on APIs.

Fastforwarding to current days, I feel like with all the Frameworks, AWS components, even AI getting answers in miliseconds, all of the “fun” of development and learning is totally gone, and I feel the 9to5 became a survival on pleasing management rather than showing your capabilities and problem solving skills.

Actually the problem solving part, I feel is not valuable anymore, as we don’t solve anything. at all, just slap new features so the stakeholders see a company as a potential investment.

Also with the “ship as fast as possible” mentality, we dont really pause and appreciate the outcome of the code, becuase time not invested in a new development is lost time.

I just want to confirm it’s just not me, that development nowadays has nothing to do with the oldschool ways of working, and we probably will never get back that “feeling” of overcoming ourselves.

As always, have a good one!

For those who have been on possibly dying teams and/or failed projects what were the biggest indicators you noticed?

Current team leadership is trying to recruit me to stay. I put our survival at 5-10%. I’m just trying to gauge if that 5-10% is correct and be able to judge not riding the ship down.

Were you ever in a position like this and stuck it out only to watch the team beat the odds? What did it take?

I got into this because I enjoy the deep work. At this level (senior, shooting for staff) I don't think there's any left for me to do. Everything is easy but it's all happening at the same fucking time.

Kube charts are broken because of SA permissions on our secret store. If I change and push this enough times it will work. DB schema needs a tiny change. Easy, push it and open PR. Feedback on another PR, all easy stuff, correct it, push it, the DB schema PR is finished building, I got tagged in a design thread but the discussion is already moving on without me, more PR feedback, address it, commit, push, the kube charts thing failed CI again and I need to change/commit/push it, that design thread is going off and I have to say something or it'll look like I'm checked out, I forgot about the schema change PR and it finished building half an hour ago and I could've queued for the QA environment but now it's backed up, there's three PRs waiting for my review so I can use the time to oh, wait, no, C-suite is wading into eng channels and I gotta make sure I'm seen, design thread is going off again, kube charts failed and honestly I'm not sure if this will just work on enough pushes and maybe I have to tag in delivery tooling and god knows when they'll get back to me but at least the QA environment is unblocked oh shit that was twenty minutes ago and there's people waiting behind me and my deploy failed anyway and it'll take five minutes to rebuild and now there's a meeting for somebody else's project that's blocking mine that I need to be in (mostly to be seen) and the fucking DB schema thing never actually got QA'd it's just been *sitting* there

I'm not good at this. I've gotten better at it, but I still suck at it. I want to delegate it to someone else, but if I did I'm not sure what I'd even do all day. All this bullshit is what my project needs most right now.

Hello everyone,

Just a rant about AI peer pressure.

So, working in a big tech company, our main goal for this term is to "use AI". We have access to almost every model and every tool in the market with crazy quotas. Soo, I use it. A lot. For coding.

My work is now to wait in front of my computer for 70% of my day, the remaining 30% are meetings.

We're supposed to use it for everything. So, to meet KPIs, my colleagues are starting to use it for everything. Every PR description is AI slop, they create "slides" about "how to use AI efficiently for [you name it]". Always low effort as fuck. When you ask questions about the content, most of the time they haven't even really read it.

And that's "okay". I don't really give a fuck, our project is quite shitty already, so why not. Everyone thinks that it's kinda shit, but everyone does it anyway. I will start to create all this low effort content as well, as I want to meet KPIs and get my bag.

But, yesterday I was talking with some colleagues about personal projects. And they where like "what?! You don't have a 200$ Claude subscription for personal projects?!". And to me, that's crazy. Personal projects are supposed to be to do something fun or sharpen our skills, right? Why would you want to improve your productivity regarding that? And paying 200$/m to do so?! And it's not the first time, everyone at work and some of my friends are baffled that I do not pay for that to use on my free time. And the pressure is building.

Anyway, idk where all this shit is going. We produce 10x the software for 1.5x the features, and people wants to start to do that on their personal time. They don't do web research anymore, and just take what's out of Claude/ChatGPT as truths.

Maybe it's not for me anymore? I have an electrician/network technician vocational school degree, should I switch to that?

For a while my method of taking and organising personal notes has been pretty chaotic. Mostly it consists of a bunch of badly-named text files open inside Notepad++, which aren't organised at all, aren't saved properly and aren't backed up. I hit 100 individual files recently at which point I realised I should probably change something.

I'm not talking about 'proper' documentation - that goes in a wiki, and is readable for everyone. But web-based wiki editing is slow and clunky (compared to just scribbling in an open text window). This is more for personal notes that come up during development ("remember to deal with X edge case", "consider refactoring Y", "Z looks like a bug"), most is for short term attention (say, this week) but some will be lower priority and get put on the mental backlog. But without proper organisation they tend to slip into the void.

I've also replaced my paper notebook with a Kindle Scribe, which is great but again it's not very good at organising/cross referencing/searching. And a long time ago I used OneNote on a tablet, but I have no idea if it's still decent and I'm not keen on getting a 356 subscription just for that.

It feels like there should be something between the heaviness of a wiki and the raw chaos of text files. What do you lot use? Thanks.

I’ve noticed it can take me a while to review PRs. 2-3 PRs of about 10 files and maybe 500-1000 lines each can blow out 2-3 hours of my morning easily. I’m on a team of 5 engineers, myself included. I find I leave the most comments; more than anyone else on my team by a good margin. Mostly questions (40%-60%), suggestions (20-40%), and issues (0-5%).

Here’s my process:

1. Read the ticket to understand the work that’s supposed to be done
2. Read the PR line by line keeping an eye on certain things I care about
3. - is it clean architecturally?
4. - is the state being managed responsibly? Unreachable code? Missing null handling? Checking conditions that aren’t possible?
5. - do the unit tests actually test all the cases it should or are we just going for green check marks?
6. If my feedback isn’t going to change too much logic, I pull down the branch and test the code. Checking the AC and then playing around with edge cases to see if I can find something

3b. If my feedback is substantial enough that I feel it’s not ready yet for testing, I’ll wait for author and re-review when the time comes

The majority of my comments are questions that have spawned from me about to make a suggestion, but I don’t want to make an assumption so I always ask the author in case there’s something I’m missing
Instead of “this condition is unreachable, we can kill it” I ask “What scenarios do we expect the user to hit this condition?”

If I do make a suggestion or raise an issue, I won’t just say “change this”, I’ll jump into the code myself and pull references from our codebase to bring a solution to the table
“This can be improved if we follow a similar pattern in the code block below”

I pride myself in being very thorough on reviews; it’s one of my favorite parts of the job but I worry I spend too long on reviews; my coworkers are quicker to review, but leave less comments.

How do others perform their reviews? What can I practice to become better while maintaining quality?

My experience is heavily in Nodejs but I always get asked how well I know Java/C#. Obviously I am not an expert in Java or C# but we all know it’s not that difficult to transition to a different language/framework. When you’re interviewing a candidate, how much does their specific stack matter?

Not talking about new grads or people who’ve been job hopping every 2 years and staying sharp. I mean the engineers who landed a solid role around 2017–2019, put their head down, shipped real products for 5–7 years, and then got caught in the post-boom layoffs.
These people built actual systems. They’ve debugged production outages at 2am, mentored junior devs, navigated legacy codebases that would make most people quit on day one. And now they’re sitting across from a 25-year-old asking them to implement a segment tree under time pressure on a shared screen.
A few things have genuinely changed since the last time a lot of these folks interviewed:
The bar shifted. A senior engineer who interviewed at Google in both 2021 and 2024 noted that LeetCode Hard problems — which he assumed were never asked — have now become the norm. That’s not a small jump.
The volume is brutal. At least 127,000 workers at U.S.-based tech companies were laid off in 2025 alone, and a lot of them are strong engineers flooding the same application pools.
The format itself has gotten more adversarial. System design rounds that used to be reserved for senior engineers now start at mid-level, and senior candidates are getting Staff-level scope questions. The goalposts moved on everyone while some people weren’t looking.
And the kicker is — engineers who have built incredible real-world applications are struggling to clear interviews because they haven’t looked at graph theory in a decade. That’s not a skills gap. That’s a preparation gap for a very specific performance.
I’ve seen people with 20 years of experience describe spending sleepless nights grinding LeetCode just to get 5 rejections in 4 months. Not because they’re bad engineers. Because the interview is essentially a separate skill from the job.
So genuinely curious — for those of you who’ve been through this:
• How big of a gap did you feel between what you knew and what was being tested?
• Did your years of real-world experience actually help you at any point in the process, or did it feel irrelevant?
• What did you actually have to do to get back in interview shape?
• And honestly — did landing eventually feel worth it, or did the process change how you see the industry?
No judgment either way. Just feel like this story doesn’t get told enough compared to the new grad struggle.

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 am a technical person. We are supposed to be given requirements via a business analyst, who ideally should analyze the ask by business, impact, various scenarios, and tell us the same. But he is transferring that one line business ask to us. We, as technical people, interpret it in one way. After code development, he doesn't review our outputs functionally. We assume it's okay (an unsaid lgtm), then we ask the business to verify it as well.

During the verification by business, they tell us it's wrong and something else was expected.

How should I communicate to my manager that if this continues, there will be a lot of to and fro s, which will bring unnecessary delays for simple tasks? Also, what is my manager supposed to do, ideally? ​

In case I need some improvements in my approach, and it's a me problem, what should I do to get better at this? ​

This doesn't happen for technical-heavy tasks, but only when business wants a new feature. ​

I spent 30 minutes today doing something AI could have done in seconds.

I was doing some AWS stuff, trying to find tables with similar names across two Glue databases. Went back and forth with AI on approaches, tried comm, figured out how to use it, got it working.

AI would have just done the whole thing if I'd asked.

I have this habit of wanting to actually do things myself and understand what's happening. When AI suggests something, I'll sometimes go figure it out myself rather than just letting it run. It feels like the right instinct. Like that's what good engineers do.

But I'm genuinely not sure anymore.

There's a version of this where that curiosity compounds into real intuition over time. And there's another version where I'm just romanticizing doing things myself in a world that has quietly moved on.

I heard someone say, "AI can do coding but not engineering." and I like that. But I'm not totally sure what it means in practice, when it comes to deciding what's worth doing yourself vs what you just let AI handle.

So where do you draw that line?

And yes, I had this exact conversation with AI, then asked it to write this post. The irony is not lost on me.

As a developer of 11 years, I've been through a lot of interview loops. This last few months has been the most challenging set of loops I've ever gone through. It feels like you have to be perfect in each of your coding/system design rounds and your project experience to get a chance at an offer.

3 years ago (even in the midst of several high profile layoffs) I applied to 3 jobs, got 2 offers and I barely prepped for interviews.

This time, I spent weeks on hellointerview and neetcode/leetcode, and have 3 years of senior/staff level projects under my belt (and to that effect, I am not having a problem with those rounds). I was rejected after 3 tech screens, 12 onsites/loops, and got 2 offers.

This isn't a "why can't I get a job" rant thread (I got one), but rather, I want to know what is happening behind the scenes to make it so difficult for a skilled developer to get an offer. Is the bar raised in the debrief? Is the recruiter in the debrief urging everyone to be harsh? Or is it just "yes, he passed the bar, but so did these other 5 candidates and now we must rank and pick"?

And I'm asking here because most of us devs are in these debriefs. I've seen so many barely qualified candidates get pushed through at "high bar" companies. I'm just wondering what the conversations are like now for a full debrief team to say "well a year ago we would have said he crushed the coding round and the system design round.. but now? decline".

With a lot of these companies putting pressure on devs to use AI for near complete workflows how is everyone continuing to grow their skills or learn anything new ? I feel like I’m a the point where I get a new task or feature to implement and I’m told just use AI and that knowledge does really stick well.

spent like three hours today debugging a PR that looked syntactically perfect but had a massive logical race condition buried inside it. our juniors are basically just pasting LLM output now and praying it passes review.

Management thinks we are shipping way faster but im honestly just spending all my time acting as a human linter for a glorified autocomplete bot. Probabalistic models guessing the next token are fundamentally flawed for core business logic. it just doesnt scale without burning out the senior engineers

it does give me a little hope seeing the research side finally pivot toward formal verification. like seeing newer reasoning agents like Aleph being evaluated on strict machine-readable proofs rather than just checking if a python script runs once without crashing

until the enterprise tools move from probabilistic guessing to mathematically provable state transitions, this whole era is just generating an ocean of technical debt that we are gonna have to clean up later

I realize this is concerning but looking for a sanity check on whether it's a yellow, orange, or red flag. I work for a "tech" company. We sell software, that is our only revenue source, not an internal tools team for some boomer legacy non-tech corp.

At the end of each sprint, all outstanding PR's are approved and merged into main, regardless of whether changes were requested, if it's in draft status it will get changed to open and then merged.

Not minor changes or disagreements on variable names, pretty big concerns such as:

• This uses a different dependency version than the rest of our repo
• This redefines a function in our existing codebase because you like the way you do it better
• This code does not work, it raises 5 different exceptions
• I literally have no idea if this code works because it's written in an entirely different language than the rest of our codebase and we don't even have a way to run it

This isn't a case of "junior doesn't understand that software is complex" ergo backend, frontend, analytics all using different languages. Last sprint, we all worked on a simple feature that calls an API, writes data to s3, writes data to a database. We ended up with a python file, a shell script, a Dockerfile (uses a different version of python but it's main feature is that it defines it's own linting and pre-commit and overrides the repo config which is admittedly pretty funny) and a Kotlin file. We are not a Kotlin shop, I have no idea how they even wrote it. Everyone called the same API, wrote to the same bucket and database, and we all did it differently.

I work on a 6 person team, so basically every sprint we end up with 6 more pieces of a feature that either don't work at all, or don't fit with anything. There is vague talk about getting it to fit together later.