Software development grades, roles and specialities

Many people today don’t fully understand the concept of seniority and are often completely misaligned when trying to hire or look for someone with specific knowledge or experience.

I want to clarify this and remind you what it’s really about. Let’s start with grades at a very basic level: the concept of grades has nothing to do with knowledge - it’s about experience and time. It implies that a person with a certain amount of working experience is likely to have been exposed to specific situations over a period of time. It does not directly reflect their knowledge itself. Let me explain how.

Grades

Intern

• Person who recently finished university or courses in the field.
• Person who don’t have real work experience in area.

Junior

• Person who has little working experiences in area
• Under 3 years of experiences can be considered as Junior experiences.

Middle

• Person who has average (this is why its called middle) amount of time spent on working in area.
• above +3 years and usually under 5 years of experience

Senior

• Person who has significant amount of experience in the area
• Usually +10 years considered as Senior

See the interesting gap here ? How do you call 5+ but less than a 10 years of experiences ? Exaclty this is why market using middle+ for person are not considered as senior, but overgrow middle bracket.

Roles

The next category is Role. Role is always have to be applied in a group, it cannot exists by it self, another words person cannot be lets say Team lead of something, it doesn’t make sense. Understand role as a rank in hierarchy which connects Grade and Speciality (read below).

Engineer

Technically capable to write code.

Team lead

Lead of those who are Engineers. Usually have enough carisma and experiences to lead the group of people to a certain direction. Worst of them referring themselves as “team lead”. Best of them calmly ruling the group of people. Team lead cannot be hired, it can only be grown from the person that exists in a group for certain period of time. So when you see job description saying “Python Team Lead” skip it, its waste of time.

Manager

Person who leads others.

Staff / Principal

Person who are so to speak lead of multiple groups of other people, read it is teams. Usually very mature, and tech-savvy.

C-Level

C‑Level refers to the top executive positions in an organisation, typically carrying the “Chief” title, such as CEO (Chief Executive Officer), CTO (Chief Technology Officer), or CFO (Chief Financial Officer). These individuals are responsible for defining the company’s vision, strategy, and high‑level decisions. The best C‑Level executives balance business priorities with technical and organisational realities, making informed decisions that drive sustainable growth. The worst operate detached from the company’s actual challenges, relying on buzzwords, trends, or micromanagement rather than genuine leadership.

Stakeholder

A stakeholder is any individual or group with an interest in the outcome of a project or product. This can include customers, end users, investors, executives, project sponsors, or team members whose work is directly affected. The best stakeholders provide clear input, understand project constraints, and collaborate constructively with the team. The worst demand results without context, change requirements frequently, or impose unrealistic expectations without considering the impact on delivery.

Speciality

Speciality is very vague topic, I’ll give an examples of few ones to understand basic structure in there. Understand that each speciality has tree like structure and can be expanded to multiple levels. (Software Developer -> Embedded -> C++, Software Developer -> Web -> PHP, and so on). I’ll only describe top level speciality hierarchy related to web-development here.

Software Engineer

Common umbrella speciality for everybody who is creating software.

Full-stack Developer

A full-stack developer is capable of handling the entire development process independently. In the mid-to-late 2000s, the concepts of “backend” and “frontend” development emerged due to the growing complexity of web technologies. Developers began specializing in specific areas — some focusing solely on frontend and others on backend. While I personally don’t favour this division, it occurred naturally as client-server applications started interacting over APIs, and managers began distributing tasks across teams. Over time, this specialization became increasingly normalized.

Frontend Developer

A frontend developer is responsible for building the parts of an application that users directly interact with. They work with technologies like HTML, CSS, and JavaScript (often with frameworks such as React, Vue, or Angular) to create responsive, accessible, and visually appealing interfaces. Their role combines technical implementation with an understanding of user experience principles. Best of them understood UX patterns and reading guidlines, worst of them just have no experience with UX and just do what being said.

Backend Developer

A backend developer is responsible for building the server-side logic that powers an application, handling data processing, business rules, and integration with databases or external services. They work with languages such as Java, C#, Python, Ruby, PHP, or Go, often within frameworks like Spring, Django, or Rails, and design APIs for frontend interaction. The best backend developers understand system design, scalability, and maintainability, while the worst simply produce code that “works” without considering performance, security, or long-term support.

QA Engineer

A Quality Assurance (QA) Engineer is responsible for testing software and ensuring its quality. While the term “quality assurance” sounds lofty, in most web development contexts, it largely comes down to structured testing. Testing can be performed manually or with specialized tools — some of which may be created by the QA engineers themselves. Traditionally, QA engineers possessed programming knowledge, but as the role became more popular, it increasingly shifted toward manual “clickthrough” testing scenarios, often with less emphasis on technical expertise.

Manual QA Tester

