Here's my personal take on what "research" means at Google. (Don't take this as any official statement -- and I'm sure not everyone at Google would agree with this!)
 |
| They don't give us lab coats like this, though I wish they did. |
Under this model, it can be difficult to get anything you build into production. I have a lot of friends and colleagues at places like Microsoft Research and Intel Labs, and they readily admit that "technology transfer" is not always easy. Of course, it's not their job to build real systems -- it's primarily to build prototypes, write papers about those prototypes, and then move on to the next big thing. Sometimes, rarely, a research project will mature to the point where it gets picked up by the product side of the company, but this is the exception rather than the norm. It's like throwing ping pong balls at a mountain -- it takes a long time to make a dent.
But these labs aren't supposed to be writing code that gets picked up directly by products -- it's about informing the long-term strategic direction. And a lot of great things can come out of that model. I'm not knocking it -- I spent a year at Intel Research Berkeley before joining Harvard, so I have some experience with this style of industrial research.
From what I can tell, Google takes a very different approach to research. We don't have a separate "research lab." Instead, research is distributed throughout the many engineering efforts within the company. Most of the PhDs at Google (myself included) have the job title "software engineer," and there's generally no special distinction between the kinds of work done by people with PhDs versus those without. Rather than forking advanced projects off as a separate “research” activity, much of the research happens in the course of building Google’s core systems. Because of the sheer scales at which Google operates, a lot of what we do involves research even if we don't always call it that.
There is also an entity called Google Research, which is not a separate physical lab, but rather a distributed set of teams working in areas such as machine learning, information retrieval, natural language processing, algorithms, and so forth. It's my understanding that even Google Research builds and deploys real systems, like Google’s automatic language translation and voice recognition platforms.
(Update 23-Jan-2011: Someone pointed out that Google also has a "Quantitative Analyst" job role. These folks work closely with teams in engineering and research to analyze massive data sets, build models, and so forth -- a lot of this work results in research publications as well.)
I like the Google model a lot, since it keeps research and engineering tightly integrated, and keeps us honest. But there are some tradeoffs. Some of the most common questions I've fielded lately include:
Can you publish papers at Google? Sure. Google publishes hundreds of research papers a year. (Some more details here.)You can even sit on program committees, give talks, attend conferences, all that. But this is not your main job, so it's important to make sure that the research outreach isn't interfering with your ability to do get "real" work done. It's also true that Google teams are sometimes too busy to spend much time pushing out papers, even when the work is eminently publishable.
Can you do long-term crazy beard-scratching pie-in-the-sky research at Google? Maybe. Google does some crazy stuff, like developing self-driving cars. If you wanted to come to Google and start an effort to, say, reinvent the Internet, you'd have to work pretty hard to convince people that it could be done and makes sense for the company. Fortunately, in my area of systems and networking, I don't need to look that far out to find really juicy problems to work on.
Do you have to -- gulp -- maintain your code? And write unit tests? And documentation? And fix bugs? Oh yes. All of that and more. And I love it. Nothing gets me going more than adding a feature or fixing a bug in my code when I know that it will affect millions of people. Yes, there is overhead involved in building real production systems. But knowing that the systems I build will have immediate impact is a huge motivator. So, it's a tradeoff.
But doesn't it bother you that you don't have a fancy title like "distinguished scientist" and get your own office? I thought it would bug me, but I'm actually quite proud to be a lowly software engineer. I love the open desk seating, and I'm way more productive in that setting. It's also been quite humbling to work side by side with these hotshot developers who are only a couple of years out of college and know way more than I do about programming.
I will be frank that Google doesn't always do the best job reaching out to folks with PhDs or coming from an academic background. When I interviewed (both in 2002 and in 2010), I didn't get a good sense of what I could contribute at Google. The software engineering interview can be fairly brutal: I was asked questions about things I haven't seen since I was a sophomore in college. And a lot of people you talk to will tell you (incorrectly) that "Google doesn't do research." Since I've been at Google for a few months, I have a much better picture and one of my goals is to get the company to do a better job at this. I'll try to use this blog to give some of the insider view as well.
Obligatory disclaimer: This is my personal blog. The views expressed here are mine alone and not those of my employer.
I like the Google model a lot, since it keeps research and engineering tightly integrated, and keeps us honest. But there are some tradeoffs. Some of the most common questions I've fielded lately include:
Can you publish papers at Google? Sure. Google publishes hundreds of research papers a year. (Some more details here.)You can even sit on program committees, give talks, attend conferences, all that. But this is not your main job, so it's important to make sure that the research outreach isn't interfering with your ability to do get "real" work done. It's also true that Google teams are sometimes too busy to spend much time pushing out papers, even when the work is eminently publishable.
Can you do long-term crazy beard-scratching pie-in-the-sky research at Google? Maybe. Google does some crazy stuff, like developing self-driving cars. If you wanted to come to Google and start an effort to, say, reinvent the Internet, you'd have to work pretty hard to convince people that it could be done and makes sense for the company. Fortunately, in my area of systems and networking, I don't need to look that far out to find really juicy problems to work on.
Do you have to -- gulp -- maintain your code? And write unit tests? And documentation? And fix bugs? Oh yes. All of that and more. And I love it. Nothing gets me going more than adding a feature or fixing a bug in my code when I know that it will affect millions of people. Yes, there is overhead involved in building real production systems. But knowing that the systems I build will have immediate impact is a huge motivator. So, it's a tradeoff.
But doesn't it bother you that you don't have a fancy title like "distinguished scientist" and get your own office? I thought it would bug me, but I'm actually quite proud to be a lowly software engineer. I love the open desk seating, and I'm way more productive in that setting. It's also been quite humbling to work side by side with these hotshot developers who are only a couple of years out of college and know way more than I do about programming.
I will be frank that Google doesn't always do the best job reaching out to folks with PhDs or coming from an academic background. When I interviewed (both in 2002 and in 2010), I didn't get a good sense of what I could contribute at Google. The software engineering interview can be fairly brutal: I was asked questions about things I haven't seen since I was a sophomore in college. And a lot of people you talk to will tell you (incorrectly) that "Google doesn't do research." Since I've been at Google for a few months, I have a much better picture and one of my goals is to get the company to do a better job at this. I'll try to use this blog to give some of the insider view as well.
Obligatory disclaimer: This is my personal blog. The views expressed here are mine alone and not those of my employer.
Thanks for the insights into Google. Funny enough, I just read a post this morning stating that one of the main problems with Google is that it does too much "research", it is too much like a university:
ReplyDeletehttp://english.martinvarsavsky.net/fon/what-larry-page-should-do-as-new-ceo-of-google.html
I wonder if you, as an insider, have a different vision to the one of this entrepreneur.
Hi, Matt, thanks a lot for your detailed descriptions about research in Google. I still have two confusions after reading your article - I do see some people in Google have titles such as "Research Scientist" and "Senior Research Scientist" while others have titles such as "Software Engineer" and "Senior Software Engineer". If Google has decided to *not* follow the traditional corporate research lab model, why not eliminate titles such as "Research Scientist" and "Senior Research Scientist" completely? And why not simply eliminate the entity called "Google Research"? Are there any differences in terms of expected responsibilities between a "Software Engineer" and a "Research Scientist" at Google?
ReplyDeleteAnon re: "Research Scientist". Indeed, there is a "Research Scientist" job title, and it is reserved for those people in the "Google Research" arm of the company. My point is that Google Research is not like Microsoft Research (say), and you don't need to be a "research scientist" to do "research". The vast majority of PhDs at Google are "software engineers".
ReplyDelete(Honestly I think Google has this title only to make it easier to hire certain kinds of people. I wish they would get rid of it, since it causes confusion.)
I do not see why this obsession with research frankly. If you are doing something you enjoy, and it is clearly novel and exciting (as noone seems to have done it before), why does it matter whether it is called research?
ReplyDeleteAnon re: obsession with research. That's very true. A lot of people with PhDs want to do "research" and I am trying to emphasize that it is possible to do that at Google.
ReplyDeleteI don't think the goal of research at MSFT or IBM is tech transfer so much as patent filing. IBM in particular seems proud of the large number of patents it files per year, referencing it in annual reports.
ReplyDeleteI suppose that could be called tech transfer, but I doubt many patents see application in anything except lawsuits.
I'd love to see more Google research/innovation in education :) Pretty thin listings on that publications page.
ReplyDeleteHi Matt, good article. I agree with everything you said. Let me comment some on the difference between a "Research" and "Engineering" position at Google, since I've done both. You're right that those with a Researcher title are also responsible for building and maintaining large systems, just like Engineers. And while there are a lot of PhD Researchers, there are ten times more PhD Engineers. The Machine Translation and Speech recognition projects are the biggest services that are run completely in Google Research. Other Researchers join Engineering teams and help out in a variety of projects across the comp[any. And some Researchers are building prototypes of something new -- but as you point out, they are using the same code base and data sets as the rest of Google, so that makes it much easier to turn a prototype into a working system. So what's the difference between the Researcher and Engineer title? In the day-to-day job, often not much difference. Researchers may be looking out a little further into the future, and may be taking more risks. But all Googlers are mainly building systems rather than just writing papers (although both Engineers and Researchers write papers as part of their job). It is easier to see the difference between Researcher and Engineer when the day-to-day job is over -- when you're trying to decide what project to do next, and you are talking to your manager, it is a give and take, but if you're an Engineer the manager has the upper hand and if you're a Researcher you get more say yourself.
ReplyDeleteProfessionals do not need a PhD to do research. Anyone can do it! You can either waste 6 years earning PhD or join google and do research after BS - Title, money, work is going to remain same.
ReplyDeletenice, very good article, plus all the comments that you guys said, including you Peter... my job today is supporting media planning and adbuyer for an advertising agency in Puerto Rico, this means to advertise in Google Adwords, facebook and another platforms..our work. I never imagined whole the work you do to keep us on duty day after day. I was pleased reading this post.
ReplyDeleteI'll first comment (unofficially) on how things get done at IBM Research. The "build a throw-away prototype and throw it over the fence to development" model mostly went by the boards over a decade ago. Most of my successful projects of the last 15 years (Rapid Type Analysis, Thin Locks, Metronome, and several smaller ones) have been developed within production infrastructure and transferred by merging back into the CVS head of the development stream and then hardening the code for production. Doing it this way keeps your work honest and increases the chance of impact by at least an order of magnitude.
ReplyDeleteFiling patents is also important. In particular, it provides a way for the Research division to realize income from projects even if they don't get into (IBM) products. This provides an important way for us to self-fund and isolate Research from the shorter-term needs and desires of the product divisions.
In terms of Google's model, there's much to admire. As Matt says, given the scale of their work, many "engineering" projects qualify as research. And the egalitarianism promotes a meritocracy where good work rises to the top.
So for someone with a Ph.D. the question is whether it's important to you to be able to return to more traditional "research" jobs (eg in academia) after a stint at Google. If so, you need to make a more conscious effort to continue publishing and staying visible in the international research community, and willing to make some trade-offs in order to do that.
Over time, it's likely to become less true that engineering at Google will qualify as research -- their scale will become commonplace, competitors will emerge, and the infrastructure will have been built out. In the 1950's the computers and even the punch card readers that IBM designed would have qualified as "research". And back then, IBM didn't even have a research division. Over the next decades, Google is highly likely to follow a similar evolutionary path.
What I am taking from this is the almost absolute integration of business and research. Having the data & information of the business woven in the fabric of decision making can only benefit.
ReplyDeleteI didn't see it mentioned here or in comments...but would the researchers also be integrating Google's own information with information from competitors/ the rest of the world?
Many researchers I know are flipping into the Google model of impact. I can understand the attraction of "in the hands of millions of users" (especially for folks who haven't released a system that's been picked up widely) and of a better salary. But what I find disheartening about this, from a societal point of view, is the seed corn problem. Impact measured in a longer time frame than what can be delivered in a year or two. Sure, a few Googlers get to work on the self-driving car. But the rest of the PhDs are shifting away from the ability to do both the normal science and potential breakthrough science that benefits somebody other than Google's shareholders and Google's userbase in what is still basically a pretty narrow domain of web scale-out and mobile services (compared to the entire breadth of computing). And many are the field's top researchers.
ReplyDeleteIn the case of systems research, it may actually be a healthy redirection of technical talent into a productive direction (in the sense of that old Rob Pike slide deck). Incidentally, David Bacon's description of PL is IBM is (in my mind) not that different from the Google model; by living in the context of existing products, you constrain what you can tackle in your research, and the main cultural difference is just that IBM still explicitly values publications. I am a lot more worried about the folks in machine learning, HCI, security, etc. whose inventive talents are desperately needed elsewhere and who are now being hoovered up in increasing numbers. As someone else pointed out, Google isn't doing educational technology; nor is it doing smart medical technology (the flu thing doesn't count), secure voting machines, etc. etc.
IMO this fits into a larger trend, the one that still drives today's most competitive Gen-Ys into finance instead of more productive careers, even though they know quite well how societally suboptimal it is. For too many folks, doing something - even medicine, let alone research - that isn't maximally well-compensated and immediately gratifying is considered to be a sucker's game. I have depressing conversations with CS PhD students who say that if school ever stops being fun, they'll do something else rather than sticking it through. And indeed dropout rates are high. We now live in a world where the buzz of hacking on a popular website is more satisfying for PhD-level folks than thinking about what might matter to the world 10-15 years out.
@David Bacon - your name sounds familiar. Have we met somewhere? :-)
ReplyDeleteAs we've discussed in person, IBM Research goes through these cycles of looking way out to the long term horizon and working on more near-team projects. The fact that a company founded in 1911 has a vibrant and active research lab today gives me hope that Google won't just disappear overnight. Though, these punch cards you speak of are very interesting - maybe Google can index them?
@Anon re: seed corn problem: I agree that the Google model does not place emphasis on doing long-term disruptive research. When I was interviewing, I asked the question, "who at Google is worried about the problems you will face 5 or 10 years down the line?" The basic answer was that things are changing so fast that Google tends to focus on the 6-to-12 month horizon (though there are plenty of exceptions).
ReplyDeleteOne question is whether Google *should* be investing more in long-term research, or whether that is best left to universities, national labs, and places like Microsoft Research. I don't know. Arguably if you don't have a hand in shaping the long term then you won't foresee the opportunities (and risks), or get ahead of the next big competitor to Google. Somehow I doubt that having a lab full of PhDs off in the woods somewhere would have been able to do anything about Facebook :-)
If a tree falls in the forest and.... While people may be doing research at Google, is it Research if nobody else ever hears of it, learns from it, and pushes the field forward? I find the oft cited 100s of papers/year a joke given the number of people doing "Research" at Google. I wish it were otherwise and if you want to count on universities, national labs, and MS to produce the needed Research, you are going to be seriously dissapointed as US investment there continues to decline... Other countries are moving in the opposite direction..
ReplyDeleteMy research career has spanned SRI, Bell Labs, AT&T Labs, a couple of startups, Penn, and now Google. The differences have not been so much on subject matter but rather in the balance, scale, and impact of the work. A big part of my job as a research manager is to keep a balanced portfolio of projects, some shorter term, some longer, some more applied, some more theoretical, some riskier, some less so, to fit the surrounding needs and conditions. There are several significant differences between my experiences at Google and elsewhere: 1) making research successes have practical impact is much easier (but not easy by any means); 2) little bureaucracy; 3) more resources available for risky research bets; 4) power and responsibility more distributed throughout the organization.
ReplyDeleteJames - that's a good point, though I don't have any numbers on hand to say whether 200 papers or so a year is big or small given the size of the organization. I wouldn't define "research" so narrowly as only published work - countless national labs, defense labs, and private companies do research that is never published (but which has impact on the real world nonetheless). That said I am a huge proponent of wide dissemination of research results and will push for that within Google.
ReplyDeleteMy impression is that a lot of research at Google deserves that label but it involves substantial inductive practices. Quantitative measurements are valued highly. Theory may evolve from experimental observation. On the network side, I have seen some stunning data gathering (that included the development of very sophisticated measurement hardware) leading to new models of congestion control and bandwidth utilization inside Google's very large scale data centers. I think the hands-on approach to research is producing deep insights into practical matters - the self-driving car team had to solve some very hard problems and had to put some pretty sophisticated theory to work. Ditto Google Earth, Machine Learning, speech recognition and translation, etc.
ReplyDeleteIsn't the so-called "Google self driving car" a Stanford project (out of the DARPA challenge) that Google later acquired? If this is really the best example of long-term research by Google, then its ironic, since it sounds like Research_Lab:Product_Team::Stanford::Google
ReplyDeleteSo in terms of research structure, Google==Apple?
ReplyDeleteHi Matt, what do you think of the ladder (http://www.quora.com/What-are-the-different-levels-of-software-engineers-at-Google) at Google? My friends at Google told me a fresh PhD would usually be placed at Senior Engineer, but one of them who only had a Master's degree was promoted from Software Engineer III to Staff Engineer within 3 years. Do you mind sharing your title?
ReplyDeletewell it's not only scientists that do reasearch quite a few "engineers" and technicians do reasearch or we certainly did at the place I worked at first (BHRA)
ReplyDeleteMatt, David, you both mention that working with production-capable systems keeps your work "honest". What does "honesty" mean to you in this context?
ReplyDeleteWei - the "ladder" only pertains to compensation levels, not the kind of work you do, nor the distinction between research or non-research positions. In general the ladder level has nothing to do with your job title, which is just "software engineer" (on the engineering track). Because I have only been at Google for about 7 months, I do not have a level yet - the idea is that you are evaluated for your level after you have been in the job for some time. My understanding is that this is primarily the case for some of the higher levels, but I really don't know. I don't want to speak for Google's HR department!
ReplyDeleteAnon re: honesty: To me, this means that at the end of the day, your system has to work, it has to be robust and scalable, and it has to be documented and tested so others can use it. This is very different than a throwaway research prototype that doesn't need to have any of those qualities, but instead just has to work well enough to generate graphs that go up and to the right for a paper submission. It also means that we're not designing systems only for the sake of exploring an idea or demonstrating technical elegance; it's about building things that work and are useful. It is remarkable how much this grounds and focuses the work we do at Google.
ReplyDeleteAnon re: Apple: I don't know if the Apple comparison is quite right. At least in the systems field, I don't know *anyone* from Apple who is publishing papers and going to academic conferences. I'm sure the folks at Apple are just as smart (or smarter) than at Google, but they seem to have less connection with the academic research community.
ReplyDeleteRe: Apple. I'll second this. Practically everyone I know has some kind of Apple product, and the vast majority of computing people I know use Apple products for their day-to-day work. The company itself has a very high "cool" factor, and is now the most valuable tech company on the market. And yet while in grad school I never heard a fellow student express interest in working at Apple. Not even once.
ReplyDeleteWait, maybe their lack of draw as a research center has something to do with them being so profitable... hmmm...
I am a graduate and currently working at Microsoft as a software developer. And the work is pretty much coding oriented.
ReplyDeleteI used to enjoy this kind of work for the first few months but then I found this very boring (to say the least!! :P)
Thats why I was thinking of doing a PhD and getting into R&D, may be at Google.
But what you said in your blog, scared me!!
I don't see much difference between your work and mine; may be the only difference is your higher pay scale.
Seriously Matt, don't you want to move on to somewhere else where there is proper "research" and you have to spend less time in coding and much more attention in setting future directions???
Having read your blog, I also think in the interview at Google, you must have been asked questions from the undergraduate level related to algorithms, data structures, OS. Isn't it?
Abhijit - it is a valid concern. Two things:
ReplyDelete(1) Google is not the only place you can work after you get a PhD. I've tried to emphasize that Google has a particular approach to "research" that differs a lot from academia and more conventional industrial research labs, like MSR. It depends on what you enjoy doing.
(2) There's no way for me to comment on the difference between what I do at Google and you do at Microsoft. Are you working on big problems that interest you, or just making the dancing paperclip more efficient? Sounds like it's more like the latter in your case. This has nothing to do with which company you work for - it comes down to the role you play. Both Google and Microsoft have huge problems that require deep research skills and training to tackle, and having a PhD can give you the opportunity to go work on those problems. (I can't speak for Microsoft, but at least at Google you don't need a PhD to do that kind of work, but it certainly doesn't hurt.)
The advantage of a place like Google is that I can both set long term research directions AND write a lot of code (both of which I love doing). Sounds like you've never been in a situation where you are doing research that nobody cares about or ever uses - let me tell you that gets old after a while.
The Google software engineering interview does tend to focus on writing code on the whiteboard, and even more senior people have to run that gauntlet.
Speaking as an academic, for good and for bad, I stopped writing code on a daily basis a long time ago. Doing research at Google for me would be extremely interesting (and a good fit with what I do). The sad truth however is that I would never pass the tech test. And to be provocative, why should I? It seems somewhat perverse that people who are optimised for research are interviewed in much the same way as a fresh undergraduate, with similar expectations of producing production-quality code.
ReplyDeleteAnon re: "tech test" - I tend to agree with you, but there are two issues at work here: a cultural one and a technical one. From a technical perspective it should be obvious that a seasoned academic shouldn't have to remember how to implement a doubly-linked list in Java to contribute something important to Google. But from a cultural level, there aren't many roles here that don't require writing code - even "researchers" tend to build and maintain real systems. There's also a deep-seated egalitarian view that everyone should have to go through that kind of interview.
ReplyDeleteOne thing I am trying to work on here is avoiding a situation where Google passes over a really great talent because they are rusty on writing code on the whiteboard.
Thanks for the quick reply!
ReplyDeleteClearly code needs to be written --and doing so is an excellent way to really understand what is happening. What is not so clear however is whether everyone should have to go through the same process. This is not a new topic really and I have heard it mentioned elsewhere many times before.
Overall conclusion from all the comments - PhD is a waste of time.
ReplyDeleteSince a lot of comments has been posted about Google's recruitment process, I request Matt to write on this topic in his blog next.
ReplyDeleteI have heard a few things about Google's recruitment process like its way too lengthy and time consuming than other companies like MS, Yahoo! or Oracle. But the latter also hires bright and smart people within less time...
All these might be rumors.
So it will be great to hear from a google insider on this.
Anon re: "PhD is a waste of time" - I'm sorry you are getting that impression - that's not what I said. What you may be confused about is that a PhD is a waste of time *for some people*.
ReplyDeleteLook, you only *need* a PhD if you want to be a professor at a top university (and even then there are exceptions to the rule - it's my understanding that Hank Levy, chair of the CS department at UW, never got one). Most industrial research labs expect candidates to have a PhD as well.
At Google, you don't need a PhD to do "research" work, but having one helps in many ways - in particular, doing a PhD trained me how to think deeply about problems, how to be an "architect", how to read and synthesize results from scientific literature, how to teach and mentor, how to leverage a wide range of scientific and mathematical approaches in my work. I sometimes run into software engineers here without a PhD who are simply unaware of important results in the literature or a scientific methodology that would help them out in their job.
I blogged about the pros and cons of a PhD before:
http://matt-welsh.blogspot.com/2010/09/so-you-want-to-go-to-grad-school.html
Doing a PhD is not for everyone, but calling it "a waste of time" seems fairly naive.
Rajeev - I might blog about this, but I'm not an expert on Google's recruiting process. A lot has been written about it elsewhere, if you look around (using your favorite search engine, perhaps).
ReplyDeleteIt is not my impression at all that Google's process is any more lengthy than those other companies. Most companies do a phone screen, if you pass that a day of interviews, then extend an offer (or not). This was my experience interviewing at Google (both in 2002 and 2010) as well as previously at Microsoft Research, HP Labs, and IBM Research. I don't see how it can be done in any less time than this, although companies differ on the length of time between interview and offer - at Google it can take a week or two. Many students of mine have interviewed at Microsoft, Facebook, Amazon, Twitter, you name it, and all report the same process.
"Overall conclusion from all the comments - PhD is a waste of time."
ReplyDeleteSee, if you've taken the trouble to do a Ph.D., you would have more correctly interpreted all the things being said here, and you wouldn't have jumped to that conclusion :)
It's been a while since I wrote code on the whiteboard, or opened a textbook on OS, but I'm doing it during my lunchtimes at work, at home after dinner, and on the weekends. Sure it's consuming time, but hey, if I want to beat those fresh graduates, I want to beat them on the whiteboard as well, not just on paper :)
And in any case, it's not like I'm learning new stuff, it's been more like "Oh, I remember this now." Then I move on to the next chapter.
In a way, I feel that Google's interview process is more fair. But I might feel differently after I had mine :p
I think there may be a part of the Google experience that may be missing: interactions with management. I found a good resource for learning about the internals of a company: glassdoor.com. There, I saw feedback about how Google management can sometimes be stifling and obstructive, or even unfair. Of course, this will vary from manager to manager, and those who are happy and content are not likely to post feedback.
ReplyDeleteBesides impressions about management (which I don't think this blogger will respond to, at least not in the negative), I'm also interested to know why this blogger did not apply for the management position. Certainly, I'm sure he is eligible for that position. And I'm thinking being a manager will give him more resources and more freedom to do what he wants. I.e. closer to an academic researcher.
And that brings me to my last point: being in the industry in general not only causes one to lose the freedom to work on anything, it also brings one under the mercy of one's management. If the management is good, then things will be great. If the management is short-sighted, self-centered, unaware of what's happening at the ground-level, insecure, unhappy with the way you look, then you're pretty much screwed. In that sense, being in academia is a better choice.
Anon re: Management - you make some very good points. I can't comment on Google management more generally, but it's been my impression so far that management is fairly hands off - of course there is a lot of variation. Overall, Google seems like a place run by a bunch of grad students who like doing geeky things and nearly all projects are driven bottom-up by the engineers, not top-down by management. The running joke is that we lack proper "adult supervision." I'm also fortunate that my manager lets me do whatever I want - either because I'm well-established or I'm not that important is hard to tell :-)
ReplyDeleteOne of the reasons I left academia is that I want to build things, not be a manager (which is all I was doing as a professor). I could certainly be a manager here but that doesn't actually give me any more power or freedom. When I move to Seattle in March I will be heading up a new team there which will require taking on more management duties, but my plan is to hand the day to day management over to a proper "manager" once the team is built up.
You are absolutely right that you have less freedom in industry than in academia. On the other hand, being in academia still requires a great deal of overhead (teaching, committee work, travel, etc.) and of course you can only really work on things that you can successfully get funding for and publish papers on. So it's true that in academia I was more my own boss, however, at least so far at Google I've been able to carve out a role for myself that I enjoy.
o o my comments :-(
ReplyDeleteyou have deleted the TRUTH! Disappointing..
ReplyDeleteI deleted two anonymous comments that were offensive. I won't tolerate mudslinging on my blog, unless I'm the one slinging mud, of course. Don't like it? Start your own blog.
ReplyDeleteI sincerely apologize if you find those comments offensive - I am sorry about that.
ReplyDeleteI had just presented what happens in academia and why google is better research place that academic institution.
Re Peter's description above of the researcher role vs. engineer role: given that the jobs are very similar and that the difference may only be in the interaction with one's manager, how does Google decide if someone who has a research background (a new Ph.D. or a Matt Welsh) is to labelled as an engineer or a researcher?
ReplyDeleteAnd Matt, given your publication record (and the fact that you were tenured at Harvard!) it would seem that either role would have been open to you. Why did you choose one and not the other?
Anon re: researcher vs. engineer: They are different job titles and therefore you apply to different jobs. Almost everyone working in systems, networking, and related areas at Google is a "software engineer". "Research scientist" positions tend to be people in machine learning, AI, theory, etc. I never even considered a "research scientist" role mainly because it was not that appropriate given my interests. I guess I could have applied for it but likely they would have steered me towards the software engineering role instead.
ReplyDelete