On Evaluating Seniority

I’ve been working in the tech industry for over 15 years, and I’ve seen many different ways to measure seniority. Some are more scientific, some more subjective, and often they’re a mix of both.
Still, there are some things I’ve found that never fail to reveal the truth. Let me explain.

The Spark

Every senior I’ve ever met had a spark for learning and growing in their area of expertise. I didn’t think much about it until recently, when I started doing hiring interviews. There was a clear difference between those who were excited to learn and grow, and those who weren’t. That got me thinking about my past experiences working with junior, medior, and senior developers.

What I realized is this: every time a senior developer was presented with a better solution to a problem they had already solved, using better technology or a better approach, you could almost see the spark in their eyes. The excitement of learning and growing.
First comes the realization,the “Aha!” moment. Then a kind of playful internal laughter sparked by the dopamine of learning something new. Then a rewind through memories: where could this new knowledge have been applied? And finally, an honest feeling of gratitude for the opportunity to learn something new.

The best people I’ve met in the industry all had this same trait. The best companies I’ve worked with shared this culture. The best teams actively fostered and cherished it. And the best results were achieved when this culture was present.

The Fall

Funnily enough, this is also the same behavior junior developers exhibit. Working in IT can be overwhelming, and the only sane way i found on how to handle it is to accept new knowledge as a gift.

Somewhere along the journey of becoming a better developer, often something changes, and that spark shuts down. Sometimes its a role change, sometimes just a saturation with learning, sometimes its just getting drunk on past achievements.

You start to see new knowledge as a burden, and the easiest way to deal with it is to ignore it. You begin to feel like you’ve learned enough. What worked a few years ago still works, so why change? Sometimes it’s getting drunk on past achievements,you made the right call a few times, so you stop questioning your decisions. Sometimes it’s ego,when you’re leading a team or managing a project, you believe you know best. Sometimes it’s politics,developers stop speaking up because they’re afraid of being wrong or not fitting in. They conform to their superiors, avoid rocking the boat, and abandon their own ideas to keep the peace. They stop learning because it takes time and effort, and the rewards aren’t immediate. Or simply because the environment doesn’t support learning. Not the last, but sometimes it was just the money that was driving them.

The Lie

I recently read through an interesting thread that posed a good question:
If the world looked like the movie Invention of Lying (2009) from Ricky Gervais, which industry would be the least, and most, affected by the lack of capability to lie? I wont go through the details of the thread, but one of the answers for the least affected was engineering, which made me think about how much of our decisions is affected by politics, and how much of our decisions is affected by the lack of capability to lie.

In theory, engineers are working with facts, best facts lead to best results, and best results win with empirical evidence.
In practice, its all politics. From high level to low, its all about who knows who, who gets the better deal, who gets the promotion, who gets the raise, who gets the credit, who gets the blame. And dont get me wrong, it is like that in every industry. Its just that IT is constantly, year by year, taking over more and more of the GDPs, and more and more of the decisions are being made in the IT industry.
From military applications, to financial applications, to healthcare applications, to education applications, to government applications, to every application in between, IT is taking over more and more of the decisions. And consequently, the more it grows, the more it affects the politics, and the more politics will affect the IT. So saying that engineering would be the least affected by the lack of capability to lie is far from the truth, especially when considering the impact that tech has on our lives.

On a smaller scale, its the same story. From a predominantly geek and nerd driven industry at its beginings, to a high achievers big salary driven industry today, IT is no different than any other industry. Competence is measured in political skills, as much as technical skills. The ability to navigate the political landscape is, in some environments, more important than the technical skills.
As an engineer, staying on the side of the truth and integrity is often not easy. You will be asked to do things that are not technically correct, or not in the best interest of the company, or not in the best interest of the customer. Short term, it might be easier to just go along with the flow, and do what is asked of you. Long term, it might be more worth it to stand up for the truth and integrity, and risk being seen as a troublemaker.

If you are doing this job for the money, you will be have no issue with this. But if you are doing this for the love of the craft, you will never be able to truly enjoy your work in this kind of environment.
That is because your progress and learning becomes limited by the need to conform to the politics. You will grow slower, you will be less likely to take risks, and you will be less likely to innovate.
You will be less motivated, and in general care less about the quality of your work.
Every senior I ever met was aware of this, and often the main cause of their work dissatisfaction stemed from this.

Someone once told me, you can go a long way by just being honest, and except keeping your integrity, this will do wonders for your knowledge and skills. Value honesty, value integrity, knowledge, and pull your self out of the rat race.
Soon you will meet people who will be grateful for your honesty and integrity, who will appreciate your knowledge and skills. Best solutions come naturally when you work in a team that values truth and integrity over politics and deals. The impact of fostering this culture is immense, and the rewards are far greater than the risks.

A senior will choose his battles wisely, stay on the side of the truth, present his arguments with facts and data, and let the best solution win.

The Truth

There are some undeniable truths about being a developer:
– Jobs change. Companies and projects come and go.
– The technology we use evolves,frameworks, languages, platforms, tools, libraries… all come and go.
– The fundamentals of software engineering remain.
– What you truly carry forward is experience, knowledge, skills,and the people you’ve worked with.

Let me add a slightly pretentious hot take,some truths about being human:
– Life happens while we’re busy making other plans.
– We go through phases. We change as we age, as circumstances shift, and as our priorities evolve.
– Knowledge and experience don’t stack linearly, each new experience reshapes how we see past ones, making them more valuable.
– And the more experienced someone is, the less eager they are to judge.

The Experience

IT is also a strange industry. It grows so rapidly that there are always more people with less than five years of experience than those with more than five. This isn’t inherently a problem, but it can easily create confusion.

A common rule of thumb usually looks like this:
– Less than 2 years: Junior
– Between 2 and 5 years: Medior
– 5 years or more: Senior

Compared to other industries, this is a very short time to be considered “senior.”
From what I’ve seen, having a CS degree doesn’t matter much, it’s more about the experience and knowledge assumed to be gained in those five years. A CS degree might help land your first job, improve your CV, or secure a better starting salary, but it’s far from a guarantee.

The point I’m getting at is this: the average working career is around 40 years.
If you’re already “senior” after 5, what do you do for the next 35?
How do you compare a developer with 5 years of experience to one with 20?

What about comparing someone who changed three companies in five years ,agency, startup, corporate, worked with multiple cloud providers, languages, frameworks, roles…, to someone who spent 20 years at the same company, using the same technologies, in the same role, with the same colleagues?

The Question

Distinguishing a junior from a senior developer is easy, the knowledge gap is obvious.

Distinguishing a medior from a senior is much harder. It’s not just about knowledge, years of experience or job titles. It’s about how problems are approached, how difficult situations are handled, how decisions are made, and identifyings the driving force behind their work.

There’s no simple way to measure this, and no easy way to quantify it. But a lot can be revealed by asking:

– Is there a visible spark for learning and growth?
    Are there personal projects? Is there interest in learning new tech outside of work?

– Is the focus on the bigger picture, technology and people, or just on details and processes?
    Ask about their previous work experiences, dig deep on processes and frustrations, and see if they are able to see the bigger picture.

– How eager are they to judge?
    Ask for their views on projects failing, responsibilities, team dynamics, what they like about working with people, and what they don`t like.

Hope this helps you think through what you are looking for in your colleagues, and ignite the spark in you and your team.