#103 - Training and Developing Junior Engineers

An open letter on training the next generation.

In the best case, an engineer comes out of university as a complete beginner. They can do calculations and they understand some mechanics, but they have a limited understanding of how professional work is actually carried out. This is not a criticism. It is how it has always been. I thought I was ready for the industry the day I graduated, and it took me fifteen years, and counting, to see that the field is deep enough that no single person masters all of it. If we’re lucky, we keep our lips above the water line.

So what do we do with the engineering graduates of today? How do we prepare them for the demands of the industry and our projects? And how do we do it while they work, integrated into the process of servicing clients?

The traditional route to professional competency involves doing the work and being corrected. You size a member, someone senior tells you it’s wrong, and you size it again. You frame a problem badly, watch a more experienced engineer reframe it, and over enough repetitions you start doing that for yourself.

But the correction loop was only half of it. The other half was watching. I learned as much from sitting in meetings as I did at my desk: watching senior engineers reason through a technical problem, handle a client, or decide what not to say. Some of the sharpest lessons came from someone saying less than I expected, because in that moment holding a card back was the smarter move. None of that is in a curriculum. It is hard to even describe, which is part of why it only ever transferred by being in the room.

There was no way to produce the work without doing the thinking, and no way to be near the work without absorbing how it got done. The practice happened whether you meant it to or not.

That apprenticeship model started to fray when more of the work moved into Teams and Zoom. COVID did not create the problem, but it accelerated it. Now AI is working its way into the day-to-day: we are not only removed from the room where the problem gets solved, we can now outsource the solving itself, to an extent.

A junior engineer can now produce a pretty clean analysis and a confident recommendation without having reasoned through any of it. The output looks like competence. Sometimes it is competence, but borrowed from an LLM. A beginner using these tools can produce work that looks as though an expert made it, and neither the beginner nor a busy reviewer can easily tell the difference. The danger is not that junior engineers use AI. Everyone is using AI now, formally or informally, and pretending otherwise is pointless. The cat is out of the bag.

The danger is that the reasoning can disappear.

A junior engineer can use an LLM to move from a vague problem to a polished answer without ever building the intermediate muscles: defining the problem, testing assumptions, checking edge cases, and deciding where their own competence ends. The work product may look better, but the apprenticeship loop becomes weaker because nobody can see which parts were understood, which parts were accepted on trust, and which parts were never even considered.

The lazy version of this argument is that I am an old man yelling at clouds. Every senior engineer in history has told junior engineers to think harder and read more. That is not what I am doing. The reason this moment is different is specific. The tools amplify whatever you bring to them. Bring real skill and they make you faster and sharper. Bring none and they let you sound like an expert while you are not, and they hide that fact from you as much as from anyone else.

Weak fundamentals used to cost you immediately because you could not produce the work at all. Now the cost is deferred. It buffers quietly until a real problem turns up, and the house of cards collapses with considerable reputational debris.

So the question is which fundamentals actually matter now. I think there are three.

Problem Solving from First Principles

The specific techniques change. The skill underneath them does not: taking a problem apart and working out what is actually being asked before you reach for an answer. Most of our real work is complex and runs over many steps, and we can use powerful language models to do large parts of this if we understand how to approach it. What decides whether that goes well is how you frame the problem and manage what the model has to work with. That is the art of it, and it is the most valuable thing we can develop in a junior engineer. A model will answer the question you give it. Working out which question and how to ask it is the job. This approach is atomic. It works for the smallest problems up to the largest.

Communication

The second is communication, written and spoken. The tools help with this, and that is a danger, because they tempt people to stop developing it. The output reads as acceptable on the surface and is usually a little dead underneath. In my experience, if I cannot explain something clearly, in writing or out loud, the problem is usually my own understanding, not my audience.

I have not always been able to do this and I am still short of where I would like to be, but the test holds: when the explanation will not come out clean, the work is not finished. Clarity does not mean having the answer. It means being able to say plainly where you are in the problem, what you know, what you do not, and what you would do next. At the senior end, being able to do that out loud, in front of a client or a room is a big part of the job.

Knowing Where Your Competence Ends

The third is more difficult to define. It is the ability to tell when you are out of your depth. The tools are good enough that you can work well outside your competence and not notice, because what comes out still looks plausible. I could write a convincing thesis on the atmosphere of Saturn, but I know as much about Saturn as I do about stain removal, which is an absurdly pathetic amount, I am told.

You cannot know what you do not know. You can build a rough sense of where the edge of your competence is, and the discipline to slow down and check when you have crossed it. That is mostly humility, and it is the one I am least sure how to teach.

---

These are the skills we need to promote. But how do we build them into a graduate without it landing as condescension? Nobody comes out of an engineering degree wanting to hear they have a lot to learn. I certainly did not. The degree is real and hard-won, but it is also, on day one, just the start. Saying that to someone without diminishing them is a difficult problem.

With the junior engineers I work with directly, this method seems to work for me. I hand them something outside their current reach, let them struggle, correct them if they need it, and trust them with more. The trouble is that this does not scale. It depends on a senior engineer with the time and the inclination, a team small enough to actually see and understand everyone, and work interesting enough to be worth the struggle. Many graduates get none of that. I am lucky enough to really enjoy working with the junior engineers on my team - that feeling may not be reciprocated but I think it is. Maybe.

What I am sure of is the part that cannot be handed off. You can use AI tools for almost everything now. You cannot use them to acquire the judgement that tells you when they are wrong. That you build yourself, slowly, by doing the work. You can watch someone else lift the weights all day, and you will not get any stronger for it.

So I will put the question to the people it actually concerns.

If you are early in your career, how do you want to be brought along? What has genuinely pushed you, and what has just been going through the motions?

And if you are more senior, how are you building this into your own juniors without either babysitting them or pushing too hard?

I don’t hear this topic being discussed beyond the usual corporate/HR channels so interested to hear what people think about this one.