Getting a job at Google for PhD Students

I happen to sit on one of the hiring committees at Google, which looks at interview packets and makes a recommendation about whether we should extend an offer or not. So I've read a lot of packets, and have seen some of the ways in which applicants succeed or fail to get an offer. Ph.D. students, in particular, tend to get tripped up by the Google interview process, so I thought I'd offer some advice.

While I can't be certain, I imagine this same advice would apply to other companies which have a similar interview process that focuses on coding and algorithms.

(Disclaimer: This is all my personal opinion, and nothing I'm saying here is sanctioned or recommended by Google in any way. In fact, it might be totally wrong. Take it with a grain of salt.)

Google's interview process

Google uses a fairly typical industry interview process: Candidates go through one or two phone screens (or possibly an on-campus interview), and if they do well they are brought on campus for a full interview loop. Each interview is an hour and consists largely of problem solving and coding on the whiteboard. Sometimes a laptop is used.

This same process is used for all software engineering positions, regardless of level: undergrads, PhD students, and seasoned industry candidates all get the same style of interview. I had to go through this interview process upon joining Google as a professor. PhD-level candidates will generally spend one interview slot discussing their thesis work, and the questions may be more "researchy", but by and large it's the same for everyone.

The problem

Ph.D. students often tend to do worse on coding interviews than, say, bachelors' or masters' level candidates. Why? Doing a Ph.D. simply does not train you in professional software development skills, and that is (primarily) what a Google interview tests for. Undergrads, paradoxically, often do better because (a) they may have done internships at companies writing code, and (b) have practiced for this style of interview in the past.

There is a widespread belief that doing a Ph.D. somehow elevates you above the need to demonstrate fundamental algorithms and coding skills. Having a Ph.D. from Berkeley is awesome, but you still gotta be able to write good, clean code.

Also, part of the long process of doing a Ph.D. means you get hyper-specialized, so you get farther away from the "basics". Many of the Google interview questions touch on topics you probably first encountered (and mastered) as a sophomore or junior in college. I don't know about you, but I never dealt with binary search trees or graph connectivity problems directly during my Ph.D. and subsequent years as a faculty member. (Then again I'm just a systems guy, so the most sophisticated data structure I ever deal with is a hash table.)

Why the basics matter

Being at Google means writing production-quality software. We don't have "research labs" where people primarily build prototypes or write papers. I have written about Google's hybrid research model elsewhere -- also see this CACM article for more. While there are exceptions, by and large being at Google means being on a product team building and launching real products. That is even true of the more far-flung projects like self-driving cars and high-altitude Internet balloons. The quality and professionalism of the code you develop matters a great deal.

Doing a Ph.D. generally trains you for building research prototypes. There is a vast difference between this and writing production-quality code. First of all, it's not good enough for the code to make sense -- or be maintainable -- only by you or a small number of collaborators. Adherence to good design, avoiding overcomplicated code, conforming to style guidelines, etc. are all super important. In addition, you have to really concern yourself with robustness, scalability, testability, and performance. Corner cases that aren't interesting for publishing your next paper can't be overlooked.

Most of these skills can only be developed by working with a professional software development team. Research and class projects don't give you a chance to develop these skills. Undergrads gain these skills largely through internships. Unfortunately, most PhD students do internships at research labs, which may or may not provide much opportunity to build production-quality software.

Advice for grad students

If you're interviewing at Google, bone up on your basic algorithms and data structures. Go dust off that sophomore-level textbook and try to page it back in. I also highly recommend the book Cracking the Coding Interview, which gives the best description I have seen of Google-style interviews - it was written by a former Googler.

Don't go in with the attitude that you're above all this. Roll up your sleeves and show them what you've got. I know it may feel silly being asked what seem like basic CS questions, but if you're really as good as you think you are, you should knock them out of the park. (Keep in mind that the questions get harder the better you are doing, so no matter what, you will probably feel like crap at the end of the day.)

Every line of code you write on the whiteboard will get written up as part of the interview packet. Make it squeaky clean. Initialize variables. Use semicolons. Don't forget your constructors. Although writing sloppy pseudocode to get your meaning across might seem adequate (after all, we're all professionals here, aren't we?), attention to detail matters. Code in C++ or Java, which shows maturity. If you can only code in Python or bash shell, you're going to have trouble. If you make the slightest suggestion of wanting to code in Haskell or Lisp, the interviewer will push a hidden button which opens a trap door, dropping you into a bottomless pit. (Just kidding.)

Never, ever suggest you are a "C++ expert", either on your resume or in person. You are not.

Unfortunately, Google interviews tend to be a bit one-sided and you will not have as much opportunity to learn about Google (and what projects you might be working on) as you would like. If you do get an offer, you'll have more opportunities to come back and ask those questions. Google is notoriously secretive, so you have to trust me that there are plenty of cool things to work on.

Finally: Remember that the content of the interview has nothing to do with the kind of projects you would work on here. You're not going to get hired by Google and be asked to implement depth-first-search or reverse a linked list -- trust me on that. I'm pretty sure we have library routines for those already.

Your Field Guide to Industrial Research Labs

There are a lot of different kinds of industrial research organizations out there. Identifying them can be tricky, so I've compiled this field guide to help you out.

The Patent Factory Research Lab

This is the classic model of research lab, and the main model that existed when I was a grad student in the late 1990s. Many of these labs no longer exist, or have transformed into one of the models below. Generally attached to a big company, this style of research lab primarily exists to bolster the parent company's patent portfolio. A secondary mission is to somehow inform the long-term product roadmap for the parent company, which may or may not be successful, depending on whether the research lab is located 50 miles or a mere 15 miles away from any buildings in which actual product teams work.

How you know you're visiting this style of lab: The main decoration in researcher's offices are the little paperweights they get for every 20 patents they file.

The Academic Department inside of a Company Research Lab

This model is somewhat rare but it does exist, and a couple of companies have done a superb job building up a lab full of people who would really like to have been professors but who really don't like teaching or getting too close to undergraduates. This style of research lab focuses on cranking out paper after paper after paper and padding the ranks of every program committee in sight with its own members. Product impact is usually limited to demos, or the occasional lucky project which gets taken in by a product team and then ripped to shreds until it no longer resembles the original research in any way.

How you know you're visiting this style of lab: It feels just like grad school, except everyone gets their own office, and there are a lot more Windows desktops than you would normally expect to see.

The Why Are We Still Here, Let's Hope The CEO Doesn't Notice Research Lab

This type of research lab exists only because the C-level executives have either misplaced it or forgotten it exists. Researchers here are experts in flying under the radar, steering clear of anything that might generate the slightest amount of media coverage lest they blow their cover. When asked what they are working on, they generally mumble something about "the cloud" which grants them another two-year reprieve until another VP-level review comes around, at which time everyone scrambles to put together demos and PowerPoint decks to look like they've been busy.

How you know you're visiting this style of lab: Nobody has the slightest idea what's happening in the actual research community, and the project titles sound auto-generated.

The It's We-Could-Tell-You-But-We'd-Have-To-Kill-You Research Lab

This type of lab deals exclusively in classified defense contracts. These labs all have innocuous-sounding names which evoke the Cold War and bygone days when it was acceptable, and even encouraged, to smoke a pipe while working in the lab. Projects are done under contract from some branch of the military and generally involve satellites, nuclear warheads, lasers, or some combination of the above. On the plus side, this is the type of lab where you are most likely to encounter alien technology or invent time travel.

How you know you're visiting this style of lab: All project names are comprised of inscrutable acronyms such as "JBFM MAXCOMM"; nobody seems to have a sense of humor.

The "We Have a Research Lab Too" Research Lab

This is the model exemplified by startup companies who are feeling jealous that they don't have enough Ph.D.'s working for them and feel the need to start "Doge.com Research" to make their mark on the world.  This generally happens the first time such a company hires an ex-academic and makes the mistake of putting them in any kind of leadership role. Projects in this kind of lab aren't that different from regular work on the product teams, apart from the expectation that launching anything will take three times longer than a non-research team would be able to do.

How you know you're visiting this style of lab: Hoodies with the word "Research" on them; free lunch.