Hiring Devs - The Seniority Paradox

Post image
Photo by Polina Zimmerman from Pexels

In IT, there is a paradox when it comes to job titles. Somewhere along the way, the practice of linking job titles to a candidate’s (desired) experience became established in large parts of the market. This then created the now famous and omnipresent job titles like “Senior Software Engineer”, “Professional DevOps Engineer”, etc. In this blog post, I would like to explain the paradox around these designations and how I use them in the course of the talent search…

Job Titles in Software-Engineering

Job titles in software development have become merely irrelevant to me personally in my twenties, but I would like to try to decipher them a bit…

Some examples:

  • Senior Software Engineer
  • Principal Data Scientist (Quantitative Analysis)
  • Intermediate Java Backend Engineer
  • Staff Site Reliability Engineer
  • Junior DevOps & Cloud Solution Architect

The list can go on endlessly…

Job Title / Discipline [blue]

Because Software Engineering is a huge field of different disciplines, technologies, and paradigms, people tend to split it into disciplines, layers, patterns, etc. Some well-known differentiations are, for example, frontend / backend / systems (site reliability) or design / engineering / architecture. Some also name the disciplines after technologies, e.g. “Java Engineer”. There are some common patterns, but nothing formal.

Specialization [green]

This part, which is normally infix or postfix, describes a specialization or main technology used by that role. Originally, the technology or programming language used was often named here. However, due to technology diffusion (people use many different ted technologies today), the tendency is declining. Even more rarely, a specific field of work is given here as a concretization of the discipline. This occurs mainly in very scientific positions.

Seniority Prefix [red]

This is usually the first word in the job title and expresses “seniority”, sometimes career level [brown]. The prefix can also be omitted, of which some then imply Intermediate / Professional level and few others, like me, do not want to define that.

The following prefixes are frequently used and are sorted in ascending order of seniority / experience:

  • Trainee
  • Junior
  • Intermediate / Professional
  • Senior
  • Principal
  • Staff

Up to and including “senior”, the prefix describes the (desired) experience or depth of the skillset. Some prefixes (e.g. “Principal”, “Staff”, “Head of”, etc.) imply technical or even personal management responsibility. In this respect, I can only recommend employers to include or exclude such requirements very explicitly at the appropriate place. As potential candidates, you should ask, in case of doubt, already in the initial interview whether the position has management responsibility or not. Unfortunately, I have already experienced nasty misunderstandings in this respect myself.

If you’re a “senior” at anything at the tender age of 21, you can either see the irony in that or be motivated by it. The latter probably won’t last long, but many employers still like to use it.

Motivational Factors

Awesome-sounding job titles motivate most of us and that is exactly why so many of them exist. Motivating talent is a very difficult task and has many aspects. Just being able to quickly change the job title on the team page and in the mail footer is one of the easier ones.

Many, especially younger developers, experience a change, for example from “Intermediate” to “Senior” as a great success and advancement on the career ladder. This usually provides a big motivation boost, which is often reflected in the performance.

Many people do not know that a promotion usually also includes new tasks, competencies, and responsibilities as well as a salary increase, or they simply do not demand it. This then remains a mere “job title update” for motivational purposes.

The Dunning-Kruger Effect

Those who take the seniority prefix seriously quickly find themselves in the judging party’s difficult position. Indeed, the difference between how “senior” someone actually is, is almost impossible to formally determine. That is why experience has to be used here, which leads to the Dunning-Kruger effect1.

To be able to evaluate experience or knowledge, one has to have it oneself. In addition, there is the tendency to overestimate oneself, which is inversely proportional to the actual knowledge. Since we humans fundamentally overvalue our own knowledge, the seniority question is more about cognitive bias than an actual assessment of knowledge.

Writing Seniority into Job-Ads

I have made the experience that I find better candidates if I simply advertise a “Software Engineer”, without a super-duper prefix. More often, candidates who overestimate themselves or even just pretend to be qualified, apply for senior positions labeled as such. In addition, many “seniors” have simply seen it all, are no longer willing to learn and tend to not be team players. Last but not least, they often demand wages that are far above their qualifications.

The far more important aspect, however, is that seniority prefixes artificially create exclusivity and potentially excellent talent therefore does not apply because they do not feel “senior” enough for the job.

If you still want to use the seniority prefix in your job ads, I recommend writing multiple different postings for the same position and comparing applicants.


All in all, I can say that as a developer myself, I used to give a lot about a “Senior” title, and I was heavily motivated to reach it in the past. For certain personalities, their own job title can be a motivator and spur them on to peak performance.

However, these days I rarely use these categories, especially not as goals or motivation for developers. I am convinced that these titles often create the wrong incentives and even negatively reinforce one or the other when it comes to team play. Especially in job postings, I have observed that I find more and better-qualified applicants when I deliberately avoid seniority indications and search for humans instead of superheroes.

You May Also Like

How a Strong Type System Saves You Documentation, Tests, and Nerves

How a Strong Type System Saves You Documentation, Tests, and Nerves

I was recently inspired to finally write this post. Especially in weakly- or untyped languages, such as the JavaScript or PHP world, the added value of strict type systems is often not recognized. Instead, many discussions and comments revolve around the need for tests or code comments. Contrary to that, in the functional programming world, we leave such checks to the compiler. In this post I would like to give a short overview and explain how to use a strict type system for everyday checks instead of writing type checks, tests and documentation for it.

How to effectively visualize an Application Landscape in Enterprise Architecture

How to effectively visualize an Application Landscape in Enterprise Architecture

In enterprise & solution architecture, connecting boxes with arrows is an often used and overrated visualization from high-level, thru component architecture, down to data and class diagrams. However, to create a holistic view on systems, component diagrams are not enough! When it comes to analysis or transformation of a high-level application- or service-architecture, I prefer to draw an Application Landscape Diagram, which I would like to show and elaborate on in this post.