Measuring Developer Skill Levels in the Age of AI Chatbots

Measuring Developer Skill Levels in the Age of AI Chatbots

As someone who has been a part of the tech industry for some time, I have seen various companies struggling to measure the practical skill level of developers accurately. In this blog post, I will share my insights on the different categories of developers and the current ways in which skill levels are measured.

In addition, I will offer suggestions for more effective methods of evaluating developers' skill levels, provide guidance to developers on accurately assessing their own skill levels, and explore the potential impact of AI chatbots on the measurement of skill levels.

Main Skill Level Categories

Currently, in the tech industry, developers' skill levels are often categorized based on years of experience, such as:

Junior Developer

  • typically has 1 - 2 years of experience

After gaining some experience, entry-level developers typically move up to become junior developers. Junior developers have one or a couple of years of experience and are capable of working on moderately complex projects under supervision. They have a good understanding of programming concepts and may be familiar with more than one programming language.

Mid-level developer

  • typically has 2 - 5 years of experience

Mid-level developers typically have a few years of experience and possess a strong grasp of programming concepts. They are capable of working independently on moderately complex projects and require minimal supervision. While proficiency in multiple programming languages is not a requirement, mid-level developers should be proficient in at least one language. Additionally, they may have the ability to mentor junior developers, although this is not a prerequisite for their role.

Unfortunately, some companies do not recognize the mid-level category, and they often label their mid-level developers as juniors, depriving them of the recognition they deserve. Such companies may exploit the developers by paying them less than what they should receive.

Senior Developer

  • typically has 5 - 8 years of experience

After several years of experience, a developer can become a senior developer. They can handle complex projects with minimal supervision and have a deep understanding of multiple technologies. They may also have a leadership role within their team and be responsible for mentoring and managing junior developers.

You may be a senior developer but good luck in proving that. Despite your extensive experience and seniority in the field of development, it can be a challenging task to convince companies and colleagues of your true level of expertise. Unfortunately, both employers and coworkers may attempt to keep you at a lower level to pay you less or to feel superior to you.

Staff Developer

  • typically over 8 years of experience

Staff developers are senior developers who have additional responsibilities such as managing a team or leading projects. They have a high level of expertise in multiple programming languages and are capable of providing guidance and mentoring to other developers.

Principal Developer

  • typically over 15 years of experience

Principal developers are the most experienced and knowledgeable developers in a company. They have a deep understanding of multiple technologies and are responsible for designing and overseeing the development of large-scale software systems. They also serve as technical leaders and mentors to other developers.

Architect/Lead Developer

  • typically over 15 years of experience

Architect/Lead developers are responsible for the overall technical design and direction of a software project. They have a deep understanding of multiple technologies and programming languages and have extensive experience in software development. They often lead teams of developers and work closely with stakeholders to ensure the project meets business objectives.

Categories that Should not Exist

Entry-level Developer

  • typically has less than 1 year of experience

Associate Developer

  • typically has less than 1 year of experience

While some may argue that the label "Junior" is intended to provide developers with guidance and support in the workplace, the truth is that categories such as Entry-level, Associate, and Junior are not truly beneficial to developers.

In fact, companies often use these labels as a means of underpaying their employees. Moreover, the industry's tendency to create increasingly disparaging labels beyond "Junior" only serves to further undermine the contributions and value of developers. Ultimately, these labels only perpetuate a culture of undervaluing and exploiting skilled professionals.

Current Ways of Measuring Skill Levels

Years of Experience

While years of experience can certainly be an important factor in assessing a developer's skills, it is not a foolproof method. It's crucial to recognize that everyone learns and advances at their own pace. Therefore, relying solely on the number of years someone has been working in the field can be misleading. Instead, it's important to consider a developer's actual abilities and accomplishments as a more reliable measure of their skill level. Ultimately, years of experience can provide helpful guidance, but it should not be the only factor considered when evaluating a developer's proficiency.


When evaluating a developer's credentials, it's important to keep in mind that degrees, bootcamps, and certificates are just one piece of the puzzle. While these educational achievements can certainly be valuable and demonstrate a certain level of knowledge, they do not necessarily guarantee real-life experience or practical skills. It's entirely possible that a developer who has completed a degree program may not be able to perform as well as a junior developer who has gained hands-on experience through internships or other practical training. Therefore, while credentials can be a useful starting point in assessing a developer's qualifications, it's important to consider a wide range of factors when evaluating their actual abilities and potential for success.

