Junior, Middle, Senior, Lead - what's the difference?
Hello everybody! My name is Alexander Demura, and I have been working in IT since 2004. Currently I manage DataArt’s development center in Odessa (I myself am from St. Petersburg, but that is another story). My main duties include hiring and developing our specialists, so discussing the "seniority" of the staff and the qualities necessary for a particular role is relevant and habitual for me. I'll allow myself a traditional disclaimer - this article sets forth my personal views (fortunately, it’s allowed in DataArt, so no one has to adhere to one specific thinking). The text I wrote does not pretend to be the ultimate truth and is unlikely to be a revelation for people who are already versed in the matter. But it will be useful to those who are just starting out in IT or do not really understand how and where to develop further, feel undervalued, or just want to expand their horizons.
Initially, DataArt did not have a formal gradation in terms of qualification. After all, we hire the whole person for a team, with all their pros and cons, and not just buy the required function from the labor market. If you think about it, "junior", "middle", and "senior" are just labels. But such labels have to be used to simplify the picture of the world and increase the effectiveness of communication - they are familiar to both clients and colleagues.
This allows you to discuss a set of expectations for a particular role. But people rarely fit perfectly into a convenient framework, and the performance of each specialist in the project depends on a variety of parameters. Therefore, it is almost impossible to come up with an objective abstract metric of quality in a vacuum.
For example, a person can perform brilliantly in one project and suddenly flunk it in the next. What to expect from them in the third project? Some specialists can brilliantly answer the most complex technical question, but then generate unsupported code. Or the contrary – a specialist can have a hard time solving junior issues while having a dozen successfully completed projects in their resume. To delve into such nuances, help people use their strengths, and compensate for weaknesses is one of the tasks of management. The task does not seem to have a one common solution, which makes the work of the manager interesting, although sometimes difficult.
DataArt has an internship program where we take people even without work experience. They have three months to achieve the junior level under the guidance of an experienced mentor. There are two basic requirements for an intern position:
- Good English.
- Understanding of their chosen tools and the ability to use them.
The English knowledge requirement is actually common for all. DataArt is an international organization, most of our clients are located in the US and Western Europe, and even internal communications are conducted in English more and more often. If a person is a competent technical specialist, we will help them with their language. For this, there are corporate courses and a lot of additional initiatives. But if a person doesn’t have the technical experience (i.e. an intern) and also knows little English, they need to have unique qualities that will overweight both of these shortcomings.
I think the point about the tools is self-evident. If you want to take the role of a programmer, the tool for you is a programming language with the development tools that you need. If a potential intern wants to develop using .NET, but cannot explain what the CLR does, how "Equals" differs from "==", or implement the simplest algorithm, then they don’t have a chance. Coming with zero knowledge and hoping that everything will be taught on the spot while earning the salary won’t work, there’s just too much competition. Many candidates have completed several professional courses, can easily answer all theoretical questions, and even have some personal programming experience. Of course, such people are hired first.
After passing an internship, the person becomes a junior. The main requirement for this is the ability to perform technical tasks independently. If there is architecture built in the project, the junior should be able to implement the next piece of the application’s sample logic without hesitation. However, a junior may from time to time make mistakes, not understand the nuances, and discuss implementation plans or check the finished code with the team lead.
For a junior, the following qualities are important:
- The desire to develop and learn (especially on their mistakes).
- Energy and commitment.
- The ability to calmly take criticism.
It should be understood that the tasks that a senior can solve in ten minutes, a junior may require an hour each, and in the process the code will have to be rewritten completely, which means spending a lot of extra energy. It's important not to be afraid of it and to seek balance. You need to know when to try and solve a task yourself, and when to stop hanging your head against the wall (while spending the project’s time on it) and ask for help. Justifying your unsatisfactory performance with “I'm still a junior" is a bad idea.
The main requirement for the middle developer is the ability to perform the tasks assigned to them independently. Very similar to what was written in the previous paragraph, right? However, there is an important nuance - here there is no word "technical". That is, at a new level, one must understand the business requirements and be able to translate them into technical solutions.
- A middle understands what the application does exactly. This allows for a deeper understanding of the task, therefore, more accurately evaluate it and implement it more effectively. If the requirements do not completely cover a certain scenario, a good developer will pay attention to this during the planning stage. And not when the application starts to crash after any non-standard user action.
- A middle is familiar with standard templates and solutions when building an application in their field, understands why they are needed, and knows how to apply them. Standardization of solutions is of great importance in the collective development of code, because it allows the new person to quickly understand what is what, and minimizes the number of errors. Understanding the structure of a typical application makes the task of building it from scratch rather trivial and allows for discussing the principles of correct implementation and distinguishing good code from bad.
- A middle understands that one soldier does not make a battle. They know how to interact with the team members, e.g. discuss a difficult moment with a designer, clarify the incomplete requirements with the business analyst, agree upon some important technical solution with the project’s architect (if there is one), and, of course, own the appropriate tools for collective development.
A senior is an experienced developer who has seen a lot of code, made a number of faults and errors, and managed to draw the right conclusions from them. The main task of a senior is to make the right technological decisions in the project. "Right decisions" are those that bring maximum benefit to the business and minimize costs. A good senior not only understands what the team is developing, but thinks about what tasks the finished application should solve. While developing a site for an auction, a senior always asks themselves about the peak load and tries to foresee the attempts of competitive entry in the database tables. They think in advance about the bottlenecks of the system and the possibility of scaling it, remembers vulnerabilities and problems caused by the improper use of tools.
Such an expert does an amazing thing - they solve problems even before they get the chance appear. From the outside it resembles the gift of foresight. But if your project lives from problem to problem, and you constantly have to throw out and rewrite pieces of code, then these are the symptoms that the project receives not enough attention from a senior.
After a little thinking, we can formulate a number of features of a senior developer:
- The ability to solve several more complex tasks and complete them faster or better than an average developer has nothing to do with seniority. In our classification, the person who does this is called "Strong Middle".
- The senior rank cannot be obtained quickly. It is necessary to gain extensive experience and understand what distinguishes a well-made product from a crudely made one, how technical debt manifests itself, how much refactoring costs, what patterns are really needed, and whether infinite levels of abstraction are needed. It is necessary to make important decisions on your own and give them time to pass the test, otherwise they will not be evaluated.
- A senior requires good communication skills, because they must not only offer the right decision, but also convince their client and the team to agree with them. If you could not defend a good decision and instead of it a bad one was accepted, you will have to blame yourself for it. The option "I told you so" does not work anymore at the senior level. Same thing with the team: it’s not enough just to know how things should be done, you also need to be able to explain it intelligibly. Then the team grows rapidly and accumulates experience while avoiding painful mistakes. The authoritarian approach ("do as I say") often leads to internal conflicts, and the situation on the project does not improve at all, so you need to try and avoid it.
- A senior cannot do without understanding the design of libraries and frameworks. If the development tool for you is a black box, and you compose an application from the finished parts without knowing what each of them does, the product will always be unstable and unpredictable.
A manager who adds a senior to the project hopes to reduce technical risks or at least begin to understand them. Rarely there are systems without a single problem - technological perfectionism often is simply unprofitable for business. But a senior is required to catch the moments when several innocuous errors turn a system into a Frankenstein and stop this process before it’s too late.
I will begin with the destruction of a popular myth; that seniors grow into project managers. The transition to a manager is a step not up the ladder, but to the side. All the experience gained over many years of working as a programmer does not really help in a new role because you have to work not with code, but with people and plans.
The very idea that the PM always stands above developers, that they are more important and receive more money is mistaken. For example, if you have to make a high loaded application in the cloud, and there are no corresponding experts, then even the best manager is doomed to fail. In addition, modern flexible methodologies often do not offer a separate the position of a project manager, therefore it is better to consider management as one of the roles in the team.
How should seniors develop? Many programmers like to talk about the "ceiling", i.e. when the internal rate (that is, the money that you get for work) is approaching the external (the bill given to the client for your services) with minimal margin. They believe that in this case the further growth of a specialist becomes inexpedient for the employer. However, this is not the case. There are many ways to further increase your value (at least in DataArt). Therefore, the position of a senior developer should be considered not as a career plateau, but as a springboard for further development. For example, in one of the following areas:
The status of a technical expert implies a deep knowledge of a specific area. For example, you can be an expert in Azure/AWS and know various services that these platforms provide. You have to be able to do Machine Learning or Computer Vision, know everything about the web vulnerabilities, understand how cryptocurrencies work, or prepare Sharepoint correctly. Such tasks do not occur every day, but when they appear, then it’s time to unleash the expert. Without them, such projects would be simply impossible, and the company is often willing to pay extra for unique knowledge.
One of DataArt’s goals is developing in certain domain areas (travel, finance, health, etc.). In each project, programmers not only acquire technical knowledge, but also get an opportunity to look into the client’s business, understand how the industry works, and learn about problems and solutions common to the field. What does it take to develop a PayPal-like payment system? Why is the Saber system needed? What is HIPAA, and what restrictions does it place on developing health solutions in the US? People who possess this type of knowledge often form the backbone of the project and bring huge additional benefits to the company and the client. Therefore, their compensation may exceed the external rate, since the companies themselves are willing to pay extra for such specialists.
The distinctive qualities of a frontman are the ability to present themselves and their company properly, talk about complex technical things in simple words, quickly build a prototype and show the first results, and speak the same language as the client’s top managers and programmers alike. Such people are often called in for initial meeting calls and sent first for a business trip to the client. Their task is to quickly understand the problem, explain exactly how we can help, and establish cooperation with the offshore team. The combination of technical knowledge and presentation skills allows the company to receive new projects. Obviously, the specialists who possess such qualities are highly appreciated.
The role of a team lead is quite understandable and traditional, so no need for me to dwell on it in detail. This is, in fact, a combination of technically literate solutions with quality development processes. Their correct combination means more benefit to the client for the same money, less chance for an inexperienced junior to spoil something, plus additional bonuses for the company, such as standardizing approaches to development, reducing the threshold of entry into the project, and stimulating the growth of specialists in the required direction.
Some projects cannot be started on the fly since they can be too large or complex. But in general, a project may require an architect for a thousand different reasons. The architect requires all the same understanding of the client's business, the ability to analyze complex technical systems, and then communicate this understanding to the client and developers. In addition, an architect must have a broad outlook in terms of platforms and components available on the market from which the solution can be synthesized. For an architect, "microservices", "cloud", etc. are not fashionable trends, but clearly verified technological solutions that give strictly defined advantages and impose appropriate limitations.
I have listed five possible roles from technical development only, leaving out testers, analysts, managers, designers, marketers, and vendors.
Additional: working without intermediaries
I want to write separately about working without intermediaries, which some perceive as the Holy Grail of programmers. It would seem that everything is logical: we find a client, we offer them our services directly, and take the entire rate. Profit! However, you need to understand that, in addition to profits, the programmer will have to bear all associated risks as well in this case. It is necessary to read the clause of the contract on the responsibility of the parties carefully, know the legislative and tax systems, come up with a mechanism for obtaining money, and know how to act if the client did not pay or unexpectedly curtailed the work. In DataArt, these issues are solved by specially trained people (salesmen, lawyers, accountants), and even if the client went bankrupt and left the business with crazy debts, the developers will still get their money on time and calmly move on to the next project. When working directly, everyone is for themselves. In addition, most companies spend very tangible budgets to attract new clients, so direct relationships with clients, which the company found, are prohibited on either side by the contract.