8 Brutal Truths About the Developer Job Market in 2026

In the last six months, I've talked to over 500 JavaScript engineers, from junior to senior to lead. I've also personally mentored hundreds of them at the senior dev together with my brother. Our mentees are landing six-figure offers at a time where most developers struggle to get interviews in the first place. In this video, I'm breaking down eight hard truths of what's actually going on in software engineering right now.

From how AI it's drastically changing coding, technical interviews, and the job market and, more importantly, what can you do today to stay employable, valuable, and in demand as a software engineer. Number one, the only stack, it's full stack. As this developer on Reddit observed, we are witnessing the death of specialization, basically, he says that originally they had people with different specialization, front end developers, back end developers, database engineers, but that now all those roles are now a single title, which is probably full stack engineer, and the developer it's expected to do all of them.

This is not something unique, this is something we've seen happening in the market worldwide, where companies are demanding full stack skills, no matter your specialization. For example, this is a front end engineering positions in California and they are asking for experience integrating UI implementations with restful APIs, so they're asking for more back end experience and experience with Docker, CI/CD pipelines, and git source control.

Meaning they are actually looking for a front end developer who can do full stack. So, my advice to front end or back end only devs, which is actually most devs, it's aimed to go full stack, build full stack skills on top of your specialization. Now, at the senior dev in the last few months, we've seen thousands of, you know, front end engineers and back end form and Kubernetes. When instead, you should look for things that are a bit closer to the front end, where your front end knowledge is still useful. Now, if you want to learn more about the specific concepts, you should master if, for example, you are a front engineer who wants to go full stack, then check the other video that Bogdan and I did about it. Hypothesis number two, the senior only market, it's here to stay. If you go to LinkedIn and you make a quick job search, you look for something like front end developer positions. You see all the top positions that are popping up in the search are usually senior or staff engineer. And if you scroll down in the search, you'll see that it's dozens of them and that most positions are actually asking for senior or staff engineers. Which is pretty crazy because most developers in the market are not staff and some of them are senior, most people are somewhere at a mid or junior level. And I really wanted to dig into the numbers, so I applied a filter, which is, hey, just show me mid to senior level positions. And even if you do that, you'll see most of them in the title have senior/staff. But what was surprising was that we've got about 1,646 results, which is quite a lot. What's even more surprising is that if you change your filter and you say, hey, just show me entry level, which I guess for LinkedIn, entry level, it's about like zero to probably three years experience, maybe these days five is experience. Anyway, you see there is like 257 results. So, they're about six to seven times less entry positions than senior positions. And part of that you can blame on AI. This is actually a study that came up a few days ago, actually October 13, where they analyze, if I read correctly, about 62 million workers across 285,000 firms in the US, and they realize that AI adoption it's associated with a sharp decline in junior employment among adopting firms relative to non adopters, while senior employment remains largely unchanged. Meaning, senior dev market, it's still doing great, but juniors got crushed.

which is something that most developers we talk to and work with actually are telling us about and brings me to the number one advice that we give to junior and mid-level devs, which is get to senior as fast as you can. It doesn't have to be by working with someone like us, I think we can help you get there much faster, but make that your number one goal if you want to stay competitive in this market.

Also, if you want to learn more, Bogden and I are constantly making videos about this, check out our channel for specific concepts you need to master for you to make that jump from junior mid level to as the senior. And by the way, folks, if you don't know me, my name is Dragosh and together with my twin brother Bogdan, which you see a lot on the channel as well, we co-founded the senior dev where we focus on helping JavaScript focused engineers, you know, React, Node.js, Angular, view, whatever you're working with.

We help you make the jump towards the senior level. If you want to know more about what we do and how we could help you, just check the link in comments. Hush, market truth number three, AI coding sucks, but you still have to deal with it. So as soon as vibe coding became a thing, Bogden and I digged into the numbers, digged into the performance, we use it ourselves as a senior dev on our platform, and we realized that AI coding, it's largely overestimating.

What we are seeing is that yes, AI coding is not what it claims to be from a developer perspective. Tech companies are still going to basically push it down your throat in a way. So, even if AI coding is not that amazing, AI engineer positions are going at a crazy pace. This is another search I've done on LinkedIn where I googled for AI engineer positions. And as you can see, this is about 2,975 results.

