People's been asking me questions every now and then – how to prepare to an interview at Google? Obviously, there are tons of documents online with supposed lists of questions (subtle hint: most of them are obsolete). So I finally decided to write this up in a hope that someone will find it useful. This is far from complete, just a few items I think it was worth mentioning.
First of all, let’s state this: an interview at Google effectively is no different from an interview in any other high-tech company – at least not in principle. It can be more complex, true, but it’s not different. So here I’ll be speaking about the interviews in general.
First of all, you should be reasonably sure that you are a good match for this position. For example, if you are a fresh grad and have zero experience, it will be a waste of everyone’s time to apply for a senior position — even if with some luck you will get to the interview stage, you will simply waste your and your interviewer’s time. Think about it before sending your CV. I will also assume that you are reasonably proficient with your language of choice (e.g. you can Google for “Java Interview Questions”, and answer all the questions you find within first three results without thinking).
Second idea is based on the fact that during the interview you will largely be asked two types of questions: tricky algorithmic questions and design/architecture type of questions. Brainteasers, frankly, are outdated: less and less questions are asked about fitting an elephant into a freezer, since they are basically no good for anyone.
Algorithmic questions are tricky. This is where you shine as a coder. In my opinion, the best way to prepare for this part is go to TopCoder and solve a couple of problems every evening. When you feel you lack some knowledge you may need to go and revisit some of your university textbooks – especially those about combinatorics, theory of probability, graphs and game theory. In my opinion, this is not the easiest way but it most certainly works (well, it worked for me). After you have a hundred or so problems under your belt (with some of them being from a higher categories of complexity) you will start seeing patterns and automatically transform vague problem definition into a sequence of mathematical and algorithmic concepts you need to use to solve this problem.
Other part is design questions. Now, this is where it gets complex. You see, part of the problem is that bad algorithm either doesn’t work or works unacceptably long. Bad design may not be so obvious to spot. This makes it inherently more complex to drill yourself in design questions – even if you know all GoF patterns by heart, it will help you very little if you can’t spot the types of situations calling for one of those patterns. There are two ways out here: real work experience and open-source projects. Obviously, if you already have a job, you will probably gain enough of experience - at some point, anyway. However this might not always be the case, or you may think that you are not doing anything that improves your skills in this particular area. In this case open source projects come to rescue. You can either join an existing project or create a project of your own. Honestly, I recommend both of this options. When you join existing project, you can become a part of a team, see how design decisions are made and how they affect the life of a project, you can learn from more experienced guys and try yourself at something real. When you start writing your own project, you can actually go all the way from the inception of an idea to implementing it in code and (hopefully!) dealing with angry users who don’t like this, and want that. This is immensely interesting and helpful. You should also consider, that many companies (Google included) consider participating in Open-Source projects extremely important and valuable and largely put an equality sign between work and open-source experience.
I hope this was helpful - feel free to comment/email me with more questions, I will try to update this page with anything of importance.