Where do companies expect experienced engineers to come from?

An early-career engineer might start with a bug fix, a small feature, or a clearly scoped operational improvement. As they develop, they take on work with more scope, more ambiguity, and more people depending on the outcome. Eventually, they can take a business requirement, work out what it means technically, make architectural decisions, and drive a project across a team. There is a progression between those two points. A degree or a bootcamp can help someone get started. Working on a real team gives them opportunities to develop that initial preparation into experience. AI can help them work through problems along the way, but it cannot substitute for taking responsibility for a change, seeing how it behaves in production, and learning from the people who depend on it.

I liked the way Amazon approached this when I was there. At the time, the junior hiring model I worked with didn't bring in L4 engineers from industry; it developed junior talent through the internship pipeline and converted successful interns into full-time engineers. Teams could see how someone approached actual work before making an offer, and the engineer had an opportunity to demonstrate what they could do.

That commitment extended into coaching after someone joined full-time. An engineer starting at L4 could grow into L5, L6, and beyond as their scope and responsibility increased. Getting someone through the door was the beginning of that investment. We have to keep developing people as they take on harder problems and greater ownership, rather than assuming the hiring process delivers a finished engineer.

There is also a tendency to talk about junior engineers as if their entire value arrives years later. Strong junior engineers can take on smaller features and bug fixes, reducing the load on the rest of the team. They bring a new perspective. They ask questions that people who have been inside the organization for years may have stopped asking.

They can also expose gaps in how a team works. Onboarding documentation and setup guides have a way of looking perfectly adequate until someone new tries to follow them. A regular flow of interns and junior engineers gives a team reasons to revisit those assumptions and improve the material for the next person. Those contributions don't remove the cost of supporting someone early in their career. They belong in the calculation alongside it.

I understand the argument for assigning work to AI that a senior engineer might previously have handed to a junior. If an experienced person can use a tool to complete that work efficiently, a manager has a reason to consider it. That work still needs direction, review, and integration. More importantly for this discussion, completing today's task and developing a future engineer are different outcomes.

A company can improve its immediate capacity while reducing its investment in the people it will need later. Both things can be true at once. AI may change the tasks that make sense for an early-career engineer. Companies still have to decide whether they will provide a path for someone to become experienced.

I wouldn't give a five-person startup the same advice as a large enterprise. A startup with limited headcount may need someone who can take on a difficult problem immediately. It may have very little capacity to supervise a new engineer. Hiring an experienced person can be the right decision.

Larger organizations generally have more room to invest in development. They have more teams, more kinds of work, and more ways to give someone useful responsibility within an appropriate scope. There are also teams where mistakes can have especially serious consequences. Security-sensitive work and critical infrastructure may require a different balance of experience and supervision. Those constraints deserve consideration. They don't explain why an entire large organization would stop building its junior pipeline.

Hiring experienced engineers means benefiting from development that happened somewhere else. That is a normal part of hiring. But if more companies depend on that approach while fewer provide the first opportunity, the industry is drawing from a pipeline it is doing less to replenish.

When teams are at capacity, internships and development programs are easy to cut. Supporting a junior engineer takes time from someone who already has delivery commitments, which is why that capacity needs to be planned in advance. A recurring summer internship program is a useful example: leaders know roughly when interns will arrive, so they can reserve time for supervision, identify suitable projects, and account for the commitment when making delivery plans. That requires alignment with leadership before the team is under pressure. A development commitment that disappears whenever delivery gets difficult will struggle to produce a consistent pipeline.

Amazon's updated guidance on the software engineer role in the age of AI makes a related point: leaders are expected to make time for their people to learn as the work changes, while keeping their focus on customer, business, and team outcomes. That guidance addresses learning across engineering teams, rather than junior hiring specifically. To me, the connection is straightforward: if learning is part of the job, we need to account for it in the plan. For junior engineers, that means making room for experienced colleagues to coach them as they take on responsibility.

Some organizations are making the hiring investment explicitly. IBM announced plans to triple U.S. entry-level hiring in 2026 while redefining those roles for AI. An announcement isn't proof of successful execution, but it is a positive signal that companies can respond to AI by reconsidering entry-level work and continuing to invest in people.

Turnover and changing business needs will eventually create demand for people with experience. Developing those people takes time. A company can't recover years of missed development as soon as a hiring need becomes urgent. Before eliminating another junior opportunity, leaders should have an answer to the question: where do they expect their experienced engineers to come from?