Mid-level folks also have a fairly solid knowledge of the tools of the craft. You can distinguish the junior from the mid-level largely by this amount of confidence she has in her abilities. The mid-level dev knows she can produce good code fast. She’s not stumbling over Git rebase errors for hours. She’s not confused about the difference between Array.map and Array.reduce any more. She mostly just cracks on with the work. Consequently, the mid-level developer is beginning to feel hunger for more interesting challenges.

Where the junior developer’s pitfalls are largely problems of ignorance, the mid-level engineer’s pitfalls are largely ones of knowledge. A junior developer might lose a week of her time because she read a Stack Overflow answer that said some framework will solve what she thought her problem was. Days later, she finally realises that her initial premise about the problem was wrong and that the framework doesn’t actually do what she wanted it to do at all. A mid-level developer is much more likely to understand the immediate problem correctly and then try to solve the class of problem with a clever abstraction. All that hard-earned knowledge and ability comes in handy as the mid-level developer starts exploring just how fancy of a solution she can come up with for the problem she’s trying to solve.

The pitfall here is priority. Yes, the mid-level developer often has the curiosity and ability to spend hours and hours solving some problem to a very high degree of technical correctness, extensibility, and general panache. However, the senior person usually has the visibility into the overall problem space to decide not to solve this problem at all. Where the mid-level person spends days crafting a clever solution, often a senior person will come along and realise that they can avoid doing any of that work with a small hack or workaround. The senior person isn’t trapped by their curiosity the way the mid-level person is.

Overall, in any technical team, the majority of the code in the codebase will tend to be written by mid-level people. The mid-level engineering level is special because it features a combination of high coding ability and high enthusiasm for new problems. The relationship between senior developers and mid-level developers tends to be that the senior person lines up some work for the mid-level person to tackle. Their conversations tend to be about how the big pieces fit together. About the why the team is doing the work more than how to actually do the work.

There’s something special about mid-level engineers. That is — many engineers never make it beyond mid-level. At mid-level, you start to see human limitations coming into play a bit. The problems mid level engineers face are sufficiently harder than what juniors face such that some mid-level engineers will be at their peak. The level of complexity goes up significantly when you transition from “how do I do this work?” to “how does this work fit into the bigger picture?” If you didn’t learn your tech well enough (in the junior sense described previously), you’ll struggle to progress beyond mid-level.

At mid-level, many engineers divert into alternative paths. Some drift toward people management, if they’re at a company that permits managing people before becoming technically senior. Some move into project management. Some move into product management. Some drift toward design-forward frontend roles that don’t require greater technical depth.

For the developers who stay on the One True Way™, the duration of their time at mid-level will be spent building things. Mid-level developers have interesting workloads in that many of their tasks will be identical to the sorts of tasks that junior folks would have to take one. The difference is that the mid-level coder handles such tasks without needing any support. Mid-level developers work also shares a lot of common ground with senior team members, except that the senior engineer knows the plan and is driving the work in the right direction, where the mid-level developer is following that lead and trying to make sense of how the work all fits together.

Mid-level engineers usually receive support from senior folks that looks something like: “I have a question about the API we need to offer for our data ingestion endpoint. Why are we asking for a JSON object instead of just accepting the four arguments we know we need?” To which a senior engineer might have a response like, “That JSON object exactly matches the output of another piece of the system. If we accept it as-is, we don’t have unpack and repack it along the way. Also, if that object’s schema changes, we don’t have to maintain this code because they’ll be using a shared definition.”

The key point in this hypothetical design discussion is that the mid-level knows what code to write. At this point in her career, she’s wondering about why to write the code. She’s thinking ahead trying to understand how the pieces fit together and how to build the whole system in a good way. Likewise, she doesn’t yet have these answers. She’s working with a senior engineer who is already thinking through those complexities. In the ideal case, the senior engineer has the time and interest to explain things and share context until the mid-level developer is operating with as much clarity as possible. Good senior engineers help smart mid-level folks move forward very quickly.

The sort of tasks I’d expect a mid-level coder to be able to handle

• Create an adapter layer that helps this piece of code communicate with that API
• Work with the designer to implement this complex UI feature, keeping an eye out for design choices that will be hard to implement
• Walk through the whole codebase adding request logging to every endpoint and API

These mid-level tasks have significant ambiguity but they’re also scoped within a project. They’re not solving key problems themselves, instead they’re a piece of a larger thrust of work. This is a key difference between mid-level and senior engineer tasks. Senior folks will be accountable for outcomes, where mid-level and junior folks will be accountable for subparts of those outcomes. As the mid-level dev progresses, she will move closer and closer to delivering work that solves a whole problem.