During Interview

The most common ways of measuring developers' skill levels during an interview are:

Theory Conversations

Theoretical conversations can be highly misleading, particularly when the interviewer is not familiar with the work of the developer. Without context or practical application, the ability to memorize and theorize about concepts becomes the focus of the conversation, rather than actual skills and experience.

Furthermore, this approach can be easy to set up, and can potentially embarrass the developer if they are unable to perform as well as expected in a theoretical conversation. It's important to keep in mind that being able to code or program something doesn't necessarily mean that a developer can verbalize and explain it to others.

Coding Challenges

Coding challenges can be problematic as well, especially when there is a time limit. Developers may feel pressurized to perform, and the platform they use may not support all the features needed to implement best practices, limiting their ability to showcase their full potential.

This is particularly true if the platform is outdated or not commonly used in the industry. In such cases, developers may have hands-on experience with more advanced tools and technologies than what the platform allows them to demonstrate, which can be frustrating. (True story)

Moreover, coding challenges are often irrelevant to the actual work that the developer would be doing if hired, leading to a mismatch between the candidate's demonstrated abilities and the actual requirements of the job.

Pair Programming

Pair programming is another approach that some companies use to evaluate developer skills. This involves pairing a candidate with an experienced developer to work on a coding problem together. While peer programming can be semi-effective, as it provides a glimpse into the candidate's problem-solving abilities and collaborative skills, it is still an interview setting that can be stressful for the candidate.

Additionally, the candidate may not be used to the tools or technologies used by the company, which can impact their performance. Moreover, the pair programming approach may not reflect the actual work that the candidate would be doing if hired, and it may not be feasible to use for all candidates due to time and resource constraints. While peer programming is a step in the right direction toward more comprehensive evaluation methods, it should not be relied upon as the sole evaluation method.

A Better Approach

Traditional methods of evaluating developer skill level, such as theoretical conversations or coding challenges, are not always effective. A more comprehensive approach, like letting developers complete actual work-related tasks and evaluating their performance, can provide a more accurate and fair evaluation of a candidate's skills and abilities.

The Hands-On Approach

This approach has several benefits. First, it allows companies to evaluate developers based on their actual performance and abilities, giving them a better understanding of their skill level. Second, it allows developers to demonstrate their skills and abilities without the pressure of theoretical conversations or the risk of being misjudged based on credentials or experience alone. Third, it lets the developer, the company, and the co-workers evaluate if the candidate is a good cultural fit for the team. Fourth, it empowers the developer to determine if the company's work style and values align with their own, and if the team dynamics are conducive to their working style. Fifth, it offers transparency, which can help mitigate the risk of the company misrepresenting the job requirements, work culture, or team dynamics during the interview process.

To implement this approach, companies should give developers a couple of weeks to a month to complete actual work-related tasks. The developer should be paid during this period, and the actual long-term contract can be signed after the evaluation is complete.

This approach is not only beneficial to the company, but it is also fair for the developer. During the evaluation period, the developer can see firsthand the real work and technologies used, which can help them make an informed decision about whether they would like to continue working with the company.

In addition to the benefits outlined above, it's worth considering the time and effort that can be saved by using a hands-on approach to hiring developers. Traditional approaches often involve multiple rounds of interviews, with a great deal of pressure to prove oneself. This can be a time-consuming process, taking several months in some cases. On the other hand, implementing a hands-on approach can be completed in as little as one month. By streamlining the hiring process and focusing on practical skills, companies can save valuable time and resources while identifying top talent more efficiently.

While traditional interview methods such as theoretical conversations or coding challenges can be useful to some extent, they are not always the most effective way to evaluate a developer's abilities, skills, and cultural fit. A more comprehensive approach, like letting developers complete actual work-related tasks and evaluating their performance, can provide a more accurate and fair evaluation of a candidate's skills and abilities. This approach benefits both the company and the developer by ensuring a good cultural fit and a successful long-term hire, and by providing transparency and empowering the developer to make an informed decision about their future with the company.

How Can Developers Accurately Measure Their Own Skill Level

This guide is meant to help developers have a better and more realistic understanding of their own skills.

It's important to note that developers may encounter individuals who try to undermine their skills and value, whether it's colleagues, managers, or potential employers. In these situations, developers need to stand their ground and fight for their rights. Some signs that someone may be undervaluing your skills include:

  • constant criticism

  • a lack of recognition or opportunities for growth

  • being offered lower pay or job titles than what you deserve.