I think it's more results than the front end search I've done, which was unthinkable a few years ago. But, and this is something that Gary Oslo at the pragmatic engineer realized, that when it comes to AI engineers, there are basically two types of them, the foundational model building versus model application. And when we talk about model building, these kind of AI engineers that are building models, they are the ones that are building the LLMs themselves and they are very close to research side, many times they they have a PhD and they have a very narrow focus. They focus on making LLMs better. And then there is another whole category of AI engineers which are more dedicated to model application and should I say model integration. This is one job posting that I found from that search on LinkedIn where for an AI engineer position they are actually asking for what? Two plus years of experience as a full stack engineer and they ask you for JavaScript knowledge, they ask you for a REST API knowledge, they ask you for Docker and so it's basically a full stack engineer that has some hands on experience building with LLM. So whether you are a front end, back end or full stack engineer, and you want to become more employable in the current market, we advise you to learn AI, but don't obsess over it. Meaning, don't drop your front end or back end or full stack knowledge and just jump straight into AI. And by the way, if you want to learn more, and I have made a video exactly about that, you can check it out in the channel. Harsh reality number four, React, it's not killing innovation. AI garbage is. A few years ago this article went viral about how React won by default and it's killing front-end innovation. What the author was claiming was that software engineers and particularly front-end engineers worked with React so much and got so used to it that whenever they are building a new app, they are not even thinking about whether, hey, is this the best framework we use? Maybe we should pick something like Vue or or Svelte or etc. They basically they are not doing that, they're just going and saying, hey, let's just use React and let's see how do we do this with React. And this is basically killing innovation. And honestly, I don't agree with that. First of all, because for God's sake, it was about time for us to have a default solution in the front end. And the fact that React is becoming this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this this

default solution where people can be like, hey, I can use React. I don't need to go to a whole cost benefit analysis for a simple app that's been built over and over again. I believe that's a positive thing, it already bring a lot of standardization in the way we do things and the way we build apps, and I believe React becoming more popular. It's an overall win. Now, I do agree with with the author that this choice about the framework you use should never be automatic and you should always think about it even if it's just a bit.

But what's even more interesting about this is that I don't believe React actually killed Web innovation, I believe it's something else and I bet you know who. Because if you remember the good old times, if you Google for any quality tech talk like anything that's in dent, you know, talking about events or or parsing JavaScript, all these amazing tech talks that are very focused on the fundamentals that are still thinking about how to optimize things are usually from what 10, eight, 57 years ago.

And what happened ever since? Did JavaScript got infinitely better so we don't need to talk about optimization? Did the web got incredibly better so we don't have to care about the details as software engineers? Not really, and sadly it's getting even worse because if you look at the release date of major frameworks that we use now, next JS one of the latest to come out and then we've got you know, graphl or even tools like vite.

If you look at the release date of these frameworks and tools, you'll be surprised that the great majority has been released before 2020. What happened then? Well, on November 30, 2022, chat GPT has been released and boom, the whole developer community gravitated towards that direction where it seems like every article, every tech talk, every YouTuber out there is talking about LLMs and generative AI and AI coding or whatever Sam Altman and Andre Karpathy says.

And I'm not saying that LLMs has a whole didn't had a the impact on programming or the web community as a whole. But I do feel like us divoiding all our time and attention talking about this, really created a gap in the innovation that's happening on the web. Which actually brings me to the next point, code is still king, and why it's code still king when everybody's thinking that developers are going to be obsolete and we won't have to write a lot of code.

Well, actually because the opposite happen, right? And as these programmers saw, life coding is becoming the norm now and they want you to be coding live and they want to be recording when you're coding. What happened? AI increased massively the number of fake applications, fake applicants, and there's a lot of fraud going on. So, one of the few ways left for companies to actually assess your skills is to see you doing it live.

Code is still king, because whatever take home challenge you send to somebody, they will drop it into GPT and just let GPT do it and send you back 1,000 lines of code that you have to go through. But not only that, some people say that, hey, with AI coding, you know, the developer will transition into more like a tech lead for AI or an architect where basically AI does the coding and the developer makes technical decisions.

And I honestly believe this statement, it's completely flawed. First, because as I've already mentioned, AI coding sucks, and second, because a great architect, it's first and foremost a great coder. Code is architecture. You can't really have one without the other. So, as I've said previously, don't get distracted, keep on coding and keep improving your technical skills. My advice to everyone, it's don't be this guy that's asking how to improve my coding skills after relying too much on AI.

And at the senior dev, we see a lot of software engineers doing this, even senior engineers are using AI so much to a point where their actual coding skills are getting worse and worse, then something happens in a company, they need to go to the market and get a new position. an interview. And that's when they realize whatever they did with AI, back at their job is practically useless, because companies want someone who can actually code without AI.

AI is not an invitation for you to stop improving your skills and your technical knowledge. And by the way, if you want to know, hey, where should I start exactly, or what are my caps and what should I actually improve on, which is probably the first question that pops in your mind when you try to do that. Bogni put together this free 10 minutes tinkle assessment for just engineers. Invest 10 minutes into it and it will give you exactly your strengths, your weaknesses, where you stand in the market, most importantly, what you can do to improve.

