Visited a friend at their Mountain View campus for free lunch and was contacted soon by a recruiter after passing along my resume. The recruiter sent links in an email to resources that help you prepare for CS fundamentals, including the 'How to Hack a Google Interview' pamphlets.

I quickly scheduled and went through just one technical phone screen, where I had to write code using CollabEdit and talk on Skype.

There were two questions:

• The interviewer pasted a function signature for 'double pow(double a, int b)' and I had to write the body. That was pretty easy, but you do have to know the fast exponentiation algorithm.
• The other question was implementing 'double rpn(List ops)' to compute some result using RPN. This was also very easy (using a stack), but do watch out for edge conditions and handle exceptions.

I got confirmation for an onsite interview after two days and gave myself a week to prepare before meeting for one-on-one interviews. There were six pairs, covering the areas of technical presentation, three algorithmic programming problems, and one system design problem.

The first interviewer walked me to lunch and chatted about my work history; nothing technical. Just make sure you have rehearsed lines about your accomplishments and be enthusiastic.

The following three interviews (in three hours) were all on programming. The first one was fairly short: implement 'int[] intersect(int[] x, int[] y)' given two sorted integer arrays and provide the big-O for your best solution. The key here is to think through the problem (but talk so they don't think you're stuck and idling), then write on the whiteboard.

The interview room was only around 8'x6', with a small round table, three stools, and a full wall of whiteboard. The hardest part, unless you're already familiar with the drill common to top Silicon Valley companies, is writing code on the whiteboard where it's difficult to add and delete lines, such as when you need to declare a new variable halfway down the board. There were three panes, and for some questions, I had to switch back and forth, which likely confused me when I was wiping lines with my hand and adding ugly arrows to insert lines (instead of erasing already crafted lines) and messing up indentation. You get the idea. I understand that good whiteboard presentation with clearly legible writing is important, but I wished that wasn't tackled on as you're trying to solve a tough coding problem. One of the interviewers pulled out his phone and took a photo of the whiteboard of one of my least proudest work (I'm usually known as an anal-clean coder).

The system design question seemed hardest, as I got stuck on trying to use more complex structures than was probably necessary, like load-balanced message queues, distributed hashmaps of sorted structs containing five URLs and their timestamps, and using LRU methods to garbage collect old data. I had to ask for a hint, but that likely sealed my fate. A better, but certainly not the only, solution would be to use buckets of a fixed time interval. It seems easy, but often the bad ideas just won't go away when under pressure.

In the final session, the interviewer asked me to pick my favorite project and describe the design in detail. Actually, the paraphrased question was: 'You just hired a new developer on this project; how would you get them up to speed on developing this new feature?' I described a bit about project and release management logistics, but they were more interested in hearing about and seeing class diagrams, module, component, and network topologies.

Finally, the question that threw me off a bit was (since the project I described happened ten years ago): 'How would you modernize the project for 2012? What different components or approaches would you use and why?'

One thing that I reacted negatively to was that all the interviewers were scheduled to arrive at the room on their assigned hour. Since the first one was late by over ten minutes, most of the sessions ran past their hour slot, with the next interviewers opening the door and interrupting my thought process, only to be told 'Can we have five more minutes?' and the interviewers standing up and nodding, basically saying 'Alright, just wrap it up.'

I waited two full days before being emailed about the rejection; no personal call unless you've made it past the gate, I suppose.

How would you design an enhancement to the LinkedIn homepage that displays 24-hour trailing lists (5-minute, 1-hour, 1-day) of the top 5 URLs that users post onto the site?

Given an interface called IntStream with methods hasNext() and next(), implement the function IntStream merge(IntStream[] streams) where each input IntStream produces strictly increasing, possibly infinite numbers of integers, and the resultant IntStream also produces strictly increasing integers by merging the input streams. The interviewer also provides a simple test harness that prints the first 5000 integers from that function.

Given a single-line text string and a maximum width value, write the function string justify(string text, int maxWidth) that formats the input text using full-justification. Extra spaces on each line are equally distributed between the words; the first word on each line is flushed left and the last word on each line is flushed right.