How I (almost) got an internship at Google

This actually might the crux of the difference. While we have an open moonlighting policy the people that work here are a lot more likely to use the extra coding energy on something directly related to the priorities we have. There's no shortage of things to do. And t's not like you spend three straight weeks fixing bugs -- there's plenty of diversity in things that we need to in the business -- and I suspect most companies I'd want to work at are similar.

And again, I'm not necessarily against side projects. But it seems like an odd way to measure a potential employees passion to the job. It does seem like a great way to measure their passion for side projects, but we generally aren't hiring people explicitly to work on side projects. It seems like a much better way to measure their job passion is to see what they actually did at their job -- look at what they shipped.

If they shipped a crap product, but had a cool side project, what is that really saying? If anything its telling you to NOT hire them, but to get them interested in your product on the side! :-)

The reasoning appears to be that you're either good enough or you're not, and that it doesn't matter who interviews you for that to be true. However, the difficulty was really variable: interviewer 1 asked lots and lots of algorithms questions which I wasn't doing well on, caused him to become obviously annoyed with me. 2 seemed fairly ambivalent throughout. 3 really worked with me to try and get answers out of me (even though I was incredibly nervous).

I don't see why phone screens are not with prospective teams; they're the ones that will have to deal with you and have the best idea of what skills they need. Maybe they're trying to avoid people building up little fiefdoms? I generally came out feeling the way you do (and the way the OP does). It seems random, and for a company that (rightly) prides itself on the quality of its data and making data-led decisions, it makes it sting doubly.

That was my first interview, and they said at first it was going to be a coding interview. My next interview was a design interview. We talked at length about designing a simple web application, which got increasingly sophisticated as we progressed. But my interviewer did ask me to write code to demonstrate what I had in mind from time to time and I had to code up some small methods and classes to show him. No puzzles. No CS theory or abstract problems. Just what I would do if I were building a real world application.

Oh, and they asked about what projects I had worked on both interviews.

I have been an interviewer in the place where I work currently, and I always asked candidates to write code. Some guys here ask puzzles, but I don't like that. Puzzles (like how to find you who's lying in an island on people or something) don't really show anything in an interview situation. But a short programming problem, demonstrating the ability to identify and use a well known data structure or algorithm, or to use good sense and understanding to design a solution to a problem does go a long way to show that a candidate can actually code and get stuff done. I've seen lots of bad candidates impress us with their knowledge of tech buzzwords, past projects in their CV and even talking about design patterns, but fail miserably when asked specific questions or writing even the simplest amount of code.

But if someone asks me about trains and birds, I would seriously reconsider working there

I wish it didn't play games in recruitment. I had already accepted an internship at Facebook by the time Google called. In the end I'm glad I did, because I really enjoyed Facebook and am going back full time.