How I (almost) got an internship at Google

I expected better from a company like Google. Asking candidates for pre-canned code snippets to cutesy little CS problems on the whiteboard is miserable and the outcome depends too much on what the candidate studied in the last few weeks before the interview. It actually tells you very little about the kind of programmer a person is and the interview itself can get quite horrible on a personal level very fast.

A while ago, I used to conduct job interviews like this. Sort this, insert that, search for the other. I still feel sorry for some of the candidates I did this to. That process was the largest single mistake I made when hiring people. I should instead have asked for the code of some projects they had been working on recently and maybe discussed a few more creative things with them.

In fact, if I could ask a candidate just one question, it would be "what projects are you working on in your spare time?"

Getting them to write code is actually pretty good.

As for binary search, I wouldn't necessarily be able to bang it out in two hours in C, but I'd easily be able to bang it out in that time for any language I use regularly. And with sufficient testing I'd take a good stab at converting to C.

Though I agree sometimes it can be a coin toss. Once I was asked to write some code that would take dates as inputs and do something with them, it was supposed to take two hours and run on a bunch of test cases they gave you. I spent much more than two hours on it, nailed all the edge cases and boundary conditions that I could think of (basically nuked it from orbit) and turned in something which ran on their test cases and also a much longer list of much more challenging test cases. I got that job.

I missed one where they wanted something written by TDD. Unfortunately, I only know how to design something that works, I don't know how to fake a bad design that organically grows into a workable design. As above I nuked all the boundary conditions I could think of, but didn't get that job.

(Probably wouldn't have been happy there, my experience is that people who do TDD or automated unit testing have way too much faith in those forms of testing, and they neglect other forms of testing, so their actual net amount of testing is well below my standards. Things like: every single programmer I've ever worked with who claims that automated testing is sufficient has always produced code that when they claim they've finished the task it fails the eyeball test. E.g. you run their code and within 10-30 seconds of looking at the result you can spot something wrong with it.)

Weird story here. MS, Qualcomm, Intel etc. everyone shows up really early @ our school. Google comes 2 months later after the offer deadlines have passed. What gives ? I couldn't even interview because I had to accept another offer.

Compared to MS, Qualcomm, AMZN (I'm headed to MS) Google's process is pretty weird.

If someone isn't working on something in their spare time, it's a big red flag to me. You need to have the hunger. I'm more turned on by what you have in your github account than whether or not you can do a binary search in your choice of languages.

Yes, I just looked at the form again (the link still works) and it asks: University, Major, GPA, strongest programming language, second programming language, and preferences for location, and then a five-option part where you rate yourself out of: Not my thing (none) Can make do (fair) Comfortable (good) Comes easily (better) World Class (best)

On the following: 1) Applications and Services: this is Google's term for the software that is directly visible to end users. People who focus on applications and services typically work on improving our capabilities in a variety of areas that span the range from new features to increasing performance and efficiency at Google scale. They will be tasked with devising and building new approaches to Google's problems, and exploring their effectiveness.

2) Systems: People who have a systems focus are oriented towards behind-the-scenes software and systems, often building them from underlying components and services. Systems work spans from platforms (hardware, OS, networking) to infrastructure (shared services such as storage, cluster management) and everything in between.

3) Sys-admin: Our system administrators keep all of Google's systems running, and help deploy new ones. They deal with issues involving single machines to those involving huge numbers. They work with native Linux environments, and Google extensions and services.

4) Verification and Test: Our test teams helps make our systems resilient and reliable - we put a lot of effort into this. Building world class applications at world class scales doesn’t happen by accident. It takes insight, innovation, and precision to verify our systems perform as expected.