Joel Spolsky writes an excellent article about the importance of experience when programming.
Joel, a one time Microsoft employee, doesn't give examples from the largest software company in the world. This is surprising, because traditionally Microsoft had a very strict recruiting policy: get the best people, regardless of whether they know something about the problem or not. The underlying assumption is that knowledge can be taught, but talent cannot.
The consequences of this policy are evident in many Microsoft products. When a new product which is unrelated to previous Microsoft products is being designed, the people who work on the project are brilliant, but inexperienced in the problem domain. Often, developers bring their own mindset from previous projects they've worked on to newer projects, whether this mindset suits the problem or not. Therefore, it takes them a few trial-and-error phases to get things done right.
For example, look at Windows CE. Windows CE has a desktop mindset enforced on a realtime environment. It was really too big for the little devices available at the time. Despite Microsoft claims at the time, it was not a realtime OS when it came out. (Microsoft used a weird definition of realtime invented by the automobile industry, at a time when the latter didn't actually understand realtime.) As a result, it took several releases of Windows CE to become moderately successful.
(It's interesting to note that Windows CE, while too big for the little devices they tried to run it on, was exactly right for the embedded systems market, in particular the industrial and military markets; these markets really wanted to use Windows CE, but were almost completely ignored by Microsoft at the time, and a great opportunity was lost.)
Apparently, Microsoft has shifted its opinions over the last few years. This is good, because you really can't beat the combination of talent and domain knowledge. With the job market low as it currently is, there's an opportunity to hire good people, experienced in areas the company isn't.
(Note: I realize Joel is mainly speaking of tools and technologies experience, while I'm talking mainly of problem domain knowledge; you really need both, I claim, to be successful.)