Should You Still Hire Junior Developers?

I've recently had the opportunity to mentor a few students from varying universities across the US. And what I found is that a lot of these kids have a lot of drive and a lot of ambition. You can see it in the way they interact, not only with me but with the people around them. You can see it in how they network with recruiters, or directly with hiring managers and team members on LinkedIn. They're not just trying to get a job. They're trying to start up their careers and do things that benefit them and benefit the company they land at.

And at the same time, hiring people like them has gotten harder to justify on paper. We see it on social media and in the media in general: more and more companies aren't willing to hire less experienced developers. More and more of the reasons given come back to artificial intelligence. There's a growing argument that you get a better return on investment by hiring seniors who know how to use AI.

So should you still hire junior developers? I think yes, and here's the short version of why: they bring drive, they bring viewpoints you don't already have (increasingly including a better grasp of AI-assisted development than your seniors), and the right one lifts the morale of the whole team. You can run a company without them and be fine. But in another sense, you're hurting yourself, because you're passing on a person who might be able to help your company way more than you think.

---

Why are companies not hiring junior developers?

The pullback is real, not just a feeling. SignalFire's State of Tech Talent report found that new graduates made up about 15% of Big Tech hires before the pandemic and are down to roughly 7% now. And researchers at Stanford's Digital Economy Lab, in their "Canaries in the Coal Mine" analysis of payroll data, found that employment for early-career workers aged 22 to 25 in the most AI-exposed occupations has declined since ChatGPT arrived, while older workers in those same occupations kept growing.

Worth noting: that same Stanford team is careful to say they don't see widespread, economy-wide job displacement from AI. The squeeze is landing specifically on young workers in exposed roles. Which is exactly the group I'm talking about here.

So the notion is: yes, you can go around this group and your company will be fine. I just think the companies doing it are giving up more than they realize. Here's what I keep seeing these people bring.

---

They have something to prove

Drive and ambition. A less experienced developer has so much to prove. They want to prove to you that they're worth keeping around. They want to prove that their skills are worth it. They want to prove to themselves that the last few years at university, or whatever they were doing, actually benefited them. They want to push themselves.

Think about the late Steve Jobs. We know a lot more about him now, but I remember when I was younger, and I know a lot of people had the same sentiment: you could just see that he had this ambition to push out new, good, awesome products. And so we flocked to him. We'd say, let's listen to him, let's trust him. Because he had that drive.

The same thing is true about less experienced developers when they come in with all that drive. They're going to have something to prove to you one way or another. They're going to have different ideas and different points of view. Give them the opportunity to push themselves. You don't know what you're missing by just having the same people show up day after day. Having someone come in and be the catalyst, be the change on a team, is genuinely beneficial from time to time.

---

They see things you don't

I can't overstate how many times I've worked with somebody new and they came in with a viewpoint that completely changed the one I'd held previously.

Recently I was speaking with somebody about what AI can do when it comes to development. This person is an AI bull, very much believes we should be using it in a lot of different ways. We got on the question of how they use it in their real workflows, and they returned an idea where I thought: whoa, that makes a lot of sense. I thought about it more and realized my own workflow was already about 90% of the way there. If I fine-tuned the last 10%, I'd have even stronger workflows than I do now. So I updated it and did exactly that. (I've written before about what AI actually does to a development team's speed, and this is the pattern: the gains come from people showing each other better ways to use it.)

Less experienced developers come in with the same effect, because their knowledge base formed in a completely different environment. Recently I heard about a student who spent the last two years of his college experience using AI for most of his development. He went on to understand architecture way better and way faster, and got a job. And when he got there, he started explaining to the team why and how they should be using AI. He came in and taught the team what it meant to build out skills and agents for their development practices. There were seniors there who were blown away by what this stuff could do. Everybody got together, put a plan together, and created a better process for using AI in their development. That all started because of a kid who understood AI better than the seniors did.

And I don't say that as a knock on seniors. Your more experienced developers have lives outside of work. They don't always have the opportunity to go study the latest trends and the latest features. Some of them do what they can while they're at work, and that's reasonable. Bringing in somebody who lives and breathes this stuff boosts the whole room: people start wanting to learn because they want to push themselves to understand it too.

---

One person can change the morale of a team

The right hire will do their absolute best to go around, introduce themselves, talk with people, get involved in meetings, put themselves in different scenarios and situations. And slowly, that person becomes the reason more people push themselves. They get involved more. They take ownership of things.

We know somebody who was a mid-level developer and got hired somewhere where the manager had a hard time getting the senior developers to take charge of the sprint ceremonies, the stand-up meetings. This mid-level developer came in and said, yeah, I don't mind doing it, I think it'd be great. She took charge, and she started asking personal questions during stand-up to help people feel better. There'd be a question of the day: what's your favorite sport, what's your favorite movie, what's your favorite cereal.

And you started to see that people were happier. In their end-of-sprint retrospective, people actually said they were feeling happier, because they felt like they got to know everybody better. Not that people didn't know each other before, but it felt like there was more of a conversation instead of just clocking in and clocking out. That mattered even more because it was a remote-first company. She was the catalyst. Now, she was mid-level rather than junior, but it's the same effect I'm describing: the newer person with energy becomes the change in the organization.

---

What about trust versus knowledge?

Simon Sinek tells a story about getting to ask the people who select members for the Navy SEALs how they pick who joins their top teams. They drew him a graph: performance on one axis, trust on the other. Everybody wants the person who's high performance and high trust. But those people are few and far between. The one they avoid at all costs is high performance, low trust. And Sinek's point is that the SEALs would rather take someone of medium performance and high trust than a high performer they can't trust. You can watch him tell it in his "Performance vs. Trust" talk.

The framework Simon Sinek describes the Navy SEALs using to select team members, from his "Performance vs. Trust" talk. Performance can be taught; trust has to be earned.

The way I think about that for hiring: a junior developer is often exactly that trustworthy, hungry person whose performance simply hasn't caught up yet. Performance is the part you can teach. And when you combine people like that with everyone else on your team, you don't end up with a semi-knowledgeable team. You end up with a very knowledgeable team where the knowledge is spread out across it, and that benefits the team longer term. It's the same balance I think about when I put together an embedded team for a client: you want the trust high everywhere, and the knowledge distributed, not concentrated in one person who may or may not stick around.

---

Finding the right one is the actual work

Yes, it's difficult to find the right ones. That part I won't argue. But if you do your due diligence (I've written about what I look for when hiring a developer), you'll probably end up with an even better team than you thought you could possibly have.

I often think about what it would have been like if I hadn't been given a chance or an opportunity.

And for those who are potentially looking for jobs right now: push yourself to be this type of person, because these are the kinds of people we like working with, and the kinds of people everyone likes to work with. Most people would agree they don't really like working with downers, or people who are egotistical or mean. People like to work with people who are friendly, who are cheerful, who like to joke around and discuss things, but who are just as technical and knowledgeable at the same time.

These are working thoughts, and it's possible I'm wrong about some of it. But from mentoring these students and watching what the right new hire does to a team, I think this is more true than not.