More than the language, it's the culture of the organization that matters. You could be working for a company that uses a 'modern' language like Typescript, but

More than the language, it's the culture of the organization that matters. You could be working for a company that uses a 'modern' language like Typescript, but then restricts you to using UI components built by a central team who can't possibly have an insight into every use case that downstream teams deal with. So you're stuck working around the limitations of those components. Or you work for <insert famous tech company> who can't use a particular library which makes your life a lot easier because a competitor had developed it. Either you find time to reinvent the wheel, or you just put together something that works for now, but will be a pain later to modify or extend. In cases like that, you can end up with code even uglier than N-Tier (where N > 4) Enterprise Java projects from the 2000s. So if you see a company with bloated culture, which incidentally uses Java, then you will find over engineered Java code. But if it's a company that cares more about solving problems than having a lot of meetings on what standards to follow, their Java code will be unlike anything from the 2000s.