Person who only capable to perform manual testing. Usually have basic QA knowledge about use-cases and scenarios and following guides of submitting reports.

UI/UX Designer

A UI/UX designer is responsible for creating the visual and interactive design of software products. They must understand popular operating systems, their design principles, and guidelines to produce proper, user-friendly interfaces. Many designers today use tools like Figma to create and refine interfaces. However, a significant portion of them focus solely on visual (UI) design and have little to no experience working with the official guidelines or UI kits provided by leading operating systems.

DevOps Engineer

A Development Operations (DevOps) engineer bridges the gap between software development and operations, ensuring that software runs reliably in production environments. In the past, these responsibilities were handled by developers themselves, but with the increasing complexity of cloud platforms, DevOps emerged as a separate discipline and a set of best practices. Initially, in the early 2000s, system administrators were responsible for much of this work. In more recent years, however, many have adopted the “DevOps” title without necessarily possessing a deep understanding of what DevOps truly entails.

Project Manager

A project manager is responsible for overseeing project implementation, ensuring adherence to delivery schedules, and managing the development process. The best project managers have a background in software development and were developers in the past; some may even continue coding independently for fun or personal projects. Typically, a project manager reports to C-level executives and stakeholders. The worst project managers, on the other hand, contribute little beyond scheduling calls and attempting to make the team communicate with each other.

Product Manager

A product manager is responsible for overseeing the implementation of the product itself — its features, usefulness to customers, and overall market fit and strategy. The most proficient product managers excel at this role and often have a background in software development. In contrast, many modern newcomers have little understanding of their responsibilities, often finding themselves caught up in endless calls with developers and designers, attempting to enforce poorly formed opinions about how things should be done.

How to use it ?

Organisations tend to hire based on their immediate needs, but many HR managers and so‑called “sourcers/recruiters” often do not fully understand the concept of grading. From a business perspective, the goal is usually to hire as cost‑effectively as possible to meet those needs, with HR negotiating salaries towards the lower end. At the same time, management and C‑level executives aim to hire the best fit for the role, while employees seek to secure the highest salary their experience can justify.

Each role may have different specialities, but not every grade is applicable to every role. Some roles only become viable at a certain level of experience. Certain roles cannot simply be hired externally - they need to be developed internally within the team. A team lead is a good example of this.

Below are the tables with rational tendencies and social mechanics based on grade.

Role vs Grade

Certain roles cannot be filled at specific grades.

• You cannot hire a junior manager - this role does not exist at that level.
• You cannot simply hire a team lead; this role implies leadership within an existing team and typically needs to be developed internally.

Speciality vs Grade

• For certain specialties, you cannot hire at specific grades.
• Avoid hiring for specialties that inherently require a high impact on the product, processes, and overall work at a low grade.

Grade to report to vs Grade you’re hiring

• You cannot hire for certain grades if there is no higher‑grade professional for them to report to.
• If you don’t have at least a mid‑level developer, hiring an intern or junior makes little sense, as it will be a waste of resources.

As you can see, there is no mention of specific skills, actual knowledge, or expertise needed for your project. This is because grades, roles, and specialties have no direct correlation with the specific technologies you are targeting. Instead, they imply the probability that experience with certain technologies will be present within those grades.

It’s important to understand that experience with a technology varies greatly by grade. For example, a junior developer who “knows Docker” may only have followed tutorials or used it in a limited, pre‑defined context. A senior developer who “knows Docker” however, likely has experience designing containerisation strategies, handling complex production deployments, troubleshooting nuanced issues, and integrating it into broader CI/CD pipelines. The same technology can mean completely different depths of experience depending on the grade.

This is why the primary goal of an interview is not just to verify whether a candidate has used a technology, but to understand how they have used it, in what contexts, and with what level of ownership and responsibility. The grade gives you a baseline expectation of exposure, but interviews help uncover the real depth and relevance of that experience.

Furthermore, the level of required experience is always relative to the project itself. You don’t need to hire a senior‑level data scientist to sort through a few thousand records in CSV reports - that’s overkill for the task. Conversely, if you are building a complex machine learning pipeline or architecting large‑scale data processing systems, hiring someone with only junior‑level exposure would be insufficient.

This is why hiring should always start with a clear understanding of the project’s actual needs, rather than defaulting to a grade or a trendy job title. Matching the right level of experience to the problem at hand ensures both efficiency and cost-effectiveness.

Oftentimes, hiring managers ask candidates about technologies or skills that are not even used in the actual project, demanding expertise in areas that are irrelevant. This is an obsolete and counterproductive practice - it wastes both the candidate’s and the company’s time and resources.

My recommendation is to define clear goals for what you want to achieve by hiring a certain expertise. During this process, you may even discover that you don’t need that specific expertise at all - or that a different role or grade would serve the project better.