JEFF MOORE: Hi everybody.
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.
