Seniority Is Not What You Think

TL;DR: Seniority is not tenure, metrics, or green GitHub squares. It is the ability to understand trade-offs and recognize when a best practice stops being the best choice.

After being in the industry for around 12 years now, I’ve been part of many recruiting processes for senior engineering positions and have seen endless debates around this title. Whether the discussion is about recruiting, promotions, or self-assessment, it's often not clear how seniority is actually determined.

Even though seniority is subjective and varies across companies and contexts, I think we often look for it in the wrong places. So before defining what a Senior Engineer is, we might have to agree on what it is NOT.

What Seniority is NOT

• Tenure

  Experience matters. But there is a huge difference between having 10 years of experience and repeating 1 year 10 times.

  Using the same framework for years doesn’t automatically make you senior. You might be solving the same problems the same way, or working in a context that no longer challenges you to grow.

• Knowing the Latest Trends

  Staying up to date is definitely valuable. That said, memorizing the newest Next.js pattern or ECMAScript feature doesn’t make you senior.

  Junior engineers often know the latest trends extremely well because that is where they begin. They understand the how, but seniority is about understanding the why.

• Shipping Apps

  I think we can agree that if you are a software engineer, shipping is the baseline, not the ceiling.

  Most engineers can ship complex software by following documentation, tutorials, reading threads on Stack Overflow, or even just “vibe coding.” But shipping without context or experience often increases complexity instead of reducing it. The real distinction is quality.

• Arbitrary Test Coverage Targets

  Lately, I have seen a trend suggesting that senior engineers should always enforce high test coverage. But tests are not free. They are code, and like all code they require maintenance, infrastructure, and introduce bugs and complexity.

  Chasing an arbitrary percentage of coverage, say 80 percent because the higher the number the better, often leads to brittle, low-value tests that you not only have to maintain but also pay for.

  A senior engineer understands the trade-offs. Sometimes high coverage is critical. Sometimes it is wasteful. The answer depends on the team, the domain, the business logic complexity, the feature, and a bunch of other factors.

• A Green Github Graph

  Open source contributions are great. Side projects are great. But they are not requirements for seniority or competence.

  It is true that working on open source projects often requires the valuable skill of reading and understanding other people’s code, and sometimes strong architectural thinking. But it is also true that open source is filled with noisy pull requests that add little value, or contributions made primarily for visibility.

  Some of the most senior engineers you’ll meet have quiet profiles and years of impact in private systems you’ll never see. And GitHub is not the only version control platform out there.

What Seniority Actually Is

If it is not tenure, trends, or tests, what is it then? To me, it comes down to a simple word: understanding. Read carefully: not knowledge, but understanding.

Knowledge is knowing that something works while understanding is knowing why it works, when it works, and more importantly, when it doesn’t. This distinction does not apply only to software engineering, it applies to life.

Take chess as an example. Every beginner is taught to "develop your pieces toward the center." It’s a great rule of thumb (as are the points we discussed earlier). But a grandmaster might look at a specific position and move a knight to the very edge of the board because, in that precise context, that is the only move that works.

Seniority works the same way. It is not about memorizing principles or collecting patterns. It is about understanding them well enough to adapt them to reality.

And this is probably why seniority is so hard to measure, and why we often get it wrong. We try to reduce it to checklists, trivia, or technical quizzes. We ask about specific APIs, edge cases, or tools, as if recalling them from memory were proof of depth.

Imagine sitting across from a chess grandmaster and asking what the correct move is in a very specific line of a very specific opening. Even elite players prepare certain lines for particular opponents. They do not carry every variation of every opening in their heads at all times. If they hesitate or misremember a detail, would that make them less of a player? Of course not.

What makes them strong is how they read the position in front of them. How they reason. How they adapt when the game leaves preparation.

I think the same is true in software engineering. If you want to understand someone’s seniority, just have a conversation. Explore how they think. If they choose one approach over another, ask why. Listen to how they reason about trade-offs, constraints, and long-term consequences. Understanding reveals itself in dialogue, not in trivia.

And if you want to become a more senior engineer, the path is similar. When debugging, do not just fix the bug, understand it. When learning a pattern, do not just memorize it, understand the trade-offs. When adopting a tool, do not just follow the trend, understand the problem it was designed to solve.

In the end, seniority is not measured by how long you have played the game, but by how well you can read the board.

So perhaps the real question is not how many tools we know, or how many years we have accumulated, but whether we have learned to truly understand the game we are playing.