How to get a faculty job, part 1b: How to get an interview

Back in Part 1 of this series on how to get a faculty job, I said there would be three parts in total. Well, I lied. I realized it would also be helpful to shed light on the process as seen by a faculty hiring committee, so in this post I'll augment Part 1 with a little behind-the-scenes of how hiring committees read and rank applications, and how interviews are granted. The "real" Part 2 will be about the interview itself, and Part 3 about negotiating the offer.

I served on the hiring committee at Harvard back in 2008 when we hired three great new Computer Science faculty: Krzysztof Gajos, Steve Chong, and Yiling Chen. It was an exhausting, months-long search with a dozen or so interviews for multiple openings (it had been a few years since we had any faculty openings and we really opened up the floodgates). So I have a little sense of how the sausage is made.

It's a complex process and utterly opaque for the poor applicant, who will usually not hear anything for many months after submitting the application. Most of the time, the response is a polite email from the hiring committee chair that because of the large number of highly qualified applicants for the position, they are very sorry that they will be unable to interview you. That is, if they ever contact you at all. Most schools don't bother even declining your application explicitly. You just never hear anything. (As for me, I'm still holding out hope that Stanford wants to interview me. It's only been 10 years since I sent my application, I guess it's still under consideration.)

Sometimes, though, you get lucky and are actually granted an interview. The most direct approach is an email saying that they are very interested in your application and would like to see if there are some dates you would be able to come for an interview. However, in some cases, a school doesn't want to "blow" one of its precious interview slots (more on that below) on an applicant who is not serious about their school. This will happen for a rock star candidate who is going to get interviews at MIT and Berkeley and only applied to your school to be polite, or as a backup. It would be a waste of time to interview such a candidate unless the department really feels it has a shot at landing this person. So, rather than directly offering an interview, the hiring committee might use side channels to find out if the applicant is serious about interviewing first -- for example, by getting in touch with the student's advisor and finding out more about what they're looking for in a school.

It's important to keep in mind is that whenever there is a faculty opening at any halfway-decent academic department, they will usually get inundated with hundreds or even thousands of applications from all corners of the globe. I am not exaggerating. The vast majority of these applicants are from schools you've never heard of in random countries where English is not the official language, and these people will rarely if ever get interviews (at least at good schools in the US).

The other thing is that most departments have only so much "interview bandwidth." Interviewing more than, say, a dozen applicants for a single position is very difficult. An interview typically lasts one or two days, you only have so many slots during the week in which to schedule job talks, and the committee has to spend a lot of time processing and discussing each interview. If a school has multiple openings in a year, they might still only interview a dozen or so candidates in total.

So, how do hiring committees decide who gets interviewed? There are about a million variables involved, but here are some of the most important:

Qualifications. Obviously this is important, but who counts as "qualified?" Your publication record is probably the strongest indicator of your success. Publishing at least one major conference paper a year -- after your first year or so in grad school -- is par for the course. Two or three papers would be a good year for most applicants. These have to be in good venues: Top-ranked, highly-competitive conferences. Workshops don't count (OK, maybe a little, but a lot less than real conferences). Journals don't count either. (This varies by field. In Computer Science, journals don't matter very much. But an article in Science or Nature will get you interviewed just about anywhere.)

Also, being first author on these papers is really important. Second author says, OK, maybe this student wasn't the most senior one on this piece of work, but they probably still contributed a lot. Third author on down conveys that you were not that involved and therefore get fewer points for the publication.

So you should expect to have something like five or six major conference publications -- ideally as first author -- on your CV, at minimum, to be taken seriously by most departments. Best paper awards are a big plus too, so list them on your CV whenever you get one. It is not uncommon these days to see applicants with ten or more top papers. I think this is a little insane. If you do a postdoc, though, you're expected to publish a good chunk of papers during that time, at minimum two a year -- the bar is higher for postdocs.

Your academic credentials matter a lot too. Your undergrad institution is not that much of a factor. I know plenty of famous faculty at top-10 schools who went to seemingly random undergrad institutions: Greg Morrisett, for example, apparently graduated from some place called the University of Richmond, which I'm sure is a very good school but is hardly a household name. What matters much more is where you went to grad school and (if you are doing a postdoc) where you postdoc. There is a reason that so many of the faculty at top-20 CS departments graduated from the likes of MIT, Berkeley, CMU, and Stanford -- graduates of these schools are highly sought after by CS departments and they tend to churn out enough graduates to fill the ranks of the top departments. So if you're coming from anything other than a top-20 school yourself, your chances of landing an interview at a higher-ranked institution are slim to none. (I know a bunch of people will argue with me here, and point out exceptions to the rule, but let's be honest. There is a strong preference for graduates of top-ranked departments when trying to pick 10 or so candidates to interview out of a pool of hundreds.)

The same goes if you're doing a postdoc. Actually, a postdoc can be a great way to increase your station in life if you didn't graduate from a name-brand department but still want a decent faculty job. Postdocing at MIT is almost (but not quite) as good as graduating from there.

The good news is that none of this shit matters if you do get an interview: No sane hiring committee is going to go back to your résumé and say, "Well, I really loved her interview, but she graduated from a lower ranked school than the other guy, so let's hire him instead." All of this is just about getting the interview. After that you're on your own.

Being a woman or a minority helps too. Hiring committees spend a lot of time trying to find anyone other than white men to interview, and most departments would love for their next hire to help increase the diversity of their faculty. This is a good thing, and is becoming more important as the diversity of the student population grows as well. If you happen to be one of these "underrepresented" candidates, more power to you -- given how competitive the academic job market is, you need every advantage you can get. (But see above about how this doesn't matter once you get the interview. That applies here too.)

Research area fit. This is a really complicated, multivariate function, in which the department attempts to discern, based on your CV, research statement, teaching statement, and letters, how well you would "mesh" into the department, whether you do the "kind of research" they are looking for, whether you can teach the classes that require coverage, and if you are likely to find collaborators in the department. It sounds like a lot to worry about, but the answer for you, as an applicant, is simple: It's too late for you to do anything about this. If you're a sixth-year PhD student applying for faculty jobs, it's too late to "rebrand" yourself to try to optimize for some complex, black-box process that is going on within each of the departments you're applying to. The time to figure out what research problems are going to look sexy on a job application is when you're a first or second year grad student, but, by the time you graduate those problems are just as likely not to be sexy anymore -- so instead, just do the research you love and hope you find a department that is looking for someone like you.

Sometimes you don't get an interview due to factors totally beyond your control. For example, I didn't get interviewed by a couple of departments because they had just recently (in the last year or so) hired graduates of my same research group at Berkeley. That poisoned the well for me -- there was no way I could pretend to not be doing research in the same area under the same set of professors. (There are still times I shake my fist at the night sky and scream "Armandooooooooooooo!")

Finally, your recommendation letters are key. I could write an entire blog post about what a good faculty recommendation letter should say, but you as a job applicant have little control over what your letters will look like. The letters touch on many things: Your technical and intellectual capacity, your research taste, your teaching style, your personality, your chances at getting tenure down the road. As an applicant, what you can do is make sure you talk to your letter writers before they write the letter. This is for several reasons. First, you want to address any questions or concerns they have about you up front. For example, there might be some lingering questions about how much you contributed to some project a few years back, and talking about it openly with your references gives you a chance to clear up any confusion. Also, your reference needs to understand what you're looking for in a faculty job. Say you are applying to a mix of top-ranked research universities and a few smaller teaching schools. This can lead to confusion: What kind of job are you after? Do you want to mostly teach? Or are the teaching schools a safety net? You need to give your references a chance to ask these questions directly rather than infer the wrong thing and write a blind letter.

What's the process like for the hiring committee? Usually, the committee will meet several times, go through the applicants, rank them in various ways, and try to reach consensus on whom to invite for interviews. This can take a month or more. At first, a couple of interviews might be given out to the clear front-runner candidates that they really want to snag early (since good candidates' interview schedules fill up too). Then a few more weeks of deliberation happens while the rest of the interviews are sorted out. Keep this in mind: If you haven't heard from a school, but know they have started scheduling interviews (say, by looking at their online events calendar where it's usually pretty obvious who's giving a job talk), that may not mean that all of the interviews have been decided yet: it's usually a rolling process. Generally the first interviews start to get scheduled around February, but March and April is when things really get going.

In the next part I'll talk about how to nail the interview.

How to get a faculty job, Part 1: The application

This is going to be the first in a series of three blog posts on getting a faculty job in Computer Science. Part one is about applying for the job. Part two will be about doing interviews. And part three will be about negotiating the offer and making a decision.

I did my faculty job search back in 2002 after finishing my PhD at UC Berkeley. Back then, academic Computer Science departments were hiring like crazy and the number of job openings far outstripped the number of highly-qualified applicants. I ended up with something like a dozen interviews, and also interviewed at IBM Research (both coasts), HP Labs, and a little search engine startup called Google. (I regret not having interviewed at Microsoft Research, but at the time I was dead-set on an academic position and had a hard time seeing myself working at MSR.) I got offers at all of the industry places and several of the universities; and ended up taking a faculty job at Harvard.

The process of getting an academic job is tremendously painful and takes months of effort. Faculty job applications are usually due in December or January, interviews happen around March and April, and job offers made in April and May. Before summer break most job applicants will have their position sorted out and know where they will be heading in the fall.

The job application itself usually consists of five components: Your CV, a cover letter, a research statement, a teaching statement, and letters of recommendation. I'll go through these in detail below.

In case you're curious, I posted my original (2002) faculty job application materials online here.

These days, most departments accept the job application online, either via a web form or email. When I applied, only about half of the departments accepted email and I had to send physical copies of my application to the other places.

The first critical component of the job application is your personal web page. I am always amazed at how many faculty applicants fail to maintain an up-to-date web page with their publications, research interests, source code releases, and so forth. Never assume that hiring committees will have your "official" application materials at hand: These days it's much easier to Google someone's name and look at their projects and papers online. For that matter, always post your job application materials prominently on your web page. In case someone is reviewing a set of candidates and can't find your research statement, everything should be linked to your web page so people can find it easily.

The curriculum vitae is probably the easiest part to get right. This should be a detailed summary of your research interests, publications, talks, service work, teaching credentials, and any other factoids that might be of interest to the hiring committee. Under no circumstances should it be a one-page "resume". My 2002-era CV is here as an example. Note how it provides a one-page summary of my research interests and a detailed breakdown of my job experience. The "invited talks" section is provided to give a sense of my experience giving keynotes and lectures at various conferences and universities.

The cover letter is a point of great confusion. First off, it's not always obvious that it's needed, and even when you have a cover letter, not everyone knows what it should say. These days, the cover letter might take the form of the body of the email that you send when submitting your materials. In my experience, the cover letter is a "school specific" statement of why you are applying to this school in particular. It should call specific attention to any potential collaborators at the school you are applying to.

For example, a good cover letter might say something like,

Dear Prof. Zuckerberg,

I am writing to apply for the position of Assistant Professor of Computer Science in your department. My research interests are in the area of computer systems and programming languages, and my thesis topic is "Rooter: A Methodology for the Typical Unification of Access Points and Redundancy." My thesis advisor is Prof. David Culler.

I am excited by the opportunity to teach and do research at University of East Nunavut. My research interests are highly complementary to Profs. Jobs and Ballmer in your department, and I would be particularly interested in collaborating with the Center for Computational Phrenology.

Please find attached my CV, research and teaching statements, and list of references. I look forward to hearing from you. 

You get the idea. It need not be long but it's a good way to customize your application for the specific school, while keeping the rest of your application materials generic.

The research statement is one of the hardest parts of the application to get right. It is intended to serve two purposes: To provide a narrative summary of your research contributions (and especially how they all tie together), and what areas you intend to work on in the future. It's usually about 3-4 pages long and needs to nail what your specific research "angle" is, why the area is important, what your track record is, and what your research vision is going forward. It is not a personal essay like you might have written applying to college or grad school -- If the expression "when I was a child, computers always fascinated me" appears anywhere in your research statement, you're doing it very wrong.

Nobody is going to hold you to working on the specific things you say you want to do for future research directions, but you should articulate a clear vision of what kind of direction you would take when starting a faculty job. This is important. Hiring committees are not hiring you based only on your track record -- they are hiring you based on your potential to be a (potentially) life-long colleague. They want to see that you have an independent and compelling vision for at least the first few years of your faculty job. If the best you can come up with is a couple of papers' worth of extensions to your thesis, you're in trouble. Try to think of a three-to-five year agenda that would get people excited to have you part of the faculty.

The teaching statement is like the research statement, but focuses on teaching. Most grad students have precious little teaching experience beyond a couple of semesters of TA work, so it's kind of hard to say much. Still, do your best. Keep in mind that teaching is a huge part of a faculty job and one of the most important criteria for extending an offer is whether you can teach well. If you have advised any undergraduate researchers or mentored junior grad students, include this in your teaching statement, as mentorship is important too. Finally, be clear on what kinds of courses you would be willing and able to teach. It's not always obvious based on your research background if you could take on, say, the OS or databases course -- make it explicit.

As for letters of recommendation, you usually need three or four. Resist the urge to have more than four rec letters: More is not always better, in case anyone writes anything to give the hiring committee pause. In general it is best if all of your recommendation letters are from well-known professors. Obviously one should be from your thesis advisor. A letter from a top-flight researcher in an industry lab is fine, too, but you should have no more than one of these: It's commonly held that industry folks write fluffy letters and hiring committees care more about the opinion of dyed-in-the-wool academics. One piece of advise I got when applying for faculty jobs was to have one letter from someone not at your home institution, who could comment more broadly (and objectively) on the impact of your research. I was fortunate to get a letter from the great Geoffrey Fox, whom I had met a couple of times and my advisor suggested would be a good "external" letter writer for me. It was kind of strange asking  a near-stranger for a letter like this, but he agreed and I guess it did the trick, since I got interviews pretty much everywhere I applied.

Keep in mind that the job application only gets you an interview, it does not get you the job. The interview is far, far more important than the application materials. It's also important to understand that hiring committees at top schools get many, many hundreds of applications, from all over the world, for a single faculty job opening. So, make sure your packet stands out. A strong publication record is the main thing. Strong letters are second. The research and teaching statement matter much less, so don't stress over them too much. You can't make up for a weak publication record with a brilliant research statement.

Finally, a note on where to apply for jobs. I often see students make the mistake of only applying to the top five or so universities, with the idea that they could only be happy at a place like MIT or Berkeley. This is a huge mistake. First of all, the probability that you're going to get a job at your "top" school is vanishingly small, considering the number of qualified applicants and scarcity of jobs. Second, you might find out (as I did) that schools that look great from a distance don't seem so hot when you're up close and interviewing there. This can cause you to seriously rethink your preferences for both what kind of school you want to be at, where you want to live, and where you see yourself building an academic career.

The converse is also true: You might fall in love with a place you would have never considered seriously before. For example, I knew next to nothing about Harvard before I interviewed there, and never imagined I would end up there -- until I visited, and found that I loved the place and the people. So try to keep an open mind about where you might go. There are lots of great departments out there, lots of great places to live, and many, many factors that count towards your overall happiness and ability to be successful. Apply broadly, include a few "safety schools" in your application list, and then cull the list later if you end up with too many invitations to interview. Most people don't have this problem, so don't be too picky.

Check out Part 1b: How To Get an Interview.

Startup vs. Big Company: What's "Freedom"?

I was talking with a talented young PhD student today about his career ambitions, and the conversation turned to whether it would be better to do a startup after finishing school rather than joining a big company, like Google, to get some "real world" experience first. I asked him what was so appealing about doing a startup, and he said that it would mean having tremendous freedom to choose what to work on and how you pursue problems. That is true, in a sense, but I question how much "freedom" you really have when starting a new company. Doing a startup is also highly constraining, there are real advantages to being at a larger company where you have more resources and a broader set of problems you can work on.

(Caveat emptor: Note that the last time I tried to talk someone out of doing a startup, it was Mark Zuckerberg, and we all know how that turned out -- so perhaps this post should be taken with a grain of salt.)

It seems to me that many startups these days are working on low-hanging-fruit problems: Things that a few guys in a garage can put together with EC2, Ruby on Rails, and XCode. Yes, you can build amazing products this way, but you're not necessarily doing rocket science. There are limits to what one can build with a small team and limited resources, and this means that most startups are constrained in the set of problems they can reasonably tackle.

Also, startups tend to focus on problems that one can build a standalone business around, something that can be monetized or build value in some direct way, in order to make investors happy. For example, it would be difficult to do a startup around a new programming language, since it's not clear how you sell it, although it might form a component of a larger product.

My point is that not all interesting problems are good startup fodder. This is where larger companies come in. One of the reasons I personally like working at Google is because I can work on problems at a scale that most startups would never achieve. Running jobs on terabytes of data on many thousands of cores is routine. For me, this is where the really interesting problems lie: Not in designing another sepia-tone photo filter app, but in solving fundamental problems of computer science that only emerge at the scale and complexity that I can work on here.

Being at a larger company means I am "free" to work on unsexy problems -- problems a venture capitalist wouldn't touch with a ten foot pole. Network protocol optimization, performance measurement, and infrastructure building may not be everyone's idea of fun, but I really enjoy doing this kind of core systems work that can have huge impact over the long run.

This is not to say that all problems at Google are unsexy. I just tend to gravitate towards infrastructure and networking since that's my background. And damned if I can program JavaScript.

The other side of being at a large company is that you have the freedom to fail. Money is not about to run out in a few weeks, and you don't have to make deals you wish you hadn't in order to keep the cash flowing. You can take your time to try different things, get it wrong, and make big bets that don't pan out. It's unlikely you'll lose your job for doing so, and there are always more cool problems to tackle just around the corner.

On the flip side, doing a startup while you are young and untethered might be exactly the right career move. In some ways I wish I had not sat out the dot-com boom doing a PhD, but taken a risk to join PurpleYogi or one of the other dozen or so startups (including Google) that tried to recruit me back when I was 22, unmarried, childless, and already used to living in a small apartment and eating ramen noodles for dinner. Who knows, maybe I would have learned JavaScript after all.

NCSSM and how it saved my life

I just got back from my 20th high school reunion and was reflecting on how much impact my high school had on my life and my career. You see, I was lucky enough to go to the North Carolina School of Science and Math, also known as NCSSM, or as we lovingly called it back then, "S&M". NCSSM is a public high school in Durham -- not far from Duke -- for juniors and seniors. Around 680 students live on campus, in dorms -- a lot like college, but with curfews, and students aren't allowed to have cars. To get in, you take the SAT and some other tests in 10th grade, and if you're accepted, it's completely free of charge -- no tuition, no housing fees, even the food is paid for. (The food was not, by the way, one of the highlights of the place.)

NCSSM is an utterly amazing place. Everyone I know who has been there has had their lives deeply touched by the experience. Although it has a well-deserved reputation as a school for, well, nerds, it is also full of some of the most interesting and creative people I have ever met. Twenty years later, it is amazing to see what my classmates are doing today: Doing high-end CGI for Hollywood movies; numerous professors and research scientists in areas as diverse as political science, planetology, integrated science and technology, and sociology; working for the Department of Health and Human Services while doing regular club and radio DJ gigs; even serving as an Episcopalian minister. Many of my classmates are not doing "science" or "math" in the conventional sense.

Prior to NCSSM, I lived in a small town called Wilson, about an hour east of Raleigh. (If you're from North Carolina, the correct pronunciation is "WILT-sun".) It would be understatement to say that I did not fit in in Wilson, which is surrounded by a rural tobacco-growing community. There were not a lot of people there like me, and my horizons were severely limited. The main pastime of high-school kids in Wilson those days was driving in circles around the mall parking lot. There were a few great teachers in the schools, but I really needed more than Wilson had to offer.

Coming to NCSSM I found a community of people like me -- a school full of outcasts, geeks, free spirits, lost souls. Not everyone was socially maladjusted, of course, but there were plenty of people there all pushing the boundaries of their humble (often rural and low-middle income) backgrounds. The faculty at NCSSM were (and still are) stellar. I could take Russian, quantum physics, photography, t'ai chi. It was like opening a vista on vast opportunities that I had scant awareness of when I was in Wilson, and I mean it seriously when I say that NCSSM saved my life: there's no way I'd be where I am today without that experience.

For one thing, my exposure to computing was greatly expanded at NCSSM. Along with some other students, I ran the school's VAX minicomputer which powered the school's "intranet" (although it was really a bunch of VT-100 terminals scattered around campus, tied to the single computer). The students and faculty all had primitive email and chat accounts on the VAX -- this was the days before the Internet was widespread. We also had an IBM RT, a high end (at the time) UNIX workstation with 3D (!!) graphics support. A few of us managed to get this machine on the Internet, over a slow ISDN connection, so we could use FTP and email, and the IBM RT was my first UNIX "root" account. At one point, I dusted off an old, unused Data General mainframe sitting in the corner, figured out how to boot it from tape, and set up a series of terminals in the adjacent computer lab, giving any student who asked for it an account, with the provisio that they have no password -- a tribute to RMS' similar practice at the MIT AI Lab. I got to do an internship at nearby Data General, and a volunteer from NC State taught a C programming class after hours. It was incredible.

Outside of conventional academics, NCSSM has tremendous resources for exploring music and the arts. It has the most unbelievable art studio, where we would spend countless hours: in the darkroom, screen printing, making stained glass, paintings, sculptures, ceramics. My major creative outlet there was the electronic music studio. Back then it was a somewhat modest affair: A couple of synthesizers, a drum machine, 8-track reel-to-reel, effects units, MIDI sequencer -- more than enough for me to produce and record two full-length albums (and no, I will not be posting MP3s). I spent hours in that studio every weekend, all thanks to the dear late Ray Church, the music teacher who let me and others run roughshod over "his" gear. The best aspect of this was that the studios were open all the time, and the students were trusted, and encouraged, to make it their own space and use the resources to explore their own projects.

It's important to keep in mind that NCSSM is a public school. It's paid for by the taxpayers of North Carolina, and can only exist because of a state legislature, and state university system, that recognizes the importance of having a high school like this. I can't imagine what my life would be like had I not had the opportunity to go there, and I know a lot of my classmates agree.

In Defense of the Scientific Paper

http://www.flickr.com/photos/openeye/5428831/

Since leaving academia, I still find the time to serve on scientific program committees (recently NSDI, MobiSys, and SOCC) and have plenty of opportunity to read both good and bad scientific papers in various states of preparation. And although I am not required to publish papers in my current job, I certainly hope to do so -- a lot of the work we are doing at Google is imminently publishable -- it's just a matter of finding the time to sit down and write them!

Although I've blogged about how the scientific publication process needs fixing, I still feel that the process of writing a scientific paper is a hugely rewarding experience. Arguably, the primary value of scientific papers isn't in reading them, but writing them. You learn so much in the process.

Writing a paper sharpens your mental focus like nothing else. Like Japanese bonsai art or building a ship in a bottle, paper writing forces you to obsess over every meticulous detail -- word choice, overall tone, readability of graphs -- and of course more mundane details like font size and line spacing. This microscopic attention to every aspect of your work brings out a wonderful, if somewhat exhausting, intellectual rapture. I have never thought so clearly about a piece of research than when I'm in the throes of putting together a paper against a deadline.

You start with nothing, a blank editor window and some LaTeX boilerplate, some half-baked ideas, a few axes to grind and a tremendous apprehension at how much your life is going to suck between now and the deadline. You throw in all of the raw ingredients, the rough ideas, the broken implementation, the confusing data, the missing citations. Over a period of days or weeks you grind it and refine it and throw it out and start over and eventually hone the paper to a razor-sharp, articulate, polished fourteen pages of scientific beauty, and then just hope like hell that you didn't screw up the margins or forget to cite some important piece of related work.

I used to think that writing a paper was something you did after the research was over, but now I realize you should sit down to write the paper as early as possible -- sometimes before even starting the "research work" itself. On a few occasions, it wasn't until I started writing a paper that I knew what the hell the research project was really about. Case in point: Our SenSys 2009 paper on the Mercury wearable sensor platform came out of a project that had been running for nearly two years without a clear set of goals or any real insight into what the interesting research problems were. We had built a prototype and had some stuff working, but we didn't know what was publishable about it, and most of the problems we had to solve seemed mundane.


In a last-ditch measure to revive the project, I got the students together and said, fuck it, let's write a SenSys paper on this. As we started piecing together the story that we wanted to tell in the paper, we realized that none of our work to that point tackled the most important problem: how to ensure that the sensors produced good, and useful, data when there was a hard limit on battery lifetime. With the deadline just weeks away, the students pulled together and reimplemented the system from scratch and cranked out a ton of new measurements. The process of writing the paper resulted in a flood of new ideas, many of which bled over into my other projects, ultimately resulting in a half dozen papers and three PhD theses. It was awesome.


And even if a paper does not get accepted, crystallizing the ideas through the process of putting together the submission can be really energizing. I never assumed any paper I wrote would actually get accepted, so submitting the paper was often the start of a new line of work, riding on that clarity of thought that would emerge post-deadline (and a much-needed break of course).

Google's Hybrid Approach to Research

This month's Communications of the ACM features an article on Google's Hybrid Approach to Research by Alfred Spector, Peter Norvig, and Slav Petrov. Since this is a topic I've blogged about here before, I thought I'd provide a quick pointer to the article:

http://cacm.acm.org/magazines/2012/7/151226-googles-hybrid-approach-to-research/fulltext

Overall I think the article does a nice job of summarizing Google's approach. The key takeaway is that Google doesn't separate its research and engineering activities: most "research" at Google happens during the day-to-day work of building products.

The benefit of this model is that it's easy to have real world impact, and the pace of innovation is fairly rapid, meaning research results get translated into products quickly. The possible downside is that you don't always get a chance to fork off  long-term (multi-year) projects that will take a long time to translate into a product. However, there are exceptions to this rule -- things like Google Glass, for example -- and plenty of things I can't talk about publicly. It is true that Google tends not to do "pure academic" research just for the purpose of publishing papers. We could have a healthy debate about whether this is good or bad, but I'll leave that for the comments...

Startup University

The academic research process is incredibly inefficient when it comes to producing real products that shape the world. It can take decades for a good research idea to turn into a product - and of course most research never reaches this phase. However, I don't think it has to be that way: We could greatly accelerate the research-to-product pipeline if we could fix the academic value system and funding model.

Here's the problem: Some of the smartest people in the world have spent their entire careers building throwaway prototypes. I sure never built anything real until I moved to Google, after nearly ten years of college and grad school, and seven years as a faculty member. And by "real," I don't just mean a prototype that we developed for a couple of years and then threw away as soon as the papers got published. In effect, I "wasted" millions of dollars in funding, and countless man-years of development effort by my students and lab staff -- apart from a bunch of papers, nothing of practical value came out of my entire academic research career. (Maybe I'm being a little hard on myself, but let's take this as a given for sake of argument.) And I don't think my lack of real-world impact is at all unusual in a university setting.

What would the world be like if all of this hard work had actually translated into real, shipping products that people could use? How could we change the structure of academic research to close the gap between playing in the sandbox and making things real?

The plight of the academic is that there is often no direct way to translate ideas into reality -- you don't have the resources to do it at the university, and the academic process forces you to bounce between ideas every few years, rather than sticking it out to turn something into a product. In theory, academics are supposed to be patenting their ideas, and companies are supposed to come along and license the patents and turn them into real products. However, I am not aware of a single project from a computer science department that ever been commercialized through this route. This approach is more commonplace in fields like biotech, but in computer science it is rarely done.

A far more common (and successful) approach is for academics to spin out their own startups. However, this involves a high degree of risk (potentially career-ending for pre-tenure faculty), and many universities do not structure their sabbatical and leave policies to make this easy to do. Most universities also make starting a company painfully difficult when it comes to questions of IP ownership, licensing, and forcing the academic's research to be dissociated with their commercial activities. As a result, you get a bunch of super smart academics who play it safe and stay within their tenured faculty jobs, subsisting on grants and rarely commercializing their work. This means that a lot of great ideas never get beyond the prototype phase.

What I'd like to see is a university with a startup incubator attached to it, taking all of the best ideas and turning them into companies, with a large chunk of the money from successful companies feeding back into the university to fund the next round of great ideas. This could be a perpetual motion machine to drive research. Some universities have experimented with an incubator model, but I'm not aware of any cases where this resulted in a string of successful startups that funded the next round of research projects at that university.

Typically, when a startup spins off, the university gets a tiny slice of the pie, and the venture capitalists -- who fill the much-needed funding gap -- reap most of the benefits. But why not close the air gap between the research lab and the startup? Allow the faculty to stay involved in their offspring companies while keeping their research day job? Leverage the tremendous resources of a university to streamline the commercialization process -- e.g., use of space, equipment, IT infrastructure, etc.? Allow students to work at the startups for course credit or work-study without having to quit school? Maintain a regular staff of "serial entrepreneurs" who help get new startups off the ground? Connect the course curriculum to the fledgling startups, rather than teaching based on artificial problems? One might joke that some universities, like Stanford, effectively already operate in this way, but this is the exception rather than the rule.

It seems to me that bringing together the university model with the startup incubator would be a great benefit both for spinning out products and doing better research.