Subscribe
Share
Share
Embed
If I had to choose between a junior engineer and a senior with 10 years of experience who's only ever focused on writing code, I'd pick the junior. Every time. In this solo episode, I explain why junior engineers have an unfair advantage right now, and why the seniors who only think in code are the ones who should actually be worried about AI.
I break down what AI can and can't replace, why starting from the problem instead of the tech stack is the fastest way to grow, and share the story of my first job in 2016 where I accidentally became a product engineer before I even knew the term existed. Plus: a practical playbook for juniors who want to break in, and a wake-up call for engineering leaders who've stopped hiring them.
---
TIMESTAMPS
00:00 I'd Hire the Junior — Here's Why
01:00 The Wrong Question Everyone Is Asking About AI and Juniors
02:00 What AI Can't Do: The Real Work of Software Engineering
06:00 My First Job in 2016: Accidentally Doing Product Engineering
09:00 Why Hyper-Specialisation Is the Real Risk
11:00 The Unfair Advantage of Fresh Eyes
12:00 A Playbook for Getting Started Without a Job
14:00 From Side Project to Entrepreneur
15:00 How Portfolios Have Changed
16:00 A Message to Engineering Leaders
17:00 Three Essential Books for the Product Engineer Path
19:00 Wrap-Up
---
KEY TAKEAWAYS
1. Junior engineers have fresh, unmolded minds — they haven't been "polluted by the old ways." That malleability is their biggest asset in a world where the rules of engineering are changing fast.
2. Writing code is the easiest part of software engineering. Understanding what to build, clarifying messy requirements, talking to users, system thinking — AI can't do any of this. This is where product engineers live.
3. Hyper-specialisation is the real risk. If your value is pattern recognition and applying known solutions, that's exactly what LLMs are good at. Seniors stuck in their ways are more replaceable than adaptable juniors.
4. Start from a real problem, not a tech stack. Look at your life, talk to people, and find a human problem to solve. Build a prototype, run usability tests, iterate. That's your new portfolio.
5. For leaders: stop hiring juniors to write boilerplate. Hire them to solve problems. Put them in front of customers. Make failure safe. Pair them with AI, not against it.
6. The companies that invest in growing junior product engineers now will have a massive advantage in five years. The ones that don't will be fighting over a shrinking pool of senior talent.
---
RESOURCES MENTIONED
- Continuous Discovery Habits by Teresa Torres
- Extreme Programming Explained by Kent Beck
- Don't Make Me Think by Steve Krug
- The Lean Startup by Eric Ries
- Clean Architecture by Robert C. Martin
- Continuous Delivery by Dave Farley
- The Pragmatic Engineer newsletter by Gergely Orosz
- PostHog's Product for Engineers newsletter
- Lovable, v0, Replit — AI prototyping tools
- Cursor — AI-assisted coding
---
CONNECT WITH PRODUCT ENGINEERS
Host: Peppe SillettiLinkedIn: https://www.linkedin.com/in/peppesilletti/Website: https://peppesilletti.io
Product Engineers:
Website: https://productengineers.comNewsletter: https://newsletter.productengineers.comLinkedIn: https://www.linkedin.com/company/product-engineers
---
SUPPORT THE SHOW
If you're a junior developer wondering where you fit in the AI era, or a leader who's stopped hiring juniors — share this episode with someone who needs to hear it. Drop a comment with your biggest takeaway.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
Product Engineers is the podcast about the convergence of product and engineering in the AI era: what's breaking, what's working, and the craft of doing both well.
If I had a tech company today and I had to choose between hiring a junior engineer or a senior engineer with 10 years of experience who has only ever focused on writing code like a code monkey and completely ignoring the product side of things, I would definitely hire the junior.
Hands down, no hesitation. I know that sounds crazy, especially right now when everyone is panicking about, uh, junior developers being replaced by AI.
But, you know, I think junior engineers right now have really an unfair advantage that most people in our industry are completely ignoring. And in this episode, I'm going to explain why.
Welcome to the Product Engineers podcast, where I'm unpacking the convergence of product and engineering roles in tech.
I am Peppe, and I am an engineer who spent years as a code monkey before figuring out there's a better way. There's one question that you see over and over on social media nowadays.
Since AI came into our world, everyone is asking, "What about the junior developers? How are people going to grow into senior developers when AI can do their job? How are juniors going to practice?
How are they going to make mistakes if they don't touch the code and grow into the profession?" I get it. Really, I get it. It's, it's a legitimate concern.
But I think the people asking these questions are thinking about it completely wrong.
They're assuming the only way to grow as an engineer is through writing code, through mastering a tech stack, through years of repetition, and that's exactly the kind of thinking that's going to get people replaced.
Not juniors, but the seniors who think like that. Junior engineers coming into the industry right now are still learning how everything works. They have not been polluted by the old ways. They are still malleable.
Their tech brain is still evolving, and that's the best time to create the engineers of the future. Before I get into the how, let me explain something that I think a lot of people are missing.
Everyone is focused on the fact that AI is getting very good at writing code, and really it is. That, that's undeniable. But writing code is the easiest part of software engineering.
Think about what actually makes a product successful. It's not the code. It's understanding what to build. It's clarifying messy requirements. It's talking to users and figuring out their real problems.
Not the problems they tell you they have, but the ones you discover by watching them struggle. It's making architectural trade-offs.
It's dealing with production accidents at 3:00 AM when something breaks in a way nobody anticipated. It's understanding how your changes affect the system as a whole. You know, system thinking.
AI cannot do any of this, and this is exactly where product engineers live. This is the work that matters.
So when people say AI is going to replace junior developers, what they really mean is AI is going to replace the, the grunt work, the, the boilerplate, the simple bug fixes, the repetitive coding tasks.
And you know what? That's amazing because that was never the valuable part of the job anyways, and plus it sounds more like an exploitation than actually teaching anything to junior developers, really.
I'm going to say that the best way for junior engineers to get into the industry right now is to stop thinking about tech. At least, a- as the first thing, right? Stop thinking about what tech stack you should learn.
Stop thinking about whether it even makes sense to learn coding or not. Instead, start working from a product problem. Let me give you an example.
Let's say you have this onboarding that is not working well, and people are churning, uh, after the first step. Okay, let- let's see why.
And, um, you don't need to be an expert in product or a UX designer or any of that to start doing this. Otherwise, what, what's really the point of being a junior developer that is, that is learning, right?
You start from there, from the problem, and you start thinking, "Okay, let's see what's the problem. Let's go look at the session replays. Let's maybe go talk to some users.
Let's do some usability tests and watch people using the onboarding and see where things break." Everything I'm saying right now are really simple instructions, some guidelines that the junior developers can follow.
And of course, that means that they're probably not going to do a great job initially. That's expected, which is perfectly fine. And
the, really, the best thing is that they will start understanding and see how things work. They will start thinking not in terms of solutions but in terms of problems to solve.
Once they identify the problem, they then... they can start doing some research. They go online, uh, to look for best practices. They ask AI at this point.
They go to ask to their senior engineers or other people in the company who understand about what they're doing, and they ask them, "How, how, how can I do this? Uh, what's, what's a good approach?
What do you recommend?" And it's perfectly fine for them to also just try something, anything, and just see what happens. Of course,
for this to work, you need to work in a company that makes failure a first-class citizen of the system. You must fail to learn. That's inevitable. And most of the time, that's the...
Yeah, that, that's really the best way to learn. Together with working from a problem and not from a solution. That's also the best way to develop problem-solving skills.
Once the problem is found, then the junior product engineer can also suggest how to improve the experience and eventually change it in, change it in the code.
I expect a junior engineer to have a basic understanding of programming, of course. If they've done any courses or university degrees, I am pretty sure they have a good foundation.
To become dangerous with code, you don't need 10 years of experience. It is completely feasible to do it from day one. They will need to interact with the code.
They will need to understand what, uh, effect the changes haveOn the code base. Now, they could do some live coding here of course, but I would say it would be better to work in a AI-assisted way.
So using AI to talk, to talk with the code, try to understand what's going on, and to implement them. I'm pretty sure that anyone that really got out of university can do this nowadays.
So all of this makes me think about, uh, my first job back in 2016 as a software engineer.
You know, I just came out of university, but I, I, I had, I already started programming since I was 15 years old, so I had developed some experience, but not really production experience.
I was mainly doing some side projects and playing with it. I think then the university really helped me kind of getting some better knowledge about, uh, databases, software engineering principles, and stuff there.
In this company, my first job was very, very challenging.
The company was called ViriCity, and it was a startup in Amsterdam that was building a monitoring system for electrical buses all around the Netherlands and in other countries.
I was tasked with building the system to update the software on the devices on the buses. There were these small devices running, uh, like, uh, reading data from the buses.
And, uh, the system, uh, needed to operate both the operating system but also the applications running on, on it.
I've always been kind of a curious person, really entrepreneurial and proactive, so I thought, "Okay, let- let's, let's just get with this. Let's see what I have to do." So I just kind of followed my guts,
and, you know, really that, that instinct to start from the problem i- is what really made a difference. I didn't just sit down and, and code.
I went to my colleagues and asked them what, what, uh, what, what's the problem that we're trying to solve here? What, what does the current process look like? What's breaking?
And I built prototypes and put them in front of people before building the real thing. I watched how they used it and iterated based on their feedback. That's the product engineering way of working, in my opinion.
Even then, even though back then I really didn't know I was doing that, right? Did I write the best code? I think not.
I probably over-engineered it a lot, and because, you know, I was following design patterns and everything, and I wanted a bit to impress my colleagues.
But, um, you know, I already knew a bit of test-driven development, which was very helpful to help me write some good code.
And, uh, while developing, I was also learning in the same time React, Redux, how to write better CSS, and also I was studying how to use Node.js and streaming and APIs. And
eventually I did it, of course, with also, um, have the help of the CTO and my colleagues. But yeah, it was one of the most successful project of my life or my career, and I still remember it.
Back then, I didn't realize that I was accidentally doing product engineering. I was just trying to solve a problem the best way I could. But looking back, that was exactly it.
I wasn't tasked with a technical thing to do. I was task- tasked with a problem, and the way I approached it, by talking to people, prototyping, iterating, that's the product engineer way.
I think new engineers really have the opportunity to start with a fresh perspective about how products are built.
They can easily overcome senior engineers who have been stuck in their ways for ages, who have only been focusing about the tech part.
Those engineers, I have to say, are the ones that risk more to be replaced by AI, because AI is getting very good at writing code.
Uh, anything that is hyper-specialized is something that AI will do very well eventually, because hyper-specializations means we have, we have seen the same pattern over and over and over and you know when to apply what.
That's exactly what LLMs are good at, pattern recognition and applying a solution to a specific problem that's been seen before. If anything, the learning process for juniors will be sped up way more thanks to AI.
First of all, you have a personalized coach that can help you along the way, and in the beginning, you are not an expert in, uh, product discovery. You're not an expert in experience design.
You're not an expert in software architecture, and so on. But, you know, junior engineers now can use a mix of working with mentors together with a, an AI coach that can give them feedback.
And again, really for this to work, it's very important that these new product engineers work in a company that enables them to do this, that accept failure as the only way to grow.
Really, the best way to grow as an engineer, as always, is, is testing something. It's seeing how it works out in the wild and getting feedback.
Nowadays with AI, you can do this very quickly, and you can build stuff very fast, and you can get feed- feedback more often. This is the best way.
Junior engineers have an unfair advantage of having a very fresh pair of eyes, a very fresh brain that they can use to learn a new way of thinking. They will do way better than engineers who are stuck in their ways.
Now, you may say, "Okay, this is great, but how does it work in practice? How can I get experience if I'm not hired by someone?" And this is probably the most important part of this episode, so listen carefully.
Back before AI, what you would do was work on a side project maybe or do an internship. You say, "Okay, let's try building a Twitter clone," or, "Let's try building a parking system," you know, whatever.
Your imagination is your only limit. So you were trying to reproduce a solution, something that was already existing. I think it's pretty much the same now, but better.
You don't need to be an entrepreneur or a founder to start building a product. You can look at your life and see what problems you have. You can ask friends, ask your family, ask to your communities locally or online.
So you go out there and look for a problem to solve with your skills, of course. A real problem, not a technical problem, something that is really human.And then you start talking to people. Start thinking about it.
Okay, this is the problem I have, and I have an idea on how to solve it with a product, a tech prod- product, of course. And I have a set of hypothesis that I need to validate.
You start talking to people, doing interviews, gathering insights about how they behave and what their needs are.
Maybe you can do this while reading Continuous Discovery by Teresa Torres, which is one of the best books on the topic. Once you do this, you can start prototyping.
Really, you can do this with Lovable or with Zero or Rapid. Nowadays, it's so easy to build a prototype.
Then with the same people you interviewed before, that you talked before, you, you carry some usability tests to see how people use the software, to see if it- if it- if it makes sense, if there are any...
if, if there's any friction, if you're not working.
Maybe you can create a landing page and show it to the people you're talking to and ask what they think about what the product is going to solve and how, how it's going to he- help them.
Once you have a good understanding of the direction, you start building it properly with, uh, Cursor or whatever like... whatever you like in an AI-assisted way.
You build your first version, your minimal viable product, and you ask people to become beta testers, so they can use it. You set up monitoring, the analytics, so you can see what's working and what's not.
You set up weekly calls with these early customers or users to get their feedback. In the worst-case scenario, you have learned a lot about how to run a product.
You have learned about the end-to-end process of developing a product.
In the best-case scenario, you may have actually found something that people need, something that they will pay for, and then you can become an entrepreneur. That's also an option.
And really, it is- it's not a coincidence that at Postdoc, the pioneering company that made the product engineer role famous, they mainly hire people that were working as entrepreneurs before.
That tells you something about it, right? Once you've done this, you can start looking for companies.
I would say the best way is to look for early-stage startups where they would love to have people who understand what it takes to build a product and who are not scared to get out there and talk to customers, people who are entrepreneurial and who are generalists with a broad skill set.
Portfolios also have completely changed now.
It doesn't make any sense to have these websites where you list all the technologies you know and that you work as a front-end developer and back-end developer developing this or that feature. Really,
no one cares anymore. It will be m- much better to have a website where you describe how you tackle product problems, um, maybe like a case study.
You write about it, and if you want, you can even talk about this on social media, on X or LinkedIn.
It's always a good thing to kind of position yourself in your niche, to write about this stuff, so other people know what you're doing and recruiters come to your profile and see you have this kind of thinking.
A lot of companies are not hiring junior developers because it's difficult to train them, and there's a high supply of senior software engineers. But again, not all senior developers can be product engineers.
They're stuck in their ways and only focus on their tech side. There is an opening for junior product engineers who can work with the startups being built right now in the AI space.
I'm pretty much convinced that once you prove you can work like this, a lot of opportunities will start to open up for you. Now, if you are a manager or a leader listening to this, this part is specifically for you.
Charity Majors said something that should keep every engineering leader up in the... up at night. "By not hiring and training up junior engineers, we are cannibalizing our own future."
AWS CEO Matt Gorman called replacing junior developers with AI, "One of the dumbest things I've ever heard." So what should you do instead? First, redefine what a junior role looks like.
Stop hiring juniors to write boilerplate. Hire them to solve problems. Put them in front of customers. Let them own the full loop, from understanding the problem to shipping a solution and measuring if it worked.
Second, make failure safe. If juniors can't fail, they can't learn. Create an environment where trying something and being wrong is not just acceptable but expected. Third, pair them with AI, not against it.
Yeah, it's a force multipliers for juniors. They can learn faster, prototype faster, get feedback faster.
They still need mentorship from humans to develop the judgment that AI doesn't have, the product thinking, the system thinking, the understanding what to build and what not to build, and also understanding why.
But really, AI can really help them getting better feedback and speed up the learning. The companies that will do this, they will have a huge advantage in your, in your next five years,
and the companies that don't do this, they will be fighting for getting a good product engineer. If you want to start this journey, let me give you three books that I think are essential for the path I described.
Continuous Delivery by Teresa Torres. This is the book for learning how to talk to customers, validate hypothesis, and make product decisions based on evidence instead of assumptions.
It's the foundation of the discovery part. Then the all good Extreme Programming Explained by Kent Beck.
This is about the development process itself, how to work in small increments, test-driven, uh, development, shipping continuously, and it will really teach you how to build things the right way.
Also, on the UX side, we have Don't Make Me Think by Steve Krug. Um, it's all about understanding how user actually interact with what you build.
It's short, it's practical, and it will change you how you think about design, even if you're not a designerThere are way more books I could recommend, like The Lean Startup, Clear Architecture, Continuous Delivery by Dave Farley, Lean UX, and I, I will put all of them in the, the show notes.
Um, there are also great newsletters to keep up to date with what's happening in the world, like Lenny's Newsletter for the product side, The Pragmatic Engineer for engineering, and PostHoc's Product for Engineers Newsletter, which kind of work as a bridge between the two worlds.
So yeah, that's it really. Whether you are a developer wanting to get started or a manager thinking about your hiring strategy, I hope this made you see the opportunity here.
There is a lot of talent out there right now, people with fresh eyes and fresh brains who can be shaped into the product engineers of the future.
There are companies that are, that are making the mistake of ignoring this. Don't be one of those companies. And if you are a junior developer, don't wait for permission. Start building. Start from the problem.
The tools have never been more accessible, and the opportunity has never been bigger. If this episode was useful, please share it with another junior developer or with some of your managers and juniors.
And also, if you like it, please drop a review if you can. It really helps a lot getting new people to discover the show.
Um, if you want to keep the conversation going, you can find me on LinkedIn at, with my username pepposilletti, and, you know, I'm happy to discuss this topic with you and, you know, answer your questions.
Thank you very much for listening, and bye. The Product Engineer's Podcast. Wow.