I worked at Google for a year, so I'll answer from their perspective. Compared to other large organizations that I have heard about, they are very unusual. But in an obviously effective way, so don't dismiss it even though it may run counter to what you expect.
Imagine you're on a big (possibly global) team...
That seems like major mistake. Large unified teams have inherent productivity problems. With a highly dynamic language like JavaScript, those productivity problems become much more problematic. Therefore it is better to have many small teams, each working on their own problems, but with a shared code base. How small? Well a commonly stated rule is the pizza rule: If a team is building something new, then the team should be small enough that one large pizza can feed them.
Next you need basic good practices. See How do big companies of software developers check for bugs in thier programs? for some of the important ones. Those are good no matter what the language is.
Moving on, JavaScript in particular, being a dynamic language, has many possible pitfalls to avoid. You can get rid of a lot of them by combining a good coding standard, automatic linting to catch whole classes of bugs, and then a good minifier that can take your clean, well-organized code and produce something that will execute efficiently on the browser. Here is Google's style guide, a lint tool to verify that you are following it (this will automatically catch common sources of bugs like assigning to undeclared variables), and the compiler that Google uses.
As with all languages, development always proceeds in two directions. Working bottom up you create the libraries that you need to make development of your application easy. And working top down you build your application on top of that library. Google has open sourced most of the library that they develop. It takes a while to learn your way around closure, but it is heavily used inside of Google. If you're going to work on the front end at Google, you need to learn it.
Note that with consistent style, rigorous code review, and an effective approval process, people both can and do work on any part of the code that they need to. If core libraries don't do what you need, you should fix that. It's a little surprising to watch it in operation, but it really does work.
While I was at Google I was not doing web development. However the parts of the company that I saw didn't talk much about UML, cyclomatic complexity, design patterns, etc. Sure, people knew abut that stuff and would be happy to use it where appropriate. But "where appropriate" is a critical qualifier. Design documents were mostly written in plain English, and were intended to be as clear as possible.
The corporate philosophy there is very much code talks, bullshit walks. Google famously doesn't have much use for architects who aren't coding. But they are very, very good at recognizing good designs and code. If you're coming up with good designs and code, people don't care too much about the process that you use to get there.
I'm quite sure that other corporations have very different cultures.
