rybody.
My name is Jeff Moore and I'm a lead
recruiter here at Google.
And wanted to welcome you all to our second Google Hangout
on Air to talk about technical interviews.
And give you guys a chance to gauge a little bit here what
some Google engineers have to say about technical
interviews.
And so to start things off, I'd like to just introduce
Rachel and Eddie I'll give you guys just a quick second to
introduce yourself.
Rachel, why don't you go first.
And then we'll start jumping in to some of the content.
RACHEL: Sure.
I'm Rachel, and I'm an engineer on the Chrome team.
I work on front end features for that, And I've been at
Google for about 3 and 1/2 years, I think, now.
And doing interviews almost as long.
Anything else?
JEFF MOORE: That's great.
EDDIE: Well, my name is Eddie.
I am an engineer on the Google Platforms team.
Specifically, I do data center software development.
Mostly a lot of back end work, dealing with our data center
infrastructures.
And in a strange coincidence, that Rachel and I were
actually in the same interview training, and she was the
sample interviewee and I was the sample interviewer.
So it just kind of magically worked out this way.
JEFF MOORE: And you both got hired.
Amazing.
Cool.
What I was hoping we could talk about is, back in the
fall we did a blog series.
And one of the things we talked about was preparing for
a technical interview.
And there were a few things that I really harped on.
Harped on is probably not the right description, but I
really focused on having candidates do their homework.
Going back through, brushing up on what they've done.
Looking out, finding sample questions on things that they
might hear.
Really making sure they know what's coming, and be as
prepared as they possibly can.
And then also--
looks like we lost Rachel.
I'm sure we can get her back--
basically go back and brush up on your algorithms.
And your core CS, stuff like that.
And one of the examples I put out there, Eddie, is the MIT
OpenCourseWare.
Which basically allows people take free courses from MIT.
And I'm not saying you need to go take a free course at MIT,
but give you the option to go back and take that basic
algorithms course, to brush up.
And then the one that I laugh at the most, is to basically
know your resume.
Don't put on your resume that you're an expert in Java, and
doing X, Y, and Z, and walk into this technical interview
and have someone go, hey, Java.
Well talk to me about this and that.
And find yourself starting your interview on your heels
from the get go.
And so, those were my quick things.
I joke around on the blog, rinse and repeat until you get
desired results.
But would love to hear just a quick few thoughts on what you
look for, and how you would prepare
for a technical interview.
And I'll re-invite Rachel while you're talking.
EDDIE: Just a little background on my interview
experience.
I've interviewed approximately 120 candidates at this point.
And I've had a lot of experience dealing with
university students.
I've done recruiting at Purdue University, University of
Texas, Carnegie Mellon.
So I've seen a lot of these student candidates.
A typical interview with me, and pretty much any other
Google engineer, is going to be very different from what
you probably read about in, let's say, the New York Times,
or the Wall Street Journal.
That they always pose these trivia questions about, you
drop an egg off a building, and how high
can you drop it from.
Or how do you get out of a blender, or whatever.
And the thing is, that we haven't been asking those
since I've been here.
And in fact, the hiring committee knows that we
shouldn't be asking those.
Even if you got asked one, it's not even
the end of the world.
They're just going to disregard the question.
But a typical interview with me is going to cover three
facets, coding, algorithms, and system design.
And the thing is, is that I expect to be
good at all of them.
You Don't have to be a superstar at all of them, but
I expect you to be able to do each of these areas.
I don't care about your language choice, but whichever
one that you do choose, I expect you to be
familiar with it.
That you chose this language because you're
comfortable with it.
So if you say you're going to do it in Java, then it should
be proper Java syntax.
It shouldn't be Java with a little bit of Python mixed in.
Like, oh there's this other thing you can do that only
applies to plusplus, or something.
And that's a mistake actually happens a
surprising number of times.
In general though, I try to make all my coding questions
easy enough that you can solve it in C without libraries.
But you're somewhat limited on what you can ask in an
interview because of format.
You have a short period of time to meet with someone.
And you want to make sure that you know a lot about them.
You want to have conversations.
And you want to deal with the simple coding question, but
also be able to get into some more complicated algorithms.
And you can't implement complicated
algorithms in an interview.
Like trying to figure out how to do different types of graph
algorithms, for example, and you can't code
that out in the interview.
And if you can, we'd love to interview you.
I want you to succeed in an interview.
So don't think that we're out to get you when
you're doing this.
We desperately want to have talented co-workers.
And we definitely want people who are capable of conversing
freely about a lot of these issues.
So, we are on your side.
Please.
JEFF MOORE: Cool.
EDDIE: So did you want me to go more?
JEFF MOORE: I was going to ask you-- it's maybe a bit of a
tangent question, but while we wait for
Rachel I was thinking.
How do you-- and I know we've gotten some questions off the
moderator page too.
When you run into a candidate in an interview-- excuse me,
I've had too much coffee today--
and they struggle, or they get stuck.
I always counsel candidates, communicate, communicate,
communicate.
Would love just your thoughts, as it's one thing for the
recruiter to say it.
It's a very different thing for the actual engineer, who
is interviewing the person to say it.
So I'd love just your thoughts on that.
EDDIE: Well honestly, I expect some back
and forth in an interview.
That generally speaking-- actually the other notes I had
here-- is that the worst candidates, in terms of
scoring and performance, are the ones who don't talk
through the problems.
Because what will often happen, is they'll
misunderstand the question or they'll get stuck.
And then they just stare blankly at a whiteboard.
And when they do this, I can't help because I don't know
where they're at.
Oftentimes if you get stuck just say, I'm stuck.
I don't know what I'm doing.
Or, I think that if could be this.
Start with a simple solution, and then optimize up to a
better solution.
That you want to keep making some progress, and if you get
stuck, that's fine.
Quite frankly, a lot of my more complicated questions, I
don't expect you to get an optimal solution for it.
I expect to have a nice conversation about the
relative benefits and disadvantages of different
solutions to the problem.
So, it's OK to get stuck, and it's OK to just say that
you're stuck.
But just talk about what you're thinking
and why you're stuck.
It's a perfectly valid way of handling an interview.
And most candidates do this.
Even successful candidates.
JEFF MOORE: Absolutely.
I think Rachel's having some technical difficulties.
We'll keep going.
You and I can do this.
EDDIE: OK.
JEFF MOORE: One of the questions that we
get is what do the--
and this is from Jason in Singapore--
what do the interviewers really look for, when they're
conducting an interview?
And I know we talked a little bit about the high level
coding designed algorithms.
But is there the one thing that makes you go, that's
right, that's what I was looking for.
EDDIE: Well it's tough to say.
Because honestly, from my perspective, I
want a complete candidate.
There's no one thing I'm looking for.
There are often conversations you'll see on Hacker News, for
example, talking about, I'm looking for a ninja in SQL, or
I'm looking for a design guru.
At Google we want to have people who are generalists, so
I expect people to be conversant in
a variety of topics.
Now I certainly appreciate it when someone's an expert in a
given area.
It's the--
we're having all kinds of problems with Rachel
there, aren't we?
But basically, my PhD advisor , I think,
probably said it the best.
It's that a great engineer is someone who knows a little
about a lot, and a lot about a little.
That's pretty much what I'm going for.
The three areas that I do look for are coding, algorithms,
and system design.
And you need to be able to be confident in all three.
The biggest mistake that a lot of people make is, they're
very insular.
That's probably the best thing I could say.
The things that don't work well, candidates who are very
quiet, who aren't good at conveying
technical concepts clearly.
Because what will often happen is that because they can't
convey the concept clearly.
I misunderstand what it is they're going for.
And we could sometimes go off on tangents that are the wrong
way for the problem.
They can get stuck and I can't give them the [INAUDIBLE] to
get unstuck.
JEFF MOORE: We have a question from Waterloo, Canada.
From Arthur up in Waterloo.
And it's actually really funny, I support our Waterloo
office, and when I grabbed my t-shirt this morning, and I
know we are talking our t-shirt show off earlier.
If you want to go show yours off, Eddie, I know you're--
Razorback pride.
EDDIE: I'm the only Razorback in
engineering that I can find.
JEFF MOORE: I was trying to decide between a standard
Google t-shirt, and I'll just, sort of, throw mine up there.
And a Waterloo t-shirt.
So Arthur in Waterloo, I apologize for not wearing my
Waterloo t-shirt.
But your question, Arthur, is how can you tell, is there a
way to tell when you are ready for a technical
interview at Google?
Now, I have some opinions.
EDDIE: What is your opinion on this?
Because I have my opinion on it as well.
JEFF MOORE: I kind of feel like, if you've done your prep
right, and you go out, and you look at sites like Top Coder,
or different competitions, and things like Code Jam, and all
of these different things that are out there for coding and
software, competency, I guess is the word I'm looking for.
So that when you're really comfortable in that kind of an
environment, it's not going to be a one to one perfect match.
But you're going to have a gut feeling to how you're feeling
about the interview.
Hi Rachel.
We've been doing a really good job not teasing you, while
you've been having technical difficulties.
We'll make up for it by teasing you now, live.
EDDIE: The question that we're answering is, what would be a
good way to tell if you're ready for the technical
interview at Google?
Jeff just gave his response, and I have to agree
with Jeff on this.
That I feel like you're ready for a technical interview when
you feel comfortable in your knowledge of computer science
and engineering.
I think that there's a lot of timidity associated with it.
That people are afraid of the process.
Which I guess was [INAUDIBLE]
questions.
That, quite frankly, the process at Google is not that
different from other places.
That it's a fairly typical process that software
engineers go through,
throughout the entire community.
So I would be no more afraid of applying for a job here, or
more comfortable with it, than any other place.
RACHEL: I would agree with that , for the most part.
For me, it's like an exam, almost.
When you were in college, when did you feel
ready for an exam?
And there's always something more you can study.
There's always something more you can read about.
But at some point, you've got to say, all right, I'm
confident with what I know.
And go in there and give the best you've got.
JEFF MOORE: Right.
Rachel, just to chime back to when we lost
you the first time.
Sorry, I told you I would pick on you.
Is there anything that you look for in an interview, when
you're doing a technical interview with someone.
Is there stuff that jumps off the page as, this is what I
really was looking for today?
That you know you've got a great candidate in
the room with you.
It's a hard question.
RACHEL: It is a hard question.
One of the things I definitely look for--
I guess, I tend to take a lot.
In addition to looking for technical skills, I'm also
looking at how they handle the situation.
Because there are situations that we have at work, where
you're working on a problem with other people.
So one of the things that I look for is,
how relaxed are they?
Are they going in there, freaking out the entire time?
Or is this just coding up something, answering a
technical question.
Is that something that is commonplace for them, so they
are OK with it.
Another thing I'm looking for is the way they're thinking
about things.
So even if they have--
and tell me if I'm going off topic, but even if they--
JEFF MOORE: We'll steer you back, don't worry.
RACHEL: OK.
Even if they have no idea what the answer to the problem is,
I want to know where they're thinking is going.
I want to know what thought processes they're having.
So I'm looking for somebody who's going to
tell me that as well.
And I can get into that more, when we talk
about details of that.
But basically I'm looking for someone, for the way someone
thinks, and I'm looking for someone who is not going to
stress me out with their stress.
JEFF MOORE: Just to pile on to that comment, one thing that I
hear a lot from candidates and from people doing interviews
is, the interview is simulating the work
environment.
And so when you ask, the question is something to the
effect of, could you do that faster,
could you do that better.
And the candidate's like, no you couldn't do that faster.
And then the other person chimes in with-- and now I'm
going to totally expose myself as not being that technical.
But says, oh you can do that, o log, or whatever.
So whatever the complexity thing is.
You guys can both laugh at me now.
That kind of back and forth communication is really key to
the interview.
And really is a big part of a good interview.
You guys are both just nodding agreement.
RACHEL: I can verbalize that.
Yes I would agree.
EDDIE: And I think that's the same thing.
I also would agree with [INAUDIBLE].
Part of what I was talking about with my response is that
we want to talk with you.
Don't just be silent.
And part of that is because we can see what you're doing.
If you make a small mistake, but you had the process right
about how you got there, that is, in my opinion, pretty much
almost as good.
Now, other opinions vary.
That's why we have a panel of interviewers and you get a
wide range of opinions about an issue.
And we do take note of things like that.
But from my perspective, I really care more to see if
it's the right approach.
Rather than whether they remembered to, add a semicolon
there, at the end of that line, or something.
RACHEL: The approach, and the way somebody's doing it, is
even more important on a phone interview, than it is, in many
ways, than in person.
Just because that's the only thing you have to go on there.
If somebody goes silent on a phone interview for five
minutes, thinking, that tells me nothing.
I can't get anything from that, as an interviewer.
JEFF MOORE: Right, absolutely.
Cool.
We've got a bunch of questions that are
coming through the moderator.
But I just want to--
we're about the halfway point, and would just like to remind
anybody out there that's chiming in late, that you're
joining the Google Hangout on the Air, about acing the
technical interview.
And we're about halfway through, and we're going to
try and get through a bunch more questions.
The one, actually it's funny, you mentioned the phone.
We actually have a question from Marian in France, so
we're getting all international here.
Can some technical interviews happen over the phone?
If so, how would that go?
Have you guys done a lot of phone interviews?
How do they go?
I know my opinion of the phone, but.
RACHEL: I probably do more phone interviews than I do
actual interviews.
I have almost a phone interview a week, actually.
JEFF MOORE: Nice.
Do you want more?
EDDIE: Do I want more?
JEFF MOORE: I'm teasing.
RACHEL: I'm doing OK, thank you.
So yes, to answer Marian's question, phone interviews
definitely happen.
And I personally prefer the in person ones, but with the
phone interview, it's very similar.
You're going to be asked technical questions, and you
actually, very similar to when you are in person, and might
have to write something on a whiteboard, we use a Google
Doc in order to stimulate a whiteboard.
And so candidates will be asked to type something in and
that's how we see it.
EDDIE: It's a standard process at this point.
I can just give a couple of tips.
Putting us back to the phone interview
versus doing it in person.
A subtle difference between the way these things work,
because of the process involved.
Rachel mentioned, don't go silent.
It's tough to tell whether you disconnected, or whether you
don't know what's going on.
But I think that the phone screen is typically the first
interview you're going to wind up getting with Google.
Unless you're doing an on campus interview, at a
university.
And I think that they require a little bit of support from
the candidate on the other side of the phone as well.
I think that on our side, we try to be more engaging, so
that we can keep on task, and make sure things are going.
And I feel like having a reciprocation
of this from candidate.
The candidate is a little bit more verbose than they would
normally be.
That they make sure to speak more clearly, as opposed to
mumbling to themselves, that sort of thing, where you might
do it on a whiteboard.
Simply because the audio quality of the phone generally
isn't as good.
And a lot of people will put you on speakerphone on a
cellphone, which compounds the problem.
They're the same interview, basically.
I ask the same questions whether it's in person, or
over the phone.
Aside from the methods [INAUDIBLE] that much of a
difference.
JEFF MOORE: I think a lot of candidates, and a lot of
people who are listening to this conversation, probably
never had to use a Google Doc for a phone interview.
And I know that we do tons of them.
Are there any tips on that little, tiny piece?
Because I know that having those kinds of things go off
the rails in an interview could be really stressful.
And is there anything you guys can think of for that guy or
that gal, who's got a phone interview next week, to make
sure that Google Docs works.
RACHEL: I would love to jump in here.
And [INAUDIBLE]
so happy.
Run through your whole set up with a friend.
Have your friend jump one the phone, in another room even,
and be on the Google Doc, and ask you some questions.
And let you know, is your connection clear?
Can they understand the things you are saying?
Can they see what you're typing at a reasonable rate of
speed, so your internet connection is up to par?
Run through the entire scenario.
Have your friend ask you a question, or two.
So that you can see, oh wow, you were silent for five
minutes there.
Your friend can tell you that.
And you may not even notice, because if you were standing
there at a whiteboard, you would just be thinking, and it
would be clear to your interviewer
that you were thinking.
It's very different, so please run through it.
Just five minutes is all it takes, really.
JEFF MOORE: Eddie, I think you just said everything you
needed to say.
That was awesome.
Too funny.
We have another question from Arthur up at Waterloo.
Actually, we've kicked around it a little bit, but I think
it's a good question.
He asks, given limited prep time, would it make sense to
concentrate more on programming and algorithm
design skills, over CS theory and specific language, then he
put quote, quote "trivia".
And now I'm going to say, yes.
And let you guys to expand on that.
EDDIE: I think I'll start with this one first.
I have no interest in language trivia, per se.
I really don't.
If I look at it, I know that there are tons of people who
know more about the languages I use every day than I do.
But I'm able to do my job, and I'm very effective at it.
I really do care quite a bit more about your understanding
of algorithms and data structures, and ability to
actualize those in code.
Than about whether you can draw [INAUDIBLE]
on the board.
I really don't need that, personally.
Rachel?
RACHEL: I would agree.
In general, most trivia about a language, if you are working
in the real world, you could just look
that up on the internet.
So, I don't--
JEFF MOORE: You mean Google it?
RACHEL: Exactly, you could Google it.
And so I don't consider that a very useful skill, per se.
If needed, let me Google that for you.
But the algorithms are something that you are going
to use every day during your job.
And so I totally focus more on algorithms
than I do about trivia.
I don't know if ever asked a trivia question.
EDDIE: Yeah.
On top of that, if it ever comes to a point where, oh
man, I wish I knew what this library was.
Oh, I know there's this one thing that I
could use in this language.
My general response is, just assume you have it, and
describe to me how it works.
And then they go ahead, and they keep going with the
coding question.
Oftentimes, they'll be using some language and it's like,
Oh, I need to have this particular
screen parsing function.
Or I need to have this hash table representation,
something or other.
It's this hash function thing I can use.
OK, fine.
Just imagine that it exists and go.
JEFF MOORE: Cool.
OK so we've got about seven minutes left in our Hangout on
the Air time for technical interview prep.
We've actually still got tons of questions
coming, which is awesome.
I like this one, not because it's from New
Hampshire, like I am.
But I'm going to be totally shameless and say it's because
it's from New Hampshire.
And the question's from Section311,
whoever that is, welcome.
And it's, do technical interviewers often test
candidate for specific technical knowledge, or
general technical problem solving skills, or for grace
under pressure when tackling problem [INAUDIBLE]
or is it of all of these?
Rachel, you have a big smile and smirk .
RACHEL: It's quite the comprehensive question.
I think it's a little bit of all of those.
As I mentioned before, we're looking for somebody who's
comfortable answering technical questions .
We're looking for somebody who's got logical thought
process, or at least creative thought processes, that's
going be able to answer questions, to some extent.
I forget what the other ones you listed there were.
JEFF MOORE: Grace under pressure.
RACHEL: Yeah.
That, I would say, is the relaxed part.
That you're not on edge.
JEFF MOORE: I really look at that part of it as my job.
So when I'm meeting a candidate, I'm going to get
you comfortable.
I'm going to get you in a place where you're ready to
roll when Eddie and Rachel come in and start talking
about crazy algorithms.
So I'm going to ask if you'd like a drink.
If you need to take a biology break.
Whatever it is you need to get relaxed, get settled down, and
then be ready to roll.
So I really look at, part of this is my job, is to set the
emotional state.
So that you guys can always have a really good technical
conversation.
EDDIE: When I look at it, I feel like I try to target my
questions to things that pretty much any candidate
should know.
I don't try to go off on esoteric details.
If I see something on their resume that sounds
interesting, like my normal first question, in an attempt
to calm things down as well.
I'll look at the resume.
It's like, can you describe your technical contributions
to this project?
And then when they, basically--
it's interesting the types of things they talk about, but
I'm looking more about, have they calmed down.
Can they explain themselves clearly when they're
describing something that they should know, because they
worked on it.
And beyond that, they're standard, general questions.
I don't expect, I try not to cater to them.
But I have this knack, that if someone says they're a graph
[INAUDIBLE], I'll ask them a graphing algorithm question to
see if they really meant it.
They're not hard, but you have to have it.
Rachel is actually familiar with this one.
It's the one I asked her during our training.
Anyway, in general I look just for the exceptional candidates
by what they provide beyond my question.
The question itself is fairly simple, but there are
subtleties in the designs.
There are subtleties in the data structures
and algorithm choices.
And the strongest candidates, the rock stars that you hear
about, they're the ones who will go beyond what I asked
and explain why they chose this.
And that there were these three other competing
alternatives.
But that you would use case A for this type of data type,
and case B for this type of data type, and case C, if you
were dealing with a massively distributed
system that had to scale.
Something like that.
RACHEL: One caveat I would add to that is, there's a high
likelihood that you will be asked to code up something.
So if you say that you code in C or C++, but you actually
only code in Java, it's not going to go well.
So just be honest.
JEFF MOORE: No, what's funny, we had a question from Alana.
That was, what languages can I use during the interview?
And Eddie and I were talking about it earlier.
Which, you can use any language you want.
Just make sure that it's the language you've said
that you can use.
I guess that's sort of what you were saying, Rachel.
RACHEL: Basically when we are assigned interviews, we are
assigned based on what languages that
we're familiar with.
Because the way memory is handled is going to be
different in C versus Java.
And so if we're asking a question that's relating to
that, you may have somebody who's an expert in C versus
somebody whose an expert in Java.
And if you haven't been fully honest about what language you
prefer to code in, it only going to hurt you as an
interviewee, rather than affect us in any way.
JEFF MOORE: We have a bunch more questions coming through.
I'm going to try and quickly knock off a couple of them.
Because they're more HR, procedural, I think.
So I'm going to knock these ones off real quick.
And then just to wrap up our time together during this
Hangout on the Air, I thought maybe we could just get, if
you guys had one magic tip.
So why don't you guys think about that.
And I'll just knock off these couple of quick questions, and
I'll sync right back to you.
One question is, how many rounds of
interviews can one expect?
I think that it varies a little bit.
Generally speaking, when you're interviewing with a
place like Google, you meet with about five people.
It might all be in one day.
It might be broken over two days.
It really can vary a little bit.
But typically speaking, you'll talk to four or five people
through the course of an interview.
And then the other question we got from AW, in the UK.
Again keeping ourselves international, after going to
New Hampshire was how technical is an initial phone
interview for a technical internship likely to be?
And I actually think that's kind of a trick question,
because your initial phone interview is probably going to
be with the recruiter.
And it will probably not be super technical.
It will be more about where do you want to work, what kinds
of stuff do you like to do.
Laying the groundwork for that second phone interview, which
will then be someone like Rachael or Eddie that's going
to basically ask you the same question
they would as in person.
So a very technical question, the first time
you speak to an engineer.
Does that jive with you guys' experiences?
RACHEL: Yes.
JEFF MOORE: Awesome.
All right, so we've got about a minute left here, Eddie, one
tip that you would give to people for technical
interviews.
Besides wear a Razorback jersey.
EDDIE: My one tip, I think, is to be nice.
We want you to succeed.
And being polite, and friendly, and sociable goes a
long way towards that.
And quite frankly, culture is one of those things
that we look for.
And we don't like working with jerks and arrogant people.
JEFF MOORE: Rachel?
RACHEL: That's a good one.
I think my one tip--
we already touched on speaking during phone interviews, and
that sort of thing.
But I just can't reinforce that enough.
How that's the best thing you can do.
Is just explain where you're going with a problem.
And explain your thought process.
The interviewer is there to help you.
Like Eddie said, we want you to succeed.
And the only way we can do that is if we
know what you're thinking.
So just talk.
That's my tip.
Talk.
JEFF MOORE: I think that's a great.
And I really appreciate you guys being on here today.
These are kind of fun, they're still pretty new.
I'm not used to being a game show host over here.
But I want to just double down and stress that communication
point of emphasis.
And that it's really key to everything that
we've talked about.
You could be as technical as could be.
If you can't articulate it through the Google Doc, or on
the phone, all of those things.
It's just so critical to make sure you're communicating,
good, bad and ugly.
I'm stuck, help.
I know this cold, let me show you.
Communicate, communicate, communicate.
And with that, we are at one minute late.
So I would just like to thank you guys again for coming on,
and doing this chat about technical interviews.
Through our Hangout on the Air.
And next week we'll be doing more.
So anybody listening that's interested can come back next
week and catch a few more.
And I'll talk to you guys later.
Go Hogs.
