Saturday, May 31, 2014

The NCSSM 2014 commencement address

This morning I had the distinct pleasure of delivering the commencement address at the North Carolina School of Science and Math, my alma mater, where I graduated in 1992. NCSSM is a public residential high school in which students attend their junior and senior years, and of course as the name suggests has an emphasis on science and math curriculum (but it is so much more than that). For some reason, the students and administrators asked me to give the commencement address this year, which is one of the strangest things I've ever had to do -- in part because it felt like yesterday that I graduated from there (yet it was 22 years ago)!

NCSSM is dear to my heart and those two years were a transformative time in my life. I've blogged before about how my time at S&M saved my life -- it is difficult to overstate how important the place was to my formative years. (Actually I think I'm still "forming".)

I wore Google Glass to give the speech, thinking this would be a really cool and unique way to show off my "Google-ness", but actually one of the graduating seniors was wearing Glass as well:


So much for being unique.

The school live-streamed the event and I was surprised to find a video of my speech online soon after it was over. Watch here at your own peril.

Below I'm posting my prepared speech (which is not exactly the same as the one I actually gave).

Students, professors, parents, mom, (hi mom!), it is most humbling to stand before you here today. Indeed, I am terrified. Somehow I think I am being punished for all of the misdeeds I was involved with back during my days as a student here so many years ago. Either that, or the fact that I am here must be proof that there is no such thing as a permanent record -- if they had one on me, well, let’s just say they would have thought twice about inviting me back to give a commencement address. So, those of you who stayed out way too late last night -- there is hope for you yet! 
Before we begin, I want to get one thing out of the way. Some of you may be wondering what this thing is that I’m wearing. This is called Google Glass, and basically, it’s a cell phone that you strap to your head. I am told that in some neighborhoods of San Francisco it either makes you utterly irresistible to the opposite sex, or it gets you beat up. Google Glass has all kinds of amazing features, and this little screen up here is feeding me a constant stream of information about each and every one of you … yes, you in the back there… the one who made a B-minus in history last term… Google Glass is telling me that those tennis shoes you ordered off of Amazon last week will be delivered this afternoon. You’re welcome.
It’s really remarkable to be back here, twenty-two years after I graduated from NCSSM, on this very lawn. Of course, I don’t remember much about the graduation ceremony itself, seeing as how I got absolutely no sleep the night before. You see, I stayed up too late with my friends and staggered back to my room at 5 o’clock in the morning and realized I had not started packing my room. At all. And my parents were arriving in just a few short hours, expecting me to be rested, cheery, but most of all packed and ready to go. So I frantically threw everything I owned into boxes, tore all of the Depeche Mode posters off of the walls, packed away my IBM PC and boxes full of diskettes, and tried to make some order out of chaos. I was only partially successful, but my parents understood, and we loaded everything into the minivan, and away we went. Sorry, mom! You guys were great about it though.
Poof. Just like that, my NCSSM experience was over. They really were two of the best years of my life, in so many ways -- and the experiences I had here utterly changed the course of my life. I am sure most of you feel the same way already, but the ripple effect will be felt for years to come. Look around -- look at your friends, your teachers, your RAs. This place has made a deep and enduring mark on who you are and who you will be.
NCSSM taught me the single most important lesson I’ve ever learned in my life, and I want to share it with you.
It’s very simple: Never stop looking. That is, never stop looking for who you are, where you belong, and what you might do with your short time on this planet. Sometimes it takes a really, really big change to figure that out.
Before coming to S&M -- as we called it affectionately in those days -- I grew up in a small town called Wilson, about an hour east of here. I cannot say that I really loved Wilson, and I didn’t fit in well there at all. For one thing, I didn’t have a car, so I could not join the legions of kids who would spend their Friday nights driving in circles around the mall, which was pretty much the only entertainment there. But more than that, with the exception of a few close friends, I never quite felt like I found kindred spirits -- people with the same weird and geeky interests that I had. People who saw the world in the same way.
Fortunately, I was admitted to Science and Math, and I am dead serious when I say that coming here saved my life. Almost as soon as I arrived here, I realized that I had found what I had been looking for all of those years in Wilson, where I was so out of place -- people who cared about the same things that I did. People who were smarter, and weirder, and more interesting than I could ever be. Teachers with an amazing passion and ability to inspire. A cafeteria serving the most amazing food … wait … scratch that … The food was terrible. But at least it was free!
Coming to Science and Math was the first time that I realized that there was a bigger, more incredible, more inspiring world out there than the narrow confines of my experience back in Wilson. I am sure many of you have had the same experiences, over and over again while roaming these halls. Never forget it. It’s the most important thing you can take away from your time here.
This lesson has been reinforced many times in my life. Another time was my first opportunity to travel outside of the developed world. Although I had traveled and lived in Europe during college, it wasn’t until I was a grad student at Berkeley that my wife and I traveled to “difficult” places -- the first such trip being Nepal, where we spent about a month, trekking through the Himalaya. I will never forget the experience of arriving in Kathmandu for the first time, speeding through the night in a taxi, looking out at the eye-popping poverty, the people everywhere, cows and goats and water buffalo roaming in the road, the endless cars and rickshaws and bicycles and motor scooters everywhere -- it might has well have been a different planet. It completely changed my conception of what the world was like, right there, over the course of about ten minutes.
Over the following years, we traveled to many other places as remote as Papua New Guinea, Bolivia, and Laos -- and every time my mind was blown by how strange and big and varied the world is. If I can leave you all with just one thing from today, it would be to encourage you to travel the world. Especially while you are young. Not enough young people do this, and I think it’s the single most effective way to broaden your horizons in life.
I also learned this lesson when I decided to quit my job as a professor at Harvard to join Google. To many people, being a professor, especially somewhere like Harvard, sounds like a dream job. You get tremendous freedom, the opportunity to work with some of the smartest students and faculty anywhere. Mark Zuckerberg, the founder of Facebook, was even one of my students. If you’ve seen the movie “The Social Network”, that scene where Zuck storms out of a Computer Science lecture -- the professor in that scene was supposed to be me -- those were in fact my real PowerPoint slides from class! Of course Mark never stormed out of a lecture -- he wasn’t actually in lecture often enough for that to have happened.
The thing is, being a professor is really, really hard work. You have almost no down time, as there’s always another deadline, another lecture to prepare, another letters to write. It’s grueling. Your teachers here have to work just as hard, so you should really thank them today -- they work their tails off for you.
So after seven years at Harvard, I was ready for a change, and started a sabbatical at Google. And going to Google felt a heck of a lot like what it felt coming to Science and Math for the first time. I mean, nerds everywhere! People wearing socks with sandals! The other day, I went to a meeting, and one of the engineers actually had a live parrot on his shoulder. This is totally normal at Google! And, just like Science and Math, they even have free food! Though you don’t have to work in the cafeteria or rake pine needles. That part’s much better.
I knew almost from the moment I went to Google that that was where I was meant to be -- that I had found my kin. But it took making a big change -- giving up a permanent job, leaving behind my students and colleagues, moving my family across the country -- to figure that out. So it was a big risk, but the reward was huge -- finding out what I really want to be doing with my life, right now. You have to take those risks.
So never stop looking. That’s it. Pretty simple, right? Never stop looking. You never know what you might find.
And with that, I just want to say, congratulations to you all. Today is a big day -- it’s your day. Live it up! Don’t forget it! That is, if you got any sleep last night. If you didn’t, well, you can go back to sleep now because the best part is over.
Thank you very much, and congratulations to the class of 2014!




