Really the big focus
of this interview is
going to be technical skills.
Most interviewers are going to
run a few warm-up questions,
one main question that's going
to take the bulk of the time,
so you can imagine a 30- to
35-minute interactive question.
The questions themselves
aren't going to have the answer
 presented to you directly.
You really have to understand
what the question is asking
and have an understanding of different
data structures and algorithms to be like,
OK, I can mix and match this together
a little bit to make this happen,
and then you can build on top of anything
you have to do inside the actual interview.
From my experience,
all the interviewers from
Google are extremely nice,
so they are very
supportive and helpful.
Even though the first solution you
come up with might not be the best,
they will guide you through and give you enough hints,
so eventually you can get the best solution.
You definitely need to think out loud.
First, ask clarification questions.
Second, call out assumptions.
Third, you need to explain your thoughts
clearly before jumping into coding.
It's like: What are your edge cases?
Define those first. Is anything going to be null?
What kind of inputs are you getting?
So you can make sure that,
you know, your system won't break halfway through.
Definitely speak out loud so that your interviewer
knows kind of where your mind is on certain things,
and that's when they can give you
hints every now and again,
like, "Oh, maybe don't use a HashSet;
a HashMap might be a little better."
I think a lot people come into
it with the misconception that
for every problem you're given, you must
find the algorithmically optimal solution,
but it's better to find some solution than
none at all. That's really easy to mess up.
The biggest piece of advice on how to do
well at a software engineering interview is
to not try to do well at the interview, but how do you
do well as a software engineer in general, right?
And that comes with practice,
and it comes with knowing your code.
So you really have to do what you have to do to make
sure that when you do get on site, you crush it.
I'd recommend the Google Tech
Dev Guide to make sure that
your fundamentals are going
to be strong for the interview.
Make sure that you're really
good at at least one language,
because you're only going to get to
pick one when you do the interview.
Prepare yourself.
Get used to coding on a whiteboard.
The difference between coding on
a whiteboard and coding in an editor
is that you don't have any helpful tools
to guide you through to finish the syntax.
So it's easy to just practice writing
some code on a piece of paper
where you don't have that type of tool.
I think there's a misconception
that you need to be, like,
you know, the best engineer ever to work at Google.
You know, you don't need to be an expert at
algorithms; you just need to be good at them.
You don't need to know some really
high-level complex data structures;
you just need to know all the basic ones really well.
You kind of think of Google as this, like,
super software-engineer-producing entity,
but then you realize it's people that have also
been through your same process, right?
They practiced, they worked, they
developed to be who they were today.
Of course Google likes to hire smart people, but
don't underestimate yourself — you can do it.
