Every developer is a bozo for their first few months in a new job, simply because it takes time to absorb all of the information needed to understand how the existing systems work.
In my experience the bozos were absolutely not the newbies. Maybe you work in a job that is dedicated to engineering only, but what happens is that often in a company of non-engineers, some kinda reorg happens where a person ends up on your team who never studied programming in their life, with the assumption that the person is a go-getter who will be able to pick all this stuff up. The experiment is never called a failure when they consistently fail to learn. 2 years later the same underwhelming "engineer" will still be there getting other people to do their work while desperately trying to introduce bugs into production.
Acculturating new developers is one of the main tasks of an organization. I don't think it's very difficult to communicate that some company uses language[s] X[, Y and Z] only.
That depends on the culture of each specific organization. Are there top-down engineering decisions? Is there a push for more team autonomy?
My experience is that many organizations have something of a pendulum swinging between those two positions, so the current state of that balance may change over time.
Also: many new developers, when they hear "microservices", will jump straight to "that means I can use any language I want, right?"