Wednesday, May 7, 2014

The Google career path, Part 2: Starting new projects

In my last blog post, I talked about what it's like to get started at Google as a new engineer. In this post, I'll talk about how new projects get started.

Standard disclaimer applies: This is my personal blog and nothing I'm saying here is endorsed or approved by Google. This is only based on my personal experience. Take it with a grain of salt.

Google is well known as having a bottom-up engineering culture. That is, new projects typically arise because a group of engineers get together, decide a problem needs to be solved, devise a solution, and convince others to (a) join in the effort and (b) launch it. It is rare -- although not unheard of -- for a Google project to start with a high-level mandate from some executive. (I have heard that this is how Google+ got its start, but I wasn't there at the time, so I don't really know.) More typically, a grassroots effort emerges out of engineers trying to build something that they think is important and will change the world. Or at least scratch an itch.

How my project got its start

My team is responsible for a range of projects to optimize and streamline the mobile web. The main thing we are known for is the Chrome Mobile data compression proxy, which provides users of Chrome on Android and iOS a switch they can flip in the browser to compress web pages by 50%. I thought it might be instructive to talk about how this project came about.

When I started the team in 2011, I was given a very broad mandate: Go fix the mobile web. Initially, we spent a bunch of time just trying to understand the problem. At the time, there were no good tools for even measuring mobile web page performance. Now, we have things like Webpagetest for mobile, but at the time you couldn't get decent measurements without a lot of work. So, we built a testbed for collecting mobile web measurements and bought a bunch of phones and tablets and started collecting data. We spent a huge amount of time analyzing the data and playing around with various technologies, like PageSpeed, to see what kind of gains could be had.

