There is something interesting happening in the tech job market right now.

Open LinkedIn, Get on Board, Wellfound, or practically any job platform, and you will start seeing the same thing:

  • Senior Frontend Developer.
  • Senior Backend Developer.
  • Senior DevOps Engineer.
  • Senior Software Engineer.
  • Senior Full Stack Developer.

Senior. Senior. Senior.

Suddenly, it seems like every company exclusively needs senior developers. The problem is pretty obvious: there simply aren't enough senior developers to fill all the positions companies are trying to hire for.

And while companies compete to find candidates with five, seven, or ten years of experience, there is another group trying to figure out how on earth they are supposed to get those five years of experience when nobody wants to give them the first one.

Junior developers.

That's why I often say, half seriously and half as a provocation, that if you can't find a senior developer, maybe you should start paying more attention to good junior developers. Not because two juniors magically become one senior. Experience doesn't work that way.

A senior developer doesn't just write code. They have made bad decisions, broken things, watched systems grow, maintained code written by someone else, fixed architectural problems, investigated production issues, and learned when a technically perfect solution can actually be a terrible business decision. You can't replace that simply by hiring more people.

But I also think many companies are overlooking something important: a good junior developer, with the right guidance, can grow much faster than we sometimes think.

And that is exactly why I believe this is, at the same time, the worst and the best time to be a junior developer.

The worst time to break into the industry

It's hard to ignore what's happening. Many positions that a few years ago could have been junior or mid-level roles are now being advertised for senior profiles.

Companies want to reduce risk. They want people who can get up to speed quickly, work with a certain level of independence, and start delivering results as soon as possible. From a business perspective, it makes sense. From the perspective of someone trying to enter the industry, it can be frustrating.

Because eventually, you run into the question almost every developer has probably asked at some point:

“How am I supposed to get experience if I need experience to get a job?”

And the answer I would give today is very different from the one I would have given ten years ago. Because you no longer need to wait for a company to give you permission to start solving problems.

You can start now.

Software always starts with a problem

When someone starts programming, they often make a very common mistake: thinking first about which technology they want to use.

  • “I want to build something with React.”
  • “I want to practice Next.js.”
  • “I want to learn Python.”
  • “I want to build an API with NestJS.”

There is nothing wrong with wanting to learn a technology, but real products don't usually start there.

They start with a problem.

Practically every company exists because someone identified a need they could satisfy. We need drinking water, so companies exist to produce and distribute it. We need food, so supermarkets and entire distribution systems exist. We need transportation, so transportation solutions emerged. We need to communicate with people who may be on the other side of the world, and today we have systems that allow us to do that almost instantly.

Software is no different.

Behind every application, there is a problem.

And if you're a junior developer wondering what to build, there are probably dozens of problems around you waiting for a solution. Look at:

  • Your workplace.
  • Your university.
  • Your family.
  • A small business.
  • How you manage things at home.
  • Something you repeatedly do in Excel.
  • Something someone is still tracking in a notebook.
  • A boring task that could be automated.

There may be much better portfolio projects hiding there than another Netflix clone.

The question stops being:

“What project can I build?”

And becomes:

“What problem can I solve?”

That small shift develops something far more important than learning another framework:

judgment.

Learning today is completely different

When I started programming, around 2013, 2014, and 2015, learning was a very different experience. There were courses, books, documentation, and plenty of content online, of course.

But whenever something stopped working, the pilgrimage began:

  • Stack Overflow.
  • GitHub Issues.
  • Forums.
  • Blogs.
  • Videos.

You would find a six-year-old question that seemed to describe your exact problem, only to discover that it used a completely different version of the library.

You tried one solution. It didn't work. You tried another. You broke something else. And then you went back to researching.

I'm not saying that time was better. I also don't believe that suffering unnecessarily automatically makes someone a better developer. Those were simply the tools we had.

Today, something exists that radically changes the learning experience for someone who is just getting started:

artificial intelligence.

You can now have something very close to a tutor available while you study.

Didn't understand closures? Ask.

The explanation is still too complicated:

“Explain it to me as if I had just started learning JavaScript.”

Still don't understand it:

“Give me a real-world example.”

Now you understand the example, but you don't know how to turn it into code:

“Let's implement it step by step.”

You can do this with architecture, databases, testing, APIs, authentication, design patterns, Git, Docker, algorithms, or practically any concept you're working with.

And you can ask twenty times. Fifty. A hundred.

Without feeling like you're slowing down an entire class because everyone else already understood.

That is a huge change.

But using AI doesn't mean letting it think for you

There is a trap here too.

Having ChatGPT, Copilot, Claude, Gemini, DeepSeek, Grok, or any other tool open while you code doesn't automatically make you a better developer. In fact, you can end up achieving exactly the opposite.

You can build massive applications that appear to work perfectly well and have absolutely no idea why they work.

That shouldn't be the goal.

Artificial intelligence should accelerate your learning, not replace it.

If it generates code you don't understand, ask what the code is doing. If it proposes an architecture, ask why.

