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 effect.
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.
Frank Neff