If you suspect that someone is undervaluing your skills, there are a few steps you can take to prove it:

  1. Conduct a self-assessment: Conduct a self-assessment of your skills. Be honest with yourself about your strengths and weaknesses and consider seeking feedback from peers or mentors. This can help you identify areas where you need to improve and give you a better understanding of your own skill level.

  2. Research industry standards: Research industry standards for different skill levels and job titles. This can give you a better understanding of the skills and experience that are typically expected for different roles. You can use this information to benchmark your own skills and ensure that you're being valued appropriately by potential employers.

  3. Ask for specific feedback: When receiving feedback from employers or colleagues, ask for specific examples and details about where you need to improve. This can help you determine whether the feedback is legitimate or whether it's an attempt to undermine your confidence or value.

  4. Seek out third-party assessments: Consider seeking out third-party assessments of your skills, such as certifications or independent evaluations. These can provide objective measures of your skills and give you a better understanding of where you stand regarding industry standards.

  5. Network and stay informed: Network with other developers and stay informed about industry trends and best practices. This can help you stay up-to-date on the skills and experience that are in demand and give you a better understanding of how your skills compare to others in the industry.

Ultimately, developers need to have a realistic understanding of their own skills and value and to be willing to advocate for themselves when necessary. By taking proactive steps to assess their skills, research industry standards, and seek out opportunities for growth and improvement, developers can position themselves for success in the industry and avoid being undervalued or misled.

Potential Impact of AI Chatbots on Skill Levels

I like to think that there is a possibility that the categories of skill levels for software developers may slowly become less distinct and merge into one category of "skilled developer." It is already difficult to accurately measure skill level, and with more developers using AI chatbots as part of their workflow, this could become even more challenging.

As AI chatbot technology advances, it presents an opportunity for junior developers to accelerate their learning process and receive guidance from an AI chatbot. This could reduce the burden on mid-level developers who previously had to mentor them and enable juniors to advance quickly into mid-level developers.

In turn, mid-level developers may also benefit from chatbots as they can leverage the AI chatbot's support to advance more efficiently toward seniority. With AI chatbots in place, senior developers may not need to closely supervise and guide junior and mid-level developers as they have in the past. This could free up senior developers' time to focus on higher-level tasks, such as strategizing and innovating.

Overall, the use of AI chatbots could blur the lines between different developer roles and enable a more flexible and efficient workflow within development teams.

We should be aware that some companies may take advantage of this blurred line by assigning mid-level developers to junior roles or demoting senior developers to mid-level roles, to save costs on hiring more senior developers.

Some companies may make the false claim that AI chatbots can handle most of the workload, with developers simply supervising them.

I believe that this is a severely misguided assumption that fails to recognize the indispensable role that skilled developers play in designing, developing, and maintaining complex software systems. Such an attitude is not only erroneous but also dangerous because it overlooks the critical human skills and expertise that developers bring to the table.

As AI chatbots continue to evolve, they have the potential to impact how we measure the skill levels of developers and the tasks they are responsible for. With chatbots able to assist and guide developers at different levels, I hope that the distinctions between junior, mid-level, and senior roles become less rigid.

This could lead to a shift towards a more flexible and dynamic model of development, where developers are valued for their overall skill set and ability to adapt and learn new technologies quickly. In such a scenario, the traditional categories of skill levels may gradually merge into one larger category of a "skilled developer."

However, it is important to note that skilled developers are still going to be in demand and having a broad range of skills and knowledge will continue to be essential for success in the industry. While AI chatbots may change the way we think about developer roles and skill levels, they are unlikely to replace the need for skilled developers altogether.

My Conclusion

I think that all of these categories and divisions are a bunch of unnecessary BS.

I divide developers into two simple categories:

  • those who enjoy programming and are loyal and devoted hard workers.

  • and those who are in it for bragging rights and spend more time gossiping and procrastinating than coding.

I believe that AI chatbots could slowly wean out the latter group and leave behind the truly dedicated and skilled developers who will excel and progress faster.

However, the pseudo-developers will surely put up a good fight and make it harder for the devoted ones, as they have been doing in the past.

Nevertheless, I encourage devoted developers to stay focused, keep up their hard work, and not be discouraged by the challenges that lie ahead. With their commitment and passion for programming, they will undoubtedly stand out and thrive in the industry, while the others will eventually fall behind.