It has been ten years since I joined Profinit as a junior Java developer. Because of the work I had done while studying at the Czech Technical University Faculty of Electrical Engineering, I already had four years of work experience under my belt at the time. However, it still seemed somehow logical and right for me to apply as a junior developer. You may say that four years is a long time, but how much do you really move forward when more than half that time is spent working only part-time and de facto you do the same things over and over again? Is it possible, in such a situation, to objectively determine the quality of those four years of experience? From my perspective, it was appropriate to first prove something before wanting anything—at least that’s how I did it. And apparently, it wasn’t a wrong approach at all.
As time went on, I joined the group conducting interviews with prospective Profinit employees. From the very beginning, it was already a mystery to me on what basis the word senior appeared in cover letters and information from recruitment agencies. Just a few years ago, this usually indicated that the person was over 35 and was also associated with more ambitious attitudes regarding personal evaluation. I have to admit that in the vast majority of cases, experience, know-how, and a general overview of the field and its technologies came with correspondingly ambitious requests for compensation.
Over the last two years, however, I feel the situation in IT has changed. Currently, the word “senior” lacks not only experience, know-how and overview of the field but also even age. The only constant actual measurement of so-called seniority (sometimes even “significant seniority”) is the ambitious ideas regarding personal evaluation. Meanwhile, the term senior appears much more often, even though the average age of candidates is falling. Although it may not seem like it from the previous lines, I have no problem with the rules of supply and demand at all. If someone is willing to hire a senior developer who has no idea why recursion should have a terminating condition, so be it. In the words of a classic, “I may not like it, I may disagree with it, but that’s probably the only thing I can do about it”—the current market is easily set up as such.
But what bothers me is the fact that across the entire field of IT there are not many people who really even know what the term senior developer means and what we should expect or want from them. If we knew this, we wouldn’t have to reduce this definition to a salary level, which sometimes creates very bizarre situations. Everybody has to determine the specific prerequisites for a senior developer themselves. However, if I could make a recommendation, it would be to require candidates to meet the following three criteria.
#1: Quality practice and experience
First, it is necessary to focus on practice. However, not only on the length but also the quality of the practice and the experience gained. Quality is best recognized through specific questions about projects, technology and the ability of the candidate to describe the given experience in sufficient detail. More than once, I’ve encountered potential senior developers who have claimed to have used a wide range of technologies for more than five years. Still, they didn’t even know the basic principles, or they have sometimes said that it was part of the project but was handled by another team, so there was no reason for them to take an interest in the issue. Sometimes we don’t have to see the forest for the trees; it is true. But if we consciously ignore it, it’s just wrong.
Being a senior developer is about the quality experience (breadth of knowledge), and we are not in the Matrix yet, so our heads can’t record three years of experience in 30 seconds. It’s an unpopular opinion, but some things take time. It’s the number of projects you’ve completed, the number of bugs you’ve fixed, the number of obstacles you’ve overcome and the number of discussions you’ve had with colleagues on that matter. There are many things you can read about, there are a lot of experiences your colleagues can relay to you, but that isn’t a substitute for really experiencing it yourself.
#2: Versatility, the ability/willingness to solve problems
Only with enough knowledge and experience can you solve a problem—ideally almost any problem. Have you come across a bug, a discrepancy with an assignment, a failed test, a need for a new integration, a bit of programming in another language, or a dysfunctional deployment pipeline? Senior developers have to be able to deal with all of this. That’s precisely why you want a senior developer on the project. Then, logically, you don’t want to deal with discussions about how they primarily know Java and can’t fix that one function in TypeScript because it would be necessary to install Node, etc.
The above is indirectly related to the quality of tools and thus to the general preparedness for situations that may occur. In my opinion, the right senior developers have their own set of tools that they have perfectly mastered and, most importantly, that they have put together in such a way as to help them overcome almost any obstacle. If you are getting into discussions about which tool to connect to a relational database or what to use with SSH, this isn’t good.
#3: Independence, good teamwork
This point is essential. You want to be able to rely on a senior developer. You want to be able to assign a task and be sure that everything will turn out as it should. Whatever it is, the senior developer will manage it. You don’t want to micromanage, but you also don’t want to find out after two days that the assignment that was supposed to be done in half a day isn’t done yet. Furthermore, the right senior developer can help less-experienced team members. Of course, this can only happen in situations where he or she has enough technical knowledge as well as the communication skills that go hand-in-hand with leadership skills (i.e., the ability to direct and oversee one or two less-experienced developers, etc.).
Senior developers are team players. They do not leave as soon as their duties are complete if there is a problem with the project or in the team. They know that they have to help, advise and lead by example. Whenever I’ve had the honour of working with real senior developers on my team, I have been able to rely on them 100%, at least in this respect.
What to say in conclusion? First of all, I’m nearly sure that you will have a different opinion on the criteria I’ve defined. But do you know what? That is perfectly fine. If we can at least agree on the fact that it is necessary to re-evaluate seniority according to what one does know (not according to what one thinks one knows or what one wants), then this text has fulfilled its purpose.
Author: Michal Petřík
Head of Software Development