Today I woke up and chose violence. Not physical violence, mind you; no, I want to talk about the conflict of interest when it comes to experience in the Software Development field.

A Junior, Medior and Senior walk into a bar...

If there is a punchline here, it's probably that you won't often find software developers / engineers at the bar, but that's beside the point. I want to take a moment to look at and examine the different levels of seniority. What makes someone a senior in their field? Of course you can do a quick Google search and find "X years of working experience". But is that a valid metric? Before we dive into that question however, let's make sure we're all on the same page.

Junior

Someone fresh out of college (no, not bootcamp, sorry peeps), ready to tackle the world after building their eighth working calculator or something calculator-adjacent. Juniors often still need help navigating the workplace, learning not just internal structures and systems but also etiquette. Their work needs proper supervision and checking, not because it is inherently wrong, but because they might have missed unspoken rules or because their solution could be improved with a little trickle of new knowledge. They will trip and fall, and learn when they get back up. Preferably without being yelled at.

Medior

Depending where you are in the world, you might not have heard of a "Medior software developer or engineer". That's because... well... it doesn't really exist. Mediors are your run-of-the-mill developers, they know their skills and their tools. They have run head-first into walls enough times to know what works and what doesn't beforehand. They will communicate and work well with others, work in teams and support each other.

Senior

These are the gray-beards, no, not literally. Often the senior is the person who has been somewhere the longest, or at least as far as the original metric is concerned. They will also have other duties besides writing code, like teaching juniors the ropes, communicating with stakeholders (both internal and external), and sitting in on project and architecture/strategy meetings. These people are also the wizards of the team; if you ever looked at code and thought, "What the heck is happening?" then yeah... that's probably their work, resulting from a 10-minute crunch because some stakeholder decided they wanted something else at the last minute.

Let's talk metrics

So how do you keep these 3 apart? Well, that's the million dollar question, ain't it? The answer is a bit more loaded than we would like it to be.

Traditionally, we look at employment; how long someone has been in a development role. There is something to be said about this metric, namely: with time comes opportunity, opportunity breeds experience. However, experience is not a one-size-fits-all kind of deal. As the title suggests, there is experience in width and in depth. Let me introduce you to two fictional characters (and their fictional employers):

Bob is a 40-year-old man who has worked his development job at Asys for the past 20 years. He started as a Junior right out of college and was hired right after his internship. He has mostly worked in C# and occasionally in C++ for his entire career building WinForms applications, but he's also skilled in calling and managing parts of the Windows ecosystem, making use of hardware acceleration and leveraging computational power to finish jobs as quickly and efficiently as possible.

Then we meet Markus. Markus is a 35 year old with several short employments, all in a software development role. His tenures have lasted just shy of 3 years per employer, and he is currently working at Bsys on their insurance dashboard in Blazor. Markus has worked with many different project types, like WinForms, Blazor, APIs, SDKs, and mobile development. Besides that, he has also successfully implemented Agile workflows, has experience with cloud products, and has assisted in streamlining several internal company processes. 

The difference between these two is as clear as night and day, yet both are experienced developers in their fields. 

Bob has nothing to prove when it comes to depth. He knows his domain, his product, his stack and the haunted little corners of the Windows ecosystem where documentation is a half-formed suggestion. If something breaks in that world, Bob probably knows where to look before the error message has finished blinking. Markus has nothing to prove when it comes to adaptability. He has walked into different teams, different products, different architectures and different company cultures. He has had to become useful again and again, each time without the luxury of already knowing where all the bodies are buried.

But put them both on paper, and suddenly the story changes. Bob reads as stable. Loyal. Reliable. A safe pair of hands. Markus reads as restless. Risky. Someone who leaves after a few years.

And that is where the problem begins.

Because neither of those readings is a skill assessment. They are comfort assessments. Bob makes people comfortable because his experience looks familiar. It fits neatly into the classic story of professional growth: start somewhere, stay somewhere, learn the system, become the person people depend on. Markus makes people uncomfortable because his experience looks fragmented. There are too many systems, too many employers, too many restarts. But those restarts are also the work. Every new codebase, every new team, every new architecture forces a developer to rebuild context quickly. That is not shallow experience by default. Sometimes that is the entire skill.

A test of skill... or fitting a skill?

So, you might be wondering: How do we test what level these guys are at for the position we are hiring for?

The real danger is that companies often do not test experience. They test similarity. Does this person look like the last successful hire? Did their career path follow the expected route? Do they use the same words we use internally? Have they solved problems in a way we already recognize?

That is understandable, but it is also limiting. Because the more specific your definition of experience becomes, the more likely you are to mistake unfamiliar experience for missing experience.

So where does that leave Junior, Medior and Senior? Probably still at the bar, arguing over whether the production bug is caused by a race condition, a bad deployment or someone changing a configuration value three months ago and never telling anyone.

But more seriously: I do not think seniority should be treated as a number on a timeline. Years matter, of course they do. Time creates opportunity, and opportunity creates experience. But time alone does not tell us what kind of experience someone has collected. Some developers become deep wells. They know a product, a domain, a stack or a system so intimately that they can hear when something is wrong before the logs start screaming. They are the people you want near old, critical, complicated systems where one tiny change can summon the rats from under the floorboards.

Other developers become wide rivers. They have moved through different teams, different stacks, different businesses and different types of problems. They may not know every hidden corner on day one, but they know how to enter unknown territory, find the patterns, ask the right questions and become useful quickly. Both matter.

The mistake is pretending that one shape of experience is automatically more mature than the other. Bob is not better than Markus because he stayed. Markus is not better than Bob because he adapted. They are different answers to different problems. So maybe the better question is not: “How many years of experience does this person have?”

Maybe the better question is: “What shape does their experience have, and does that shape fit the problem we are trying to solve?”

Because sometimes you need the deep well. Sometimes you need the wide river. And sometimes, if your project is truly cursed, you need both standing next to each other, staring at the same legacy code, quietly wondering who hurt the person who wrote it.