I realized I should have expounded a bit to actually make why this is a red flag a little more apparent.
A 'normal' year of work nets you 2080 hours of work. Thats 52 40 hours weeks.
Mastery of a given topic matter is considered to be around 10,000 hours of work. At that rate, if you have worked a 40 hour job doing something, for 5 years, you should have mastered most of the skills. When I see 'junior' developer, I am used to it being a developer with less than 3 years of experience. I hire people like this, but only for specific needs. My expectations are inline with their experience, and I look at their past work history to get an idea of what level I should expect them to perform at.
Not all people doing technical hiring are that fair minded though. There are many that will see junior, and will move on, because they need someone with more team skills, or skills in architecture, large application development, etc, that they do not expect to see from 'junior' developers.
If someone tells me they have been working on web development related tasks for ten years, but consider themselves junior, then I worry that they have not applied themselves, or stuck to the same job long enough to actually improve their skills, etc. THESE worries...are why I wouldn't hire them. I would have concerns around their ability to grow and learn within my organization, and whether or not the time and money I would pour into their training would pay off in the future with a well skilled and well rounded member on my team, rather than another trip to the well of talent for another junior developer to try to help 'level up' to a different role.
A 'normal' year of work nets you 2080 hours of work. Thats 52 40 hours weeks.
Mastery of a given topic matter is considered to be around 10,000 hours of work. At that rate, if you have worked a 40 hour job doing something, for 5 years, you should have mastered most of the skills. When I see 'junior' developer, I am used to it being a developer with less than 3 years of experience. I hire people like this, but only for specific needs. My expectations are inline with their experience, and I look at their past work history to get an idea of what level I should expect them to perform at.
Not all people doing technical hiring are that fair minded though. There are many that will see junior, and will move on, because they need someone with more team skills, or skills in architecture, large application development, etc, that they do not expect to see from 'junior' developers.
If someone tells me they have been working on web development related tasks for ten years, but consider themselves junior, then I worry that they have not applied themselves, or stuck to the same job long enough to actually improve their skills, etc. THESE worries...are why I wouldn't hire them. I would have concerns around their ability to grow and learn within my organization, and whether or not the time and money I would pour into their training would pay off in the future with a well skilled and well rounded member on my team, rather than another trip to the well of talent for another junior developer to try to help 'level up' to a different role.