Applying to Google: Life of a PhD Googler
- Articles, Blog

Applying to Google: Life of a PhD Googler


BRENDAN COLLINS: Hi, folks. PETER NORVIG: Hey. BRENDAN COLLINS: This is a–
welcome to our second session for “Life as a PhD Googler.” My name is Brendan Collins. Hi. I’m joined by Peter
Norvig, as you can see. PETER NORVIG: Hey. BRENDAN COLLINS:
And we are going to spend today’s
session going over the ins and outs of what it’s
like to work at Google as a PhD employee. So the kind of overall
agenda for today is Peter is going to talk about
sort of the philosophy of PhD engineering here,
especially as it pertains to software engineering. We’re going to talk a
little bit about the hiring process for a couple
minutes, and then we’ll spend a lot of time
at the end to answer some of your questions. So as you can see, to
the right– over there, I think– is a chat window,
which is being moderated by a few of my colleagues. They’re happy to answer
questions as you ask them throughout the session today. And also, we will
save some of the kind of best and most relevant
questions for this group to answer at the end,
for Peter and myself, where I can help out, as well. So one quick plug. If you haven’t already,
there is an RSVP link at the bottom, sort of
right under us right here. If you haven’t filled out
that form yet, please do. That will allow us to
stay in touch with you throughout the rest of not only
this fall, but into the spring, as it pertains to internships
and jobs and answering questions about research
at Google in general. So without further ado, I’m
going to pass it over to Peter. PETER NORVIG: Great. Thanks, Brendan. OK. Let me just introduce myself. Peter Norvig. My title is Director
of Research at Google. I used to be the
director of research. Now, as the company has grown,
I’m a director of research, because we have several. But it’s a little confusing,
because we have research as an organization
within the company, but we also have research that
goes on throughout the company. I came to Google in 2001. I ran the search
team for five years, and then moved over to research. My field has been in artificial
intelligence and information retrieval and machine learning
and– done a lot of things throughout Google. Let me try to tell you a little
bit about what it’s like. So this is what we’re
going to go over. We’re going to say what it’s
like to be a PhD at Google, how Google does research,
what’s it really look like, talk about publishing, and then
talk about the hiring process. So overall, what’s it
like to be a PhD Googler? Well, the answer is
it’s totally awesome. OK, that’s it. We’re done. Goodbye. Any questions. Just kidding. I can say a little
bit more about it. So I think– there’s
a lot of things that contribute to what it’s like. I think one of the
most important things is the impact you can
have on the world. So as a PhD, you have
a lot of choices. You can go into academia,
you can go to a startup, you can go to an
established company. But at Google,
there’s– you know, we’ve got a billion customers
out there that you can help. And we have a pipeline
and sort of a setup within the company where
it’s very easy to go from PhD research into production. Another thing that’s great
is the team that we have, the people you get to work
with, and the autonomy. So Google is still a kind
of a bottom-up company, and people get to decide what
it is they want to work on. There’s a lot of
fluidity and flexibility in how you manage your
time and what you work on. Now, Google’s
approach to research. So, I wrote a paper with Alfred
[? Spector ?] and [? Slav ?] [? Petrov ?] in which we
tried to describe that. And mainly the idea
is that we want to have a close connection
between research and development and
engineering and delivery. And we want to look
for places where we’re doing
cutting-edge research, but we can apply
that into products. I think there’s four things that
make it great to be at Google, and why I said it was awesome. So, one is the amount
of data that we have. And I remember when I came
to Google, it’s in 2001, so it was a small
startup company. Some people had heard
of it, some hadn’t. And people were asking
me, well, why would you leave your established
organization that you were at for this tiny little startup,
and is that really safe, and is that a good move? And my answer for why I wanted
to come to Google, I said, well remember Willie Sutton? Willie Sutton was a bank
robber in the 1920s or so. And they once asked him,
Willie, why do you rob banks? And he said, because
that’s where the money is. And when people ask me,
why did you come to Google, I said, because that’s
where the data is. And we didn’t have the
word big data then, but I knew that’s
what I wanted to do, and I knew Google was
the place to do it. Now, on top of having
the data, you also need the infrastructure– so
that’s the hardware, the data centers, as you see
here, to process that data– and the software. I think it’s pretty important
that the software is easy enough to use that even
the PhD can do it, right? So in some companies,
you know, there’s a separation between
the production engineers that run the complicated stuff
and the PhD researchers that play on their laptop using
R or MATLAB or something with smaller data sets. At Google, some people do
that at the very beginning. But then you quickly
get to the point where you say, you know, I
could do a lot better if I used all this data that we have. And it’s easy enough to
use that I can do that. I can use the same
production systems that are used for our
production applications. I can use that as
a researcher, and I can get at a copy of
the web or all the data I need for whatever it
is I’m trying to do. And the software makes
it very easy to do that. So that’s great. And then the other thing, we
talked about impact before. There’s a billion
users out there, and so you can build
something and get the satisfaction of knowing that
you’re really helping people. And finally is the
incredible colleagues, that there’s other great
people working here, and you get to work with them. So those are the four
things that are important. That’s what it’s like. Now, what can you do? Well, here’s all
the research areas. And I won’t read through
them, but basically, you know, anything you see
in an academic CS department, we’re probably doing it. So, what does research at
Google actually look like? So, here’s a diagram
of the intersection of basic research– so striving
for fundamental understanding of the world– and
applied research, trying to build something that’s
actually going to help people. And Google research is kind
of right there in the middle. And we talk about
that in our paper. There’s another book out by
Ben Shneiderman, the professor at the University of Maryland. I forget the title
of the book, but it’s something about ABC’s,
which is applied and basic research combined. So he has a very
similar idea, that– you know, he says that
there was kind of a myth that the key to
doing good research is to fund basic research. But he said that was never
really true, that all the best research has always
been this combination of applied and basic. And that rings true to me. So I would recommend
Shneiderman’s book. And so this hybrid approach,
combining the basic and applied, we’re focused
on technology transfer. So our goal is not to prove
theorems or write papers, our goal is to
make a new product and either improve
an existing product or invent something
entirely new, and get that out in
the hands of users. We usually do that
in small steps. So we don’t say, I’ve
got a plan and I’m going to deliver something
10 years from now. We say– you can still have a
10-year plan, but you can say, along the way, this year,
here’s what I’m going to ship. And then next year, I’m
going to do the next step. And so on. We can use all
this infrastructure that we have in order
to do experiments. So we don’t have to
just think about things, we can actually try them out. And we’re allowed to
think about hard problems, but we’re evaluated by does
it actually work in the end. Now, another aspect
that’s sometimes confusing is that we have an
organization within Google whose title is Research. You look on the org chart,
and there is research. But there’s research
going everywhere throughout engineering. And a lot of the well-known
researchers that you may be aware of,
people like Jeff Dean and Sanjay [INAUDIBLE], their
title is not researcher, their title is
software engineer, because it just
happened where they sit within the organization. We go more– you know,
your title, whether you’re research or engineer,
doesn’t really depend on how academic
you are, doesn’t really depend on whether your projects
are shorter term or long-term. It depends more on the
area that you’re in. So if you’re in an
area of something we’re already doing,
like systems programming that Jeff and Sanjay were doing,
then your title is engineer. If you’re in an area
of something brand-new, then your title
might be researcher. But in the end, it doesn’t
matter what your title is. What matters is
what you work on. And we have a couple
different models for how teams work together. So here’s one example, where
an engineering team comes up with research results
and new products. An example of that
might be the MapReduce or the BigTable system that Jeff
and Sanjay and others worked on, where they’re
officially engineers, they invented something new, and
they shipped it as a product. Here’s another example, where
a research group comes up with research results and ships
the new products, as well. So examples of that might
be the machine translation and the speech
recognition systems, which started with a small
team, just a couple people in research, saying,
hey, let’s pursue this. They got some good results. But rather than handing
that off to an engineering team, because we wanted to
keep developing it, especially with examples like
that, where every month or so we were adding
a new language, we didn’t want there to be
one research system and one engineering system and have
to keep the two synchronized. We wanted there
to be one system. So we kept the whole
development within research, and we just added
engineering support to be able to ship the
product and develop the system as we went. There’s another example is a
research group might come up with a result that an
engineering team who they aren’t working directly with
then sees, picks up, and says, hey, this is
exactly what I need. So an example of that might be
the fingerprinting techniques for audio and visual that
was done by [? Michelle ?] [? Cavell ?] and
[? Shamit ?] [? Belusia. ?] So they had this
technique for saying, is this YouTube video– is this
a match for something else. And of course, if it’s a bit
for bit match, that’s easy. Anybody can do that. But what if it’s somebody
with a camcorder who sneaks into a movie and
records off the screen and it’s a noisy copy,
and in the middle there’s somebody
with a box of popcorn who walks across the screen. But that’s still– we want
to detect that as copyrighted material for whoever
owns the movie. So it’s an approximate match. They came up with techniques for
doing that approximate match, published the research results. And then the YouTube
team picked that up and said that was important. And the music team also
said we want that, too, to match against audio tracks. And those teams were able to
work from the basic research to develop the product. And finally, there are examples
where we have a research group and engineering teams coming
together to form one team and work on new products. Example of that might
be the ads optimization, where we had experts in machine
learning from the research team go and join with the
engineering team and say, we’re going to figure
out what’s the right ad to show so that users get
better, more interesting, less annoying ads to look at. OK. What about publishing at Google? So first of all, there’s a big
difference between industry and academia, in that academia,
it’s publish or perish. It’s an important
part of what you do. You get evaluated on it. If you don’t publish,
you don’t get tenure. And that’s the end of the story. At Google, you’re evaluated by
the products that you produce. So we said it was– we
had this applied focus, and we want you to
develop something. And of course, we looked at
all those different models. You can be a success in
any one of those models, so you don’t have to always
deliver the product yourself. So some of these, I came
up with a good research result that was important, and
it was used by somebody else. You still get credit for that. So there’s lots of
ways to get credit. But you’re not going to get
credit for publishing alone if those publications aren’t
interesting to anybody, don’t lead to any products. You do get credit for
publishing as an addendum to everything else that you do. So it’s something we value very
much, and we courage to do it, but it’s not the primary
thing you’re evaluated on, as it is in academia. And despite it not being
our number one focus, we still do a lot
of publication. And here’s a bunch
of different areas. And this is all on our website,
so you can go look at them. And then beyond
publishing, there’s other ways to be involved
with the community. So we’re involved with a
lot of open source projects. People here spend time on
that, work with the open source community, develop and
release these systems, maintain them,
lead the community. I had a great experience with
the Google Summer of Code, where we get some
students to help work on an open source project. And I managed a couple
of them over the summer that worked out great. We also have people working on
defining industry standards. We have our own
internal APIs for things like object
recognition API, where you say give me a
picture, and I’ll give you back labels for that picture. We collaborate with
colleagues in academia through visiting faculty,
through a research grant program through inviting
people in for tech talks, through going
through conferences. So lots of opportunities
to stay up-to-date with the academic community. OK. And now, let’s go to Brendan and
talk about the hiring process. BRENDAN COLLINS: Sure. Thanks, Peter. So, a little bit about the
sausage-making of hiring. This is the big
fall hiring season. We’re in the midst of it. So thank you to
everyone who’s watching right now, because I’m sure
that’s of interest to probably most of you. So as Peter mentioned,
you know, PhDs are embedded sort of within
every major engineering team. And so it shouldn’t
surprise you as well that we have PhD
Googlers working at most of the main engineering
offices in North America. And they’re listed here. So let’s talk
about how to apply. Drum roll please. It’s the easiest
thing in the world. Google.com/students. That is your one-stop shop
for finding information about internships. That’s where you can find
info about full-time roles. That’s where you
can find resources about how to interview. That’s where you can find more
information about scholarships. It really is kind
of the only address you need to know if you want to
talk to Google about possibly working here or getting more
involved with the company. To apply– and you
have to apply online. It’s insufficient to hand
off your resume to someone at a career fair. You do, in fact, have to go on
to the student job site here to apply. But all you need to
get the party started is just upload your resume
and an unofficial copy of your transcript,
and then click Submit. So a few of the
deadlines and things to note about the
software engineering roles for PhD students
that we have here. If you are going to be
graduating anytime between now and next May or
June with a PhD, you do not need to apply
at any particular time. There is no deadline. We hire throughout the year. And it’s not even like
there’s a rolling admission. It really is no deadline. You know, if you want to take
some time and practice doing technical interviews,
we strongly encourage that, because in
the midst of research and sort of finishing up
your dissertation, it can get lost that
you do, in fact, need to do a coding
interview, at least one, to work at Google as
a software engineer. And we’ll talk a little bit
more about the interview process in just a bit. But if you are looking for
an internship as a software engineer with us next summer,
the application is open, and it closes on
January 31 of next year. So that internship
application is, in fact– it’s kind of much more
of a rolling admission. So we encourage you
to apply as soon as you feel ready to get started
with the interview process. And once you do apply,
you’ll get an automatic email from Google recruiting
saying, hey, thanks so much, we really appreciate you
signaling your interest. If we want to move
forward, we’ll be in touch. And so if a recruiter
reaches out and says, hey, you know, thanks
so much for applying, we’d like to interview you
for a software engineering internship for PhD students
next summer, at that point you have a little bit of
flexibility to say OK, here’s my availability,
or, I have to go to this conference on this
date, so that date won’t work. The recruiting team
is really flexible. So just be as honest and
transparent with them as you can, and
they’ll treat you well. So a little bit more about
the actual interview process. It differs for
interns and full-time. More of in tactics than
in strategy, though. So for an internship, the
only interviews you’ll do are over the phone. And these are technical
coding interviews. So if you haven’t had
a lot of experience doing coding interviews, I
strongly recommend practicing. The best way to
do that is to get your hands on some mock
interview questions, such as those that you
can find in the magnum opus of tech interviewing,
called “Cracking the Coding Interview.” Volume 6 just came out– or
the sixth edition, excuse me, came out last year. The fifth edition is
still just as good. The questions are
a little older, but that’s no real difference. And doing tech interviews
is– it can be tough if you haven’t had experience,
which is why there is no shortcut to getting better. You do have to practice. After the phone interviews,
if the engineering sort of hiring committee thinks
that things look good, they will put you into the
host matching process, where your interests will
be shopped around to the different
teams at Google, throughout the company,
that are looking for folks who have experience
such as the kind that you have. So Google’s approach
to internships is incredibly curated
and manicured. We don’t just hire interns for
the sake of hiring interns. We hire interns to
do very specific work that is of great business need. And you are not just
working on some project that is going to gather dust
the second you leave the office. Every internship at Google,
every engineering intern, you work on production-level code. And so you’re right
there in the trenches with the rest of the
teams, working on the stuff that keeps the lights on here. So after that host
matching process, if they find a match
that works for you and that also– if
you work for the team, your application is put
to that hiring committee. And if they think
it all looks good, then they extend an offer. For full-time, it’s similar,
but it’s a little bit different. The first step of the process
is also one or two interviews over the phone. But it’s a little bit
more robust after that. If the committee decides to
move forward, and the recruiting team as well, they
will fly you out, most likely to our
Mountain View headquarters, where Peter and I are right now. And you will do four or
five interviews on site. It’s more than likely that
four of those interviews will be technical coding
interviews similar to the ones that you did on the phone. But there’s also a
research interview. And that is usually tailored
to your particular focus area. And the interviewer
will be someone who is also pretty
experienced in the field that you’re working in,
and the field that you’re sort of hoping to continue
working at once you join us here at Google. After those interviews
are finished up, they’re all sort of
calibrated against each other by that same sort of
committee-type approach, where if you do really well
in one interview, that’s not going to
guarantee you a job here. But on the same flip
side of that coin, if you feel like you
didn’t do very well in one of the interviews,
that’s not going to necessarily rule you out. It’s designed to be as fair
an approval as we can make it. So if the committee
decides that it looks good, that’s when we
hand out the offer. So at this point, we are going
to move on to the Q&A portion. So, my colleagues have
been diligently answering the questions in
the chat window. Thank you very
much to colleagues who are in another conference
room around the corner from us. But we have some
questions that they have collated from
the chat window that would be really good to have
answered in front of everyone watching today. So the first one, is
all research at Google focused on production, or
is any research specifically for the purpose of licensing? PETER NORVIG: We don’t really
do much in terms of licensing. I think we want to take
advantage of the scale that Google has
and say, you know, we’ve got those billion
customers out there, and we want to go
direct to them. And if you put something
behind a license, that just kind of
mutes the impact. I guess there probably are a few
cases where we do stuff to help out some of our partners. So I’m thinking things
like the phones. So you know, yesterday we
released our own phone. But we also– there’s
Android phones from lots of different
manufacturers. And sometimes, we do work to
help them out with problems that they’re having. So you might think
of that as licensing, although I don’t know if
that’s exactly what you want. But mostly, we want to
go to our customers. BRENDAN COLLINS: OK. Here’s a good question. And this comes up a
lot with recruiters, is will you focus
on the published papers of an applicant more than
their engineering skills when considering them,
especially for students who are maybe in the
first two or three years of a PhD program? PETER NORVIG: Right. So, it’s not a
competition to see who has the most publications. What we want is we
want you to demonstrate that you can do the job. And there’s lots of different
ways that you can do that. So one way to do it is to have
a strong publication record. Now, we know you can
take an assignment and you can do a good job on
it and you can write it up and you can finish it and
move on to the next thing, so you’ve proven
yourself that way. But there’s lots of other
ways you can prove yourself without doing publications. So if you’ve done an
open source project and contributed to that, or
done your own software project and finished it, even
if it’s not written up as a publication, if you’ve
shown you can do the job, then that’s great. BRENDAN COLLINS: OK. And you touched on this a
little bit during the slides, but what’s the main difference
between a software engineer and a research scientist? PETER NORVIG: So, in
terms of day-to-day, I think there’s not
that much difference. So everybody’s working
together, and you pitch in and you do what you have to do. One time I answered that in
that the main difference is not when you’re on the job, but
when you’re done with the job. So if I, as a manager, had
a talk with my employee, if that employee is
a software engineer, then we usually start out the
conversation with me saying, hey, I have an idea for
what you should do next. But if it’s a
researcher, then maybe we might start with the
researcher saying that he or she has an idea
for what she wants to do next. And then I’ll agree to that. So it’s a little
bit more flexibility in choosing your own direction
if you’re a researcher, you’ve shown that you have
the ability to do that. But once you’re on the
job, a lot of times you can’t tell the difference
of who has what title. BRENDAN COLLINS: That’s
refreshing to hear. Yeah. Titles don’t matter that
much once you’re in the door. OK, another question. Are there specific research
or applied research teams at Google focusing on
large-scale machine learning, you know, distributed
optimization, or will we be absorbed into
specific machine learning teams that already exist? PETER NORVIG: Right. So that’s a great question. So we do it kind
of at all levels. So there are tools
that we work on. TensorFlow is probably
the biggest tool. And there, a big part of that
is the distributed systems type part, and other parts is sort
of the core machine learning algorithms part. And that’s building the tools,
and it’s across the board. Then there are
teams whose main job is to do machine learning
to solve a specific problem, to do speech recognition,
image recognition, whatever. And I guess that’s the
second part of your question. And then there’s also teams
where their main focus is something else. So they’re trying to
ship a piece of software, and they’ve got 10 major
problems before they can get it out the door, and
maybe machine learning is number nine on that list. But they still need
somebody to help out and get that part done. BRENDAN COLLINS: OK. What is a recommendation
for someone in their first year
of a PhD program who may not have a
lot of publications? And this is similar from
an earlier question, but I think that first year
of being a PhD student, what are you looking for? PETER NORVIG: Yeah. So I mean, I guess that the good
thing is that for a first-year, we’re comparing you
to other first-years. So we’re not expecting you to
have a lot of publications. Again, we’re
looking for somebody who can do the job,
and so somebody who’s flexible in terms
of their ability to be able to program
up something new, to be able to read and
understand, be able to work with other people on the job,
to know how to use the tools, source control
systems, and so on. And if you can demonstrate
you can do that, then you’re well on
your way to saying you can be a valuable
member of the team, even if you don’t have a
lot of publications yet. BRENDAN COLLINS: OK. So here’s a
question– and I hear this one a lot
from students– is I’m concerned about taking
a software engineering role because I’ll just
be coding all day instead of solving big problems. How do you respond to that? PETER NORVIG: Right. So again, the titles
don’t matter, right? And everybody’s
solving big problems, but everybody has to code
in order to get there. So I think you should
look at the group you’re going to be with
and, you know, talk to them, talk to your manager, talk to
the other people on the team, and try to understand what the
project is going to be like. And don’t pay any attention to
the titles, because as I said, a lot of very well-known
people, like Jeff and Sanjay, their title is
software engineer. That didn’t bother them. But I gotta say, you know, I
wish we didn’t have these two different titles. And I’m envious of
places like Bell Labs in the old days, where
they had one title, member of technical staff. And I wish we had
that, because then I wouldn’t have to
answer this question, because it comes up a lot in
hires, and some of the hires are disappointed that they
got one title or another. Now I’m in research,
so the people I hire have the title of researcher. But when I was doing
search, the people I hired had the title of
software engineer, even though they
were doing research in how to get to right
answers for Google. So they were a core researching
everything that Google did, but every one of the
people that I hired had the title of
software engineer. And a lot of them,
fresh PhDs complained, and I said, this is
just the way we do it. And then a month later,
they’d come back to me and say, oh, I’m sorry
I complained about that. Now I understand that it makes
no difference whatsoever. BRENDAN COLLINS: Yeah. Such a– it’s a definite
first-world problem for sure. OK, this is a good question,
especially coming off of yesterday’s launch with
the new hardware devices that we have. Given that machine learning
is such an enormous focus for the company for the
short and long term, do you need to have
machine learning experience in order to work on
machine learning problems? PETER NORVIG: Right. So again, I said there’s
multiple ways in which machine learning fits in. And there’s a lot of
teams for which it’s not their main focus, but they
need to do a little bit of it. And for that, you might be
the person on the team that gets assigned that. And that’s fine. We certainly hire people that
have the mathematical skills, but not necessarily
the experience. And so a lot of the machine
learning that’s common now is really just
manipulating matrices. So if you can do linear
algebra, then you can do machine learning. And the rest you can
learn on the job. BRENDAN COLLINS: And that’s kind
of a recurring theme of hiring at Google at large, is
we don’t necessarily hire people who are pigeonholed
as being really, really strong in one area. We hire folks who are
incredibly good at learning on the job, because we know
that when we hire that way, we are making a bet on
the future of the company, and not necessarily
on that one team that needs that one person
who’s good at that one thing at any given time. PETER NORVIG: Yeah. BRENDAN COLLINS: OK. So related to that,
actually, there’s a perception that,
at Google, you might not have a
lot of choice when it comes to the project
you’re working on. How true is that? PETER NORVIG: So
when you come in, you’re usually
assigned to a project. And there may not be
that much choice there, although we are able to
do some accommodation. But then you’re very free, and
in fact encouraged, to switch over time once you get here. And we have internal
tools and marketplace where new jobs are advertised. And people look at
it and they move. And in fact, the
main problem we have is that people
don’t move enough. So we want them to go
on to the next project, and people say,
oh, yeah, I will, but first I want to finish
up what I’m doing here, and it’ll take
another quarter or so. Because we want that
experience to spread throughout the company. We want connections, both
personal and technical, to be made, and to
have that diversity. And we don’t get that when
people just stay on one thing forever. So you know, you’ll
move around a lot, and you’ll have a lot of
choice in where you go and what you want to do next. BRENDAN COLLINS: And it
shouldn’t surprise anyone on this call,
especially, that there are a lot of extremely talented
behavioral science PhDs working on Google’s HR team. And the science is
clear about the benefits of internal mobility, because
not only to your point of does the company
benefit from having new people in to stir
the pot, but also you want to have employees
happy at work. You want to have them in
charge of their own careers. And Google does a fantastic
job of facilitating that conversation
with your manager, with your HR representative. You know, there’s an
internal jobs board that, if teams are
short-handed, they can say, oh, we’re looking
for this one person. And kind of related to the idea
of a 20% project at Google. A lot of times, you know, 20%
is not, like, codified in stone, it’s pretty flexible as far
as a principle of work sharing and kind of focusing on
individual projects versus team projects. But the core idea of doing
stuff that makes you happy is baked into the DNA of
the company from its culture from day one. And that has not changed at all. In fact, in the six years
that I’ve been at Google, I personally have
switched teams four times. And I’ve gone from one
org to an entire other org in the company. And it’s one of those situations
where everyone is scratching everybody else’s back,
because the team is happier to have new people
on it who come with a breadth of experience
from another department or another division. And then the people
moving are also, they know that they are sort of
driving the bus of their work, of their careers
and their lives. And it’s really important to
Google that people are happy. PETER NORVIG: Yeah. BRENDAN COLLINS: OK. Another question– oh,
here’s a logistical question. When should we apply
for internships? Should we wait to pass
qualifications or wait until after we defend to apply? So there’s two answers for this. I can take the first one,
is internships at Google, for every part of
the company, are only open to people
who are going to be returning to school. So you have to do at least a
couple more months of school. I know for PhD, it can often
be difficult to plan out when exactly your graduation
day is, but you can– you know, if you do want to have
an internship here, you have to go back
to school for at least a preordained amount of time. And your recruiter can– if
you have questions about that, and you apply and you’re
moving through the process, the recruiters can
answer those questions on a case-by-case basis. But the window for
applying for internships is only open until
January 31, so you have to apply at some point
between now and then if you do want to get an internship
here next summer. I mentioned it is kind
of a rolling admission, so the sooner you apply,
the better position you put yourself in to
be sort of– you know, have your application on the
top of the pile once, in theory, a really good fit
for you comes online, and the recruiting
managers can say, oh, hey, this great
internship kind of just– you fit the mold perfectly. Good thing you applied
early and you’re through the interview
process and we can start that host match. So the sooner you apply, I
think, the better position you put yourself in for sure. OK. So– this was a cool question. What drives research
projects at Google. What is kind of
the starting spark, like what is the kernel
of ideation that– how does that happen? PETER NORVIG: So sometimes, it’s
improving the existing product that we have, saying, you
know, we have search results, we want better ones, we
have speech recognition, we want that to be better,
and let’s look at the current state-of-the-art and
say, what can we do? And sometimes, it’s something
entirely new, where we say, we think there’s
a new technology that we’re not doing yet that
could be really transformative. And one way to think about it
is that a good research project is something that you should be
able to go to a product manager and, in 30 seconds, say, here’s
a technology that I have, do you want that, and to have
the product manager be really excited. So things like
machine translation. If you could say, well,
I have the ability to have people understand stuff
that’s not in their language. Would that be useful? And the product manager
[INAUDIBLE], that’s fantastic, I want that. And so we look for those
types of opportunities, where we can apply the
skills that we have. We look at the current
state-of-the-art throughout the world, as well as internal
to the company, and we say, where can we make a difference. BRENDAN COLLINS: Yeah. And I think it was on
display in a wonderful way yesterday with the big
product launch that we had. And I was talking to
one of your colleagues yesterday who said
that it’s amazing, how Google went from
starting Android phones, you know, 2008, 2009,
to today, where– the amount of patience that the
company had for that great idea of how do we design and build
the best phone that we can, it took Google a long time
to get from then to now. And if the company was
driven by short-term returns on investment, we never
would have gotten as far as we have on that front. OK. Here’s another cool question. Does research at Google need to
go through a sanitation process before it can be published? If so, how difficult is this. PETER NORVIG: Right. So we do have a review
process for every publication. And we’re looking for a
couple different things. So one is don’t
say anything that’s so bad it will embarrass Google. I know that anything
you’d want to publish wouldn’t have that
problem, so that’s fine. Another is, you know, are
there copyright type issues. Did you steal some
photograph that you don’t have the proper rights? So we have to clear all that up. And then the third is, is
there anything proprietary that you’re talking about that
you shouldn’t be talking about? And that sometimes comes up. It’s usually pretty minimal. And it comes up
in a couple ways. Sometimes, we can talk
about a technology without saying
exactly how we do it. And I remember sometimes we
would talk about short text segments, right. So we’re talking about
English language, and we’re talking about
a couple word segments, and here’s some interesting
result that we advanced the state-of-the-art
on those segments. But we didn’t quite say are
those short words, number of words, is that a search
query that we’re dealing with, or is that, you know, the
underlined part of a hypertext link, or where did
that come from. For strategic
reasons, we might not want to reveal
something like that. And you know, we
might not want to say exactly how many computers
we have in our data center. So we would just take
that number out and say it in terms of percentages,
or say, you know, we had this much data,
and this is twice as much. So for the reader of the
paper, nothing has changed. For you as the author, you
still get the paper out there. It still has all
the important ideas. It can still be reproduced
by your academic colleagues. But it doesn’t give
Google’s competitors a leg up in certain
cases for things that we don’t want
to share quite yet. BRENDAN COLLINS: OK. I think we have time for
one or two more questions. Here’s a good one. How can having PhD experience
benefit both Google and me in doing a job or an internship? So let’s say a PhD and
an undergraduate both have strong linear
algebra experience, maybe applying for a machine
learning position of some kind. What is the difference between
having that PhD experience versus either that undergrad
experience or that kind of self-taught– PETER NORVIG: Yeah. BRENDAN COLLINS: –curriculum? PETER NORVIG: So I
guess what we see in PhD is the ability to take
a project over the long run, right. So as an undergraduate,
you’re kind of going one course at a
time, and the biggest thing you work on is the final
project for a class. As a PhD, you’ve
shown you could stick with a problem over
a number of years. And that’s a great attribute,
because we have hard problems, and we want people
that can work on them. And so having a PhD or
being well on your way towards getting a PhD
is a great way for you to demonstrate that
you can do that. And I guess about a quarter
of engineering staff is PhDs. So we like PhDs. We like what they can do. And we hire them. On the other hand, if you can
do that without getting a PhD, then that’s fine, too. If– what we’re looking
for is that capability, not necessarily the piece of paper. BRENDAN COLLINS: Right. OK, and one last
question is, is there a difference in the application
for either jobs or internships to do the different kinds
of software engineering? So for instance, front-end
versus back, infrastructure versus whatever, right. I can answer this one, actually. It comes up a lot. And it’s interesting. There’s– for software
engineering at Google, there’s usually that one
application for either a full-time or an internship
that is the one door into the whole company. So when you apply for
a software engineer PhD as a full-time position, that
is the one job application that you need to fill out. What will happen then is
the recruiters will look at your qualifications,
they’ll look at your background, your focus
area, your research area. And then as you go through
the interview process– as I mentioned,
you’ll have to go through those technical
interviews– that’s when they’ll start to say, OK,
let’s really start to focus and sharpen your marketing
within the company, as far as which team you’re
going to be placed on. Same kind of thing
goes for internships. If you apply for that one
internship application on the student job site,
that’s your one key that you need to
the whole kingdom. Similarly, you’ll do the
technical interviews. And then in the host
matching, that’s where they market you
around and shop you around and say, OK, this team
works great for that person. So it just kind of– that’s
where the matches are made. I think that’s it. So Peter, I want to
thank you once again. PETER NORVIG:
Thank you, Brendan. BRENDAN COLLINS:
This was lovely. PETER NORVIG: Thank
you, audience. BRENDAN COLLINS:
So, one final plea. If you joined us late and
haven’t RSVP’ed, please do sign in. The link is right underneath
us in the information section for this video. So, good luck this fall. Our next session
will be on machine learning research
and development in our ads organization. And that’s going to
be on November 9 or 10 at 12:00 PM Pacific or 3:00
PM Pacific, respectively. And just like
yesterday and today, they’re going to
be run identically. So you don’t have to go to both. You can pick whichever one
works best for your schedules. So if you RSVP’ed in
that form– again, shameless plug for that
little link down there– we’ll send you the link to the–
we’ll send you the YouTube link for those events a day or two
before they happen so that you’re caught up
and ready to go. But with that, thank you again
all very much for watching. And hope to see you on campus
or in the hallways here soon. PETER NORVIG: Thanks. So long. BRENDAN COLLINS: Phew. OK. PETER NORVIG: OK.

About Ralph Robinson

Read All Posts By Ralph Robinson

Leave a Reply

Your email address will not be published. Required fields are marked *