Harshty number six, don't try to plan your developer career, you'll probably fail. Back in the days, you had this linear progression, right? You would learn how to code, get to junior dev, then probably meet and senior and etc, maybe principal, maybe staff, maybe you would go into engineering management. But the market is a lot more messy these days. There's so much uncertainty, you can get a job and three months you're again looking for another job.

You can get a freelance project in between and then you go back to full employment. You can't really plan. There's just too much random stuff happening and so many things outside your control that I feel like trying to plan your developer career in this environment. It's setting yourself up for failure. Because these days what really happens is, yeah, you might start as a junior, maybe you find a position, maybe you don't, maybe you go freelancing a bit, maybe you get an opportunity to to be a tingle co-founder.

Which I wouldn't advise someone at junior or mid level to do, or maybe whatever, there is no script. You cannot have a linear career progression. It's very challenging to have this kind of linear uniform career progression. And my advice here is just to kind of surrender to the chaos and just be a bit flexible, you know, this doesn't mean you should like jump from place to place and opportunity to opportunity.

You should have a strategy, but don't expect something linear, don't expect things to fit on a piece of paper. have an amazing resume. Because in the end, in this market, you know, your offer might get canceled, you might get fired even after a few months of doing an amazing job. The company you work for might shut down completely tomorrow and you have to go back to the job market. You never really know.

But trust me, you will be fine. And this is something that being a senior gives you, which is you've been in these situations before. You had friends who got fired, then they found another job. Then even yourself, maybe your project was shut down, you had to go back into the market. But you have this experience and that gives you confidence. And that confidence helps you not to panic when you get laid off and be like, hey, you know what?

Time for a new chapter. Again, my tip here would be for you to stay flexible. And remember, it doesn't really matter if your project is three years or three months or three weeks. You can learn something from everything and you can make the best of it. Which actually brings me to the next point, because there's a limit on how flexible you should actually be. Hardware reality number seven, your text stack matters more than you think.

So if you've been around, you probably heard this voice before that in software engineering, there are like 15 patterns that keep repeating themselves. And if you master those patterns, you are done because it would be very easy for you to pick up another framework, another text stack, etc. And honestly, I stand by this advice. I believe mastering these repeating patterns and mental models, it's probably one of the best, fastest and only way for you to get to senior.

This is actually what senior devs do, but there's a catch. How well you implement these 15 repeating patterns depends on your understanding of the framework, platform and environment you are in. So, it's 50-50. 50% of your software engine knowledge, it's fundamentals and mental models that are framework agnostic. And the other 50%, it's very implementation focused. So for example, things like object oriented programming or functional programming. These are fundamentals that you can apply in different languages, different requirements, etc. But if you're a JavaScript engineer and you work with something like React or Node, it will be tough for you to be productive if you only know these kind of framework agnostic concepts and you don't have an understanding of of how JavaScript actually works and of course the browser. Because as you can see here, when we are trying to implement something like a in memory cache in both JavaScript and Java, the implementation, the code itself can be quite different even if the design and the principles behind it are very similar. Lord have mercy for the Java developers out there because this file was like 100 lines. Anyway, moving on to highest reality number eight, burnout and not AI, it's your greatest enemy. Funny enough, a few days ago, I was checking which article on our blog at the senior dev was the most read in the last one months. And I was surprised because we've got a lot of stuff out there, we talk about senior concepts, we talk about senior front end road maps and back end road maps. But the article that got the most visit was actually this one. To every developer close to burnout with this. And the fact that the market being difficult means a lot of software developers have to stay in jobs they don't like, they have to put up with longer hours, they have to put up with stuff they don't like. Then it makes sense that a lot of developers are actually burning out. What's worse and I remember back a few years ago is that developers don't pay a lot of attention to burn out until they are burn out and when they are burn out, they don't blame it on the job or on the hours, they think, hey, maybe you know, maybe I'm not made for this job. You know, maybe it's not for me. I have some other colleagues who are putting up with all this stuff and they don't really complain about it. And I truly believe this is the worst way you can think about it because you're just kind of putting a lot of shame on yourself and not really thinking about the problem.