The sort of tasks I’d expect a mid-level dev not to be able to handle

• Choose a technology and design an API with it that satisfies a number of business constraints; implement that API efficiently, migrating existing data as necessary to achieve a clean implementation
• Debug and fix a data inconsistency issue that seems to span several systems, each maintained by different teams
• Lead the development of mobile apps based on existing desktop interfaces, choosing a tech stack that maximises code re-use

Where the mid-level developer falls down is where the ambiguity is too great for them to manage it. This might mean organisational or business ambiguity. Or it might mean technical ambiguity of a sort that exceeds what that mid-level engineer is ready to handle. The difference between a mid-level and a senior developer is almost entirely in her ambiguity management skills. In other words, some technical details that are ambiguous to a mid-level would be obvious to a senior developer. Where the mid-level engineer gets overwhelmed by the ambiguity and can’t make progress, the senior developer will stay cool and find their way through. Where the mid-level developer says to herself, “Oh no, I don’t know what to do next,” the senior developer is saying to herself, “Time to figure out the next piece of the puzzle.”

On the Cusp of Senior

As a mid-level developer is heading for seniority, some key behaviours start to change. The most noticeable one will be the type of questions they ask.

Junior engineers will mostly ask “how” questions. “How do I use this library?” “How do I debug the error message?”

Mid-level engineers will tend to ask “why” questions. “Why should I implement this code this way?” “Why do these parts of the system fit together this way?” “Why aren’t we doing that other work before this work?” Mid-level engineers grow by tuning their radar for how decisions are made. For priorities. For tradeoffs.

Tradeoffs and priorities are the senior engineer’s life. Their questions tend to be “What happens if…” and “How could I know if…” questions. “What happens if we spend a week solving that caching problem? Will we be able to deliver the whole solution on time?” “How can I know if this data consistency problem is here or if it’s actually upstream of the system I’m currently looking at?” Where mid-level engineers are often asking for answers, senior engineers are usually looking for means to answers. They’re trying to work ahead of the current situation, figuring out not just what comes next but at what cost relative to everything else that could come next.

Mid-level engineers have some hard-won technical abilities. They earned them along the way out of juniority. They’re raring to dive into complex problems and build elegant solutions. One of the milestones that mid-level engineers have to reach before they can turn senior is seeing exciting technical opportunities and carefully deciding what work not to do. Where the mid-level engineer might fascinate for hours or days (or, in rare cases, months) on a difficult problem, a senior developer will pause to consider the costs to the team, the project, the codebase. Mid-level engineers usually don’t have enough context to make these kinds of tradeoffs. As they begin to sharpen their senses for these kinds of things, they’ll start to notice other engineers spending time on things they shouldn’t be. They’ll start to see places in their own work where they wasted time solving the wrong problems.

Update: A super common mid-level engineer trap is lack of people skills. Many mid-levels will struggle to transition smoothly into senior status because of underdeveloped interpersonal skills. Maybe she gives super harsh feedback that is technically correct, just soul crushingly blunt. Maybe she avoids key meetings because she doesn’t like to waste time talking and prefers only to write code and solve problems. Maybe some aspect of her personality is holding her back (e.g. excessive negativity, lack of time management, excessive egocentrism). I’ve seen mid-levels struggle with each of these.

It’s extremely common for companies to fail at mentoring these people. It was pointed out to me by a very successful engineering director that my posts here carry the same bias the industry has — we spring the expectation of people skills onto engineers without ever calling them out explicitly. We just assume that once you’re super technical, you’ll sprout wings and learn to fly, too. It’s not fair, but it’s super common. The mid-level engineer trending toward senior needs these skills. She needs to be able to give critical feedback with compassion. She needs to be able to effectively run meetings and execute planning. She needs to be able to coordinate people. Technical skills are the key skills of juniority. Across her time at mid-level, the developer has to continue to level up her technical skills while also starting to acquire the leadership skills she’ll need to succeed as the head of a team.

At some point, she’ll have all the technical chops she needs to solve most problems she comes across. She’ll have the ability to discover answers where she doesn’t have them yet. She’ll be able to think critically about the tradeoffs between different approaches to solving a given problem. She’ll be able to think about how to support junior and other mid-level engineers as they progress through the subparts of the work. She’ll be able to deliver technical solutions leveraging all of the above. With a couple successes at doing this, she’ll have proven her track record enough to say it wasn’t just luck. At that point, the engineer will have attained the rarified air of seniority.