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.

Conclusion

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.


  1. Dunning-Kruger Effect on Wikipedia ↩︎

You May Also Like

Blog Relaunch (Yes, again)

Blog Relaunch (Yes, again)

I noticed that I write not as often as I want to, so I procrastinated and first relaunched my blog instead of writing. It has a new design and some new functionality, also the posts have now images. The relaunch was, for me, some kind of personal retrospective, where I read all my old posts and found out that I’m probably a better webmaster than a writer…

Why complexity in software projects is bad (and you should not advertise it)

Why complexity in software projects is bad (and you should not advertise it)

There are (still) many people telling proudly, how complex their product is. There are job ads, explaining that you will “create highly complex software”. These false signals, which I personally saw in many positions and projects, create a potentially huge long-tail problem, not primarily for engineers, but for the product management and engineering team lead. In this blogpost, I want to point out some of those impacts of advertising complexity…