and I've checked different studies, it's hard to come up with an exact number, but about 70% of developers suffer from burnout. Some of them are critically burned out, others are kind of just exhausted, just tired, just sick of it, but, you know, they have to pay bills, so they just keep coming. And I honestly believe this is a pity in last few years bug the nice, so many talented developers who left the industry, just realize a few years after that they're actually missing it. I don't want this to to happen to you. So let's understand first why a burnout happen and then how you can actually fix it. Developer burnout happens because first of all, a lot of developers have to work over time, which is more and more common. Managers, they want to hit their numbers and they're just pushing people, pushing people, especially when they know the market is tough and people don't have a lot of choices. Which is actually very sad, because that person will leave you as soon as they have an opportunity and it's a bigger loss for the company. But what can you do about? Then there are, of course, unclear requirements. Hey, just just code it, just make it happen. Code what? And also, of course, the project scope just keeps going and going, we just keep adding features and adding features and we never release. Or when we release, there's a lot of bugs going on and the work is never done. I I live to this and it definitely it can get you burn out very, very fast. Then there's too much stuff going on, frameworks, AI, learn this, learn that, there's so much anxiety, so much pressure. It feels like it's never enough, of course people get burn out. Job market instability doesn't help. Then AI, it's adding even more noise and increasing expectations, not productivity, because you have all these tech companies who are pushing this AI tool. Saying, no, this will make your developers 20, 30, 50% more productive. Then developers are using the AI tools, they might be maybe a 3, 5% productivity increase. But now the managers have to justify everything, all the investment they've done in those AI tools, right? So they are pushing developers actually. Finally, because of all this, a lot of software engineers put all their time in energy into their job.

And when they get home they have nothing else going on besides their job. Their whole identity is tied to their job and their happiness, they may have one or two friends. They don't have a lot of hobbies besides maybe video gaming, which is not a very healthy to have, especially when you spend 80 8 hours a day. Looking at the computer. And this leads to burnout and it leads to depression and it leads to to misery, yeah, you know, I was that developer that would, you know, spend 10 hours a day at work. Then go back, have some junk food, play video games until 2:00 a.m., 3:00 a.m., then just wake up, drink a bunch of Red Bulls, back to the office, back to coding, back home, more video games, more junk food, etc. It's a recipe for failure. The good news is that you can learn how to mitigate most of these issues. And the first point you have to not forget is to have fun. Yes, we have deadlines, we have requirements, but work has to be fun. We spend 40 hours a week there. At to enjoy at least half of what you're doing. Also, learn how to differentiate signal versus noise. Get good at ignoring stuff. You don't need to master all the 15 frameworks that are in your in your inbox. So AI coding tools or you don't need to invest in nFTs and blockchain and all that crap that people are, you know, talking about and making you feel like you're missing out on stuff all the time. You don't need that. Shut down your YouTube, shut down your your email for about 3 days and you're going to be just fine. You still your your life will not change. Second, learn how to manage expectations, external, that means your boss, your stakeholders, your project manager, and also internal. That means your own expectations over your your own performance. Because most people are very critical on themselves, very hard on themselves when they actually shouldn't. Also, set boundaries, again, say no, say no to projects, say no to people, protect your time. Improve your tangle skills, both interviewing and delivery. I think there is this very good quote from Jim Ron where he said, don't hope for things to get easier, hope for you to to get better. And that's the best advice I can I can give you, the better you get.

the easier things will be. And of course, finally, find a mentor and a community, it's a lot easier to go to these things when you are surrounded by someone who went through this and by other people who are going through the same and realize, hey, it's it's not me, it's just the way it is and I can learn, I can become better and look at them, they went through the same and look at where they are now.

And I'm not saying you should, you know, join our mentorship and our community, all I'm saying is if there's someone at work, if there's someone that you know, you can get some mentorship from. It doesn't have to be every week, it can be someone that you have lunch with once a month. That's totally fine. I used to do this with a bunch of my uh ex CTOs and tech leads where I would have lunch with them once a month and I would talk about the struggles, they would tell me how they would deal with it, how they dealt with it, etc.

And it helped me a lot and it led me to amazing friendship and it opened so many toys in my developer career. So I advise you to do the same. And finally, change your perspective. And this is one change I wish I did a lot earlier in my developer career where I should have changed from I have to to I get. I used to go to work and think about all this stuff, you know, I have to learn testing and I have to learn performance and I need to ship this and this feature and then I need to apply and I need to improve my skills.

And I have to do this data structures and I have this now to learn about system design, I have so much to do and so little time and I just, you know, why me, why why do I need to to do all this stuff? And one day I was reading this book and the author said, hey, everything you do, you should do with passion and you should think about how lucky you are to be in a position where you get to do all these things.

Where you have the opportunity to actually learn more about system design, to learn more about data structures, to learn more about what other companies are doing when you're interviewing. And this little change in my, I mean, the work was the same, you know, I would go to work and do the same, but I'll finally at least be able to enjoy at least, you know, 50% of it, which was already huge improvement.

And I invite you to try the same this week. Okay, folks, this is it for today. And I'll see you in the next one.