At one point we realized that the only way to move the needle with mobile web performance was to build our own proxy service which could be integrated into a browser. Around the same time, the Chrome Mobile project was ramping up, and we realized that the technology we were building would be a great addition to Chrome when it became available for Android and iOS. So, we went to the Chrome team (which we were not yet a part of) and pitched the idea -- would it make sense to integrate this hypothetical proxy into the browser, provide a setting for users to enable it? At the time, we didn't even have the proxy yet -- just a slide deck and a crude, proof-of-concept demo. But we had a lot of ideas of what it could do and how it would work.

Fortunately, the Chrome team loved the idea and even offered to take our team on as part of the Chrome project. Of course, they hadn't agreed to launch anything yet -- that approval wouldn't come until many months later -- but we had their blessing to develop the idea further and get it to a state where it could be dogfooded within Google. So we built it. We got it to dogfood. We collected data from real users (well, Googlers anyway). The data looked good, so we got approval to launch it externally, first behind a flag, then in the Chrome beta channel, and finally launch it to everyone. Boom!

So the idea for the proxy service and the project as a whole came entirely from within our team. Nobody told us to do this. And it was our job to "sell" it internally, in terms of turning the idea into a fully-baked feature that could launch with Chrome. In a lot of ways, it's like being a startup company (although one that does not have to worry about funding and already has fancy cafeterias and a gym).

Does this generalize?

I can't say for certain that my experience is the standard way of getting new projects off the ground at Google, but it seems to be.

Projects often seem to get their start with one or two engineers who have an itch to scratch, and come up with something compelling that they want to build. They might start the project on their own, in their 20% time (on which see more below), or they might spawn an effort out of their existing work.

A typical example might be where an engineer realizes that a new system needs to be built to solve a problem that they keep running into all the time (measuring mobile web pages, say). So with the blessing of their manager (or not, in some cases), they carve out time to get that project off the ground. If it's successful, it might grow, and more engineers will start to get involved.

New projects often die, too. Sometimes a project will start out with a couple of people, they'll spend a quarter or two trying to get it off the ground, and the effort fizzles out for any number of reasons. One example is that it turns out to be much harder than expected. Another is that other priorities come up and they don't have the time to run as far with the idea as they had hoped. Another is that some other project comes along which is a broader, more general form of what they were trying to do, so they decide to join forces (or just shut down the original effort).

What about 20% time?

Much has been written about Google's "20% time", whereby engineers are allowed to work on projects unrelated to their main job. (You can't do just anything for 20% projects -- taking guitar lessons wouldn't be allowed, for example -- but the definition is pretty broad.) 20% projects are a great way to seed a new effort, since (a) you don't really need any formal approval to work on them, and (b) it gives engineers a chance to do things that they would not otherwise find the time to do.

Gmail famously started as a 20% project. (The original press release was ironically posted on April 1, 2004, but it was not actually an April Fools' joke!)

There have also been many unfounded rumors of 20% time's demise. From where I sit, 20% time is alive and well, and several engineers on my team have active 20% projects. For example, one of them contributes actively to our internal platform for employees making charitable contributions, called "G-Give". Another contributes to the smart contact lens project. My own (unofficial) 20% project is doing outreach activities to the Computer Science research community -- serving on program committees, reviewing research proposals, that kind of thing. (It actually takes a lot less than 20% of my time, but don't tell my boss that.)

That said, 20% time is not used uniformly across the company and some managers are probably allergic to it. I don't think all engineers should do 20% projects, since often people can have more impact if they spend 100% of their time on their "day job" -- the 20% would be a distraction and not necessarily help them get promoted.

But promotions are the subject of my next blog post, so I'll leave it at that.

Thursday, May 1, 2014

The Google career path, part 1: Getting started

Apart from how to get a job at Google (which I have previously blogged about), the most common question I get from people considering taking a job here is what the career path is like -- that is, how you get started, how you grow your career, how promotions work, and so forth. I thought I'd try to capture some of my perspective in a series of blog posts on the topic.

