Everybody is arguing about the semantics of the question, but I think it is fairly obvious what is being asked.
Personally, no I do not believe I have worked with a "first year of experience repeated X times" developer. I have certainly worked with developers whose coding practices I disagreed with. For example, our team once got a coding contribution from another team, and the employee had a more senior job title than mine. It was using all static classes and Hungarian notation. I was completely floored and didn't want it in my code base. Later on I discovered Joel Spolsky's blog and read Making Wrong Code Look Wrong. And then I also started to think about this employee's situation, the team they were in, the kinds of tasks they routinely did, their history. And their strategy made sense in context. And their code was sound, just not organized according to the best practice of the day. Sure, it was going to take some work to adapt to our code base, but my initial assessment of the developer was misguided. And maybe I also felt some competition because their title was above mine. Before I realized all that, I ended up wasting political capital with management attempting unsuccessfully to avoid integrating their code. And that pointless exercise could have been avoided by not presuming myself to be an impartial judge of code quality.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Everybody is arguing about the semantics of the question, but I think it is fairly obvious what is being asked.
Personally, no I do not believe I have worked with a "first year of experience repeated X times" developer. I have certainly worked with developers whose coding practices I disagreed with. For example, our team once got a coding contribution from another team, and the employee had a more senior job title than mine. It was using all static classes and Hungarian notation. I was completely floored and didn't want it in my code base. Later on I discovered Joel Spolsky's blog and read Making Wrong Code Look Wrong. And then I also started to think about this employee's situation, the team they were in, the kinds of tasks they routinely did, their history. And their strategy made sense in context. And their code was sound, just not organized according to the best practice of the day. Sure, it was going to take some work to adapt to our code base, but my initial assessment of the developer was misguided. And maybe I also felt some competition because their title was above mine. Before I realized all that, I ended up wasting political capital with management attempting unsuccessfully to avoid integrating their code. And that pointless exercise could have been avoided by not presuming myself to be an impartial judge of code quality.