Ask:

  • What other alternatives exist.
  • What advantages it has.
  • What problems it could create.
  • What the official documentation says.
  • What best practices exist.
  • What would happen if the system had one hundred users.
  • What would change if it had one hundred thousand.
  • Which parts should be tested.
  • What security problems you might be overlooking.

That conversation is where the real learning begins.

One of the habits I recommend the most is exactly the same one I recommended before this generation of artificial intelligence existed:

read the documentation.

AI can help you understand it. It can summarize it. It can give you examples. It can explain concepts you don't fully understand yet. But you should get used to going to the source and understanding how the things you're using actually work.

Because writing code has never been the hardest part of being a developer.

The difficult part is knowing what code you should write and why.

Your portfolio should show how you think

That's also why I don't believe too much in portfolios made up entirely of pretty screenshots. A working application is great.

But behind it, there is something potentially much more interesting:

the decisions you made while building it.

Let's say you found a problem and decided to develop a solution.

Document the process:

  • What problem did you find?
  • Why did you decide to solve it?
  • What was your first approach?
  • Which technologies did you choose, and why?
  • What went wrong?
  • What did you change?
  • What did you learn?
  • What would you do differently if you started again?

You can even write about it. Create a small blog inside your portfolio and publish what you're learning along the way.

Now imagine this from the perspective of someone evaluating candidates.

Instead of receiving a CV that simply says:

“React, JavaScript, Node.js, PostgreSQL.”

They visit your website and find three real projects:

  • They can see the code.
  • They can use the applications.
  • They can read why you built them.
  • They can see the problems you ran into.
  • They can understand how you researched those problems.
  • They can see how your way of thinking evolved.

That starts answering many interview questions before the interview even happens.

Don't commit too early to a single technology

Another common mistake when we're getting started is defining ourselves entirely by a tool.

“I'm a React developer.”

Perfect.

But React is a tool.

JavaScript is one too.

  • Python.
  • PHP.
  • Ruby.
  • Java.
  • Angular.
  • Next.js.

They are all different ways of expressing solutions.

Of course, you should understand the tools you work with. Every language has its own characteristics, ecosystems, patterns, and philosophies that take time to master.

But underneath all of that, there is something much more valuable:

logic.

If you understand what problem you want to solve, how to break it down, how information flows, what responsibilities each part of the system has, and what result you expect, learning a different syntax becomes much easier.

You're no longer starting from zero.

You're starting from a different question:

“I know what I want to build. How does this language express this solution?”

That shift is huge.

That's why a good junior developer shouldn't obsess only over collecting technologies. They should obsess over learning how to solve problems.

Put your hands to work

You can:

  • Watch three hundred courses.
  • Save forty playlists.
  • Buy twelve Udemy courses.
  • Read one hundred articles.
  • Ask ChatGPT twenty different questions.

And still be exactly where you started.

Because eventually, you have to close the tutorial and build something.

There are initiatives like Midudev's 100 JavaScript Projects that can help you start practicing with smaller projects. But you don't have to limit yourself to projects someone else came up with either.

Look around.

  • Find problems.
  • Build things.
  • Start small.
  • Then build something a little bigger.
  • Break code.
  • Fix it.
  • Refactor it.
  • Write tests.
  • Deploy it.
  • Let someone use it.
  • Discover that the user did exactly the thing you were absolutely sure nobody would ever do.
  • Fix it.

That is experience too.

Maybe it isn't professional experience yet.

But it is definitely experience building software.

And when a professional opportunity eventually comes, you won't have to introduce yourself by simply saying:

“I'm looking for my first opportunity.”

Instead, you'll be able to say:

“I'm still looking for my first professional opportunity, but this is what I already know how to build.”

There is a huge difference between those two statements.

So, what makes a good junior developer?

I don't think it's knowing twenty technologies.

Or solving LeetCode problems faster.

Or having a GitHub profile full of green squares.

Or writing code without ever searching Google.

And definitely not writing code without artificial intelligence just to prove something.

To me, a good junior developer is someone who is curious:

  • Someone who asks questions.
  • Someone who researches.
  • Someone who tries to understand.
  • Someone who accepts when they don't know something.
  • Someone who reads documentation.
  • Someone who experiments.
  • Someone who breaks things and wants to understand why they broke.
  • Someone who receives feedback and uses it to improve.
  • Someone who gradually develops better judgment.

And above all, someone who puts their hands to work.

Because this may be a difficult time to get that first opportunity. But you also have access to tools that previous generations of developers could only dream of:

  • Free documentation.
  • Courses.
  • Open-source repositories.
  • Communities.
  • Complete projects.
  • Free development environments.
  • Cloud platforms.
  • Artificial intelligence.

And an absurd amount of knowledge available almost instantly.

That's why I still believe this is the worst and the best time to be a junior developer.

The worst if you're waiting for someone to show up and give you permission to start.

The best if you understand that you can start long before that opportunity arrives.

Learn. Research. Ask questions. Build. Document. Make mistakes. Fix them. Then build again.

Because maybe you can't put “Senior Software Engineer” on your CV yet.

But you can start developing something much more important today:

the way of thinking that will eventually turn you into one.