(But first, the obligatory disclaimer: This is my personal blog. Google doesn't condone or support anything I'm saying here. Heck, it's probably all wrong anyway. Take it with a grain of salt.)

This stuff is mostly targeted at new grad hires (at any level -- Bachelors, Masters, or PhD) for software engineering positions. (I don't know how things work in other parts of the company, like sales.) This may apply to a lesser extent to more senior engineers or researchers as well.

Before you join: The team match

Before your start date, you will be assigned to one of the many hundreds of teams at Google. While there are exceptions, teams typically consist of O(10) people who all report to the same manager and have a common project focus. Examples might include the Android Hangouts app, feeding real-time data such as sports scores into Search, or (my team) making mobile Web browsing faster and more efficient.

A lot of people want to work on teams doing things they have already heard of -- such as Search, Chrome, or Android. But keep in mind that the vast majority of teams at Google work on things that are (a) not user-facing and therefore (b) not something you would necessarily know anything about before coming here. My first team at Google focused our content delivery network for YouTube, which I never even knew existed until I started the job. Many project teams are building internal infrastructure and tools, and often the work they do is highly confidential, so we can't (unfortunately) always tell new hires very much about the details of what the team works on until they join.

Google tries to assign you to a team that matches your interests. If you are a Bachelors or Masters new grad hire, the team match is typically done in a "late binding" fashion, a few weeks before the start date (so, after you have accepted the job offer). Given how rapidly projects and hiring priorities shift among teams, it makes sense to do the binding as late as possible. For PhD and more senior candidates, because your skills are more specialized, the recruiters try to make sure that the candidate has a team interested in hiring you even before bringing you in for an interview. As a result, you essentially have a spot "reserved" on that team well before you would begin the job. In those cases you might be able to learn a bit more about what your target team is working on during the process of interviewing and negotiating the offer.

The thing I always emphasize is that when you are hired by Google, you are getting a job at Google, not a specific team at Google. In other words, the initial team match is by no means final, and nor is it locking you down. Engineers move between teams all the time -- it is not uncommon for people to look for a new team every couple of years. Some people prefer the stability of staying in the same area year after year, while others prefer to explore different parts of the company. New projects and teams are always spinning up, and (indeed) teams often reorganize or disband. So there is a fair bit of churn, and I would not stress the initial team assignment much -- it's a starting point.

The starter project

My advice to people starting at Google is to roll up your sleeves, dive in, and start contributing however you can. It's a super steep learning curve, and for the first month or two you won't have the foggiest idea what anybody is talking about, but the more you get involved the faster you'll come up to speed.

The first week on the job is typically spent in orientation, which is usually done at the headquarters in Mountain View. I blogged about my first week at Google a while back -- it is pretty intense, and there is a huge amount to learn. I found it to be super fun (though exhausting) and have great memories of that week. You get your badge, your laptop, your first five or six items of Google schwag, try to figure out where to get lunch, how the videoconference system works, and how to get started on programming in our insanely complex environment. There are a bunch of hour-long courses on topics ranging from how Google Search works to how to use our source code control system.

After the first week you'll start working with your new team. Your starter project is intended to show you the ropes and get you up to speed on our coding environment, build tools, code review process, and so forth, so you can start to be a fully productive member of the team. Starter projects might be something like adding a small feature to your team's code or fixing a straightforward bug. A starter project might take anywhere from a week to a month.

Taking ownership

As you come up to speed, you'll proceed to taking on projects with larger complexity and scope, as you become more familiar with the codebase and conversant in the problems that are being worked on by your team. It's really up to you to drive this process and own your work.

To give a concrete example, one of the (relatively) recent PhD hires on my team, Michael Buettner, started out by investigating the size and quality tradeoff for the image transcoding parameters we were using in the Chrome Mobile data compression proxy. Over time he expanded his expertise of our software and started taking on harder, bigger problems -- including sophisticated optimizations to the proxy's HTTP fetching backend. He is now our team's "latency expert" and has devoted a great deal of his time to making the whole system faster. Since he knows so much of our codebase, he advises on a broad range of new features and bugfixes, and works with other teams to implement functionality to streamline our system's performance.

I want to emphasize that this is not something Michael was specifically tasked with doing. Like most teams, ours has way more problems than people, so engineers tend to gravitate towards the problems that match their interests. My job as the team lead is to coordinate and prioritize our team's work, and fortunately we rarely have cases where we have something really important to do that's not up someone's alley.

In the next couple of blog posts I'll talk about the evaluation and promotion process at Google, as well as how new projects are started.

Friday, February 28, 2014

Taking the "Hot" out of "Hot Topics" workshops

I just got back from HotMobile 2014 (for which I was the general chair). HotMobile is the mobile systems community's "hot topics" workshop, held annually as a forum for (according to the Call for Papers) "position papers containing highly original ideas" and which "propose new directions of research" or "advocate non-traditional approaches". It's a small workshop (we had about 95 people this year) and the paper submissions are short -- 6 pages, rather than the regular 14.

The HotMobile'14 poster and demo session.
Look how happy those mobile systems researchers are!
Overall, the workshop was great -- lots of good discussions, good talks, interesting ideas. And yet, every time I attend one of these "hot topics" workshops, I end up feeling that the papers fall well short of this lofty goal. This is not limited to the mobile community -- the HotOS community has a similar problem as well.

This has bugged me for a long time, since it often feels as though there is no venue for doing "out of the box" work that is intended to look out five or ten years -- rather than just things that are incremental but not yet ready for publication in a major conference like SOSP or MobiSys. I also have fond memories of HotOS in the late 1990s in which it felt as though many of the papers were there to shake up the status quo and put forward a strong position.

What I've now come to realize is that there is a tremendous value in having a small workshop for preliminary (and often incremental) results. The community obviously feels that such a venue is useful, despite its lack of "hotness" -- we had a record number of attendees this year, and (I believe) a near-record number of submissions.

And after all, the main reasons to attend any workshop are the discussions and networking -- not the papers.

The problem is that we insist on calling this a "hot topics" workshop and pretend that it's about far-out ideas that could not be published elsewhere. Instead, I think we should be honest that HotMobile (and HotOS, HotNets, etc.) are really for three kinds of papers:
  1. Preliminary work on a new project which is not yet ready for a major conference. Getting early feedback on a new project is often very useful to researchers, so they know if they are barking up the right trees.

    An example of this from this year is the CMU paper on QuiltView, which proposes allowing users to pose real-time queries ("How is the weather down at the beach in Santa Barbara?") and get back real-time video snippets (from users wearing Google Glass!) in reply. This work is no where near mature enough for a full conference, and I hope the authors gained something from the paper reviews and discussion at the workshop to shape their future direction.
  2. An incremental, and possibly vestigial, step, towards the next major conference paper on a topic. Many such papers are simply not big enough ideas for a full conference paper, but make a nice "short paper" for the sake of getting some idea out there.

    One example from this year is this paper on the dangers of public IPs for LTE devices. This isn't something that's going to turn into a longer, more pithy paper later on, but is probably worth reporting.
  3. The odd wacky paper that falls under the "hot topics" rubric. These are increasingly rare. About the only example from this year is this Duke paper on adding smart capabilities to childrens' toys with smartphones -- but the idea is not that radical.
Last year at SOSP, there was a one-day workshop called TRIOS ("Timely Results in Operating Systems") which was an informal venue for preliminary work -- exactly to provide an outlet for papers in the first two categories above. At least TRIOS was honest about its intent, so nobody attending could be disappointed that the papers weren't "hot" enough.

So, my humble proposal is to rename the workshop "ColdMobile" and, just to be cheeky, hold it at a ski resort in the winter.


Thursday, January 30, 2014

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.

Tuesday, January 21, 2014

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.


Sunday, January 19, 2014

Google did not steal the smart contact lens from Microsoft

Wired is carrying an article rather provocatively entitled, "Google Stole Its Smart Contact Lens From Microsoft. And That’s a Good Thing." While the article makes a few good points, the gist of the headline is dead wrong. I now work at Google, but I was previously an academic myself and received a significant amount of funding from Microsoft while I was at Harvard. (Standard disclaimer applies: This post represents my own opinion and not that of my employer.)

The Wired article gets it wrong when it claims that Google "stole" the smart contact lens project from Microsoft. It's true that Microsoft funded the original project being done by Babak Parviz when he was on the faculty at the University of Washington. Google then subsequently hired Babak (and Brian Otis, another UW faculty) to develop the project further, which was recently announced on the Google Blog. However, I don't think anyone would consider this "stealing". Suggesting that it does is a real problem, since it undercuts the open model used by many companies for funding university research.

It would not surprise me if Microsoft hired former faculty to work on projects that were originally funded by Google's university research programs (which, like Microsoft, provides millions of dollars a year to university projects to undertake research). These kinds of industry research gifts generally have no strings attached. As the recipient of several Microsoft research awards, I could have used the money for anything -- pizza parties for my grad students, extravagant trips to the tropics -- without any repercussions, apart from gaining a poor reputation and probably excluding myself from consideration for future Microsoft awards. Likewise, the research output that these gifts funded had no intellectual property restrictions: the research was wholly owned by the university, and Microsoft received no IP rights whatsoever.

This is a great model for industry research funding. It provides researchers with the maximal amount of flexibility, and does not preclude a researcher from funding one project from multiple sources (even multiple awards from competing companies).

The Wired article does make a good point that Google seems to be doing a good job at taking these kinds of moonshot research ideas (like self-driving cars, Google Glass, and the smart contact lens project) to the next level, beyond the lab. But the implication that Google "stole" the research "from" Microsoft is disingenuous. I am sure most academics, and even Microsoft folks, would agree.