How to Work at Google: Internship & Interview Insights, Software Engineering

How to Work at Google: Internship & Interview Insights, Software Engineering


NOELLE TARDIEU: Hi, everyone. Thanks for tuning in for our
YouTube live session today. I’m Noelle. I’m on our recruiting team
for our software engineering internship. And today, I’m joined by
two of our awesome engineers who are here to run through
some interview tips and tricks and also run through a few mock
interview questions with you guys during this session. So as a first step, as you
can see on your screen now, if you’re able to go to this
link to mark your attendance, we’d love to know that
you’ve joined us here today. And throughout this session,
myself and my teammate Andy will be answering your
questions in the chat box. So feel free to use this to
be as interactive as possible. We’ll be answering
as best as we can, and then any
technical questions, we’ll turn it over
to the experts when we get a chance
in the program. So that is all I
have for us today. I’m excited to turn it
over to our engineers for them to get
started with you guys. EDGAR DUENEZ-GUZMAN: Thank you. TSION BEHAILU: Hello, everybody. My name is Tsion. I’m very excited to
be here with you. So I am a software
engineer here at Google. I’ve been here about a year. I work on the Android
partner engineering team. I love it. And I hope I can
be useful today. EDGAR DUENEZ-GUZMAN:
And hi, everyone. My name is Edgar. I’m a software engineer
here at Google. I’m from Mexico, and I went
to the University of Tennessee for my graduate studies
before joining Google. I was trying to be a scientist. And I currently work in
search infrastructure in index selection
for web and images. TSION BEHAILU: So the
technical interview– what can you expect? Most technical interviews
consist of the first couple of minutes, which are a
short introduction, where the engineer will ask you a
little bit about yourself. But a majority of
the time is going to be spent doing a technical
assessment in whatever language you prefer– that’s C, Java,
Python– after which there’s hopefully a little
bit of time at the end that they’ll leave so that you
can ask any other questions that you have. EDGAR DUENEZ-GUZMAN: Yeah. And what the engineer
is going to be looking for when you are
in your question is basically assessing
your technical skills, figuring out how well you code,
how well you know your data structures, your algorithms. And the most important
thing that we’re going to be looking
for is for assessing your analytical skills and
your problem-solving skills. Those are definitely the
most important things. We try to hire generalists,
and as such, we don’t care so much into
the solution itself. We care about good
design principles. We care about how you are
thinking through the problems. And Tsion is going to go
into a little bit more detail with that. TSION BEHAILU: Yeah. So what is the actual
interview like? Well what we really want to
know is how do you think? That’s what the engineer’s
there to assess. Do you have the right
problem-solving skills? So that means we want
you to think out loud. Just try to always be
talking, expressing all the thoughts that
are coming into your mind during the interview. And ask as many
questions as you can to make sure you have a full
understanding of the question before diving in. So sometimes, the questions
will be a little bit in depth. But that’s really
just because we want to know how you handle
complicated problems. So finding the right
solution is nice. But it’s really not
the point of it. It’s mostly just to
make sure that we can evaluate how you think
and how you solve problems. EDGAR DUENEZ-GUZMAN: Yeah. And so I’m going to
be sort of walking you through the timeline of how
you should be approaching, roughly, a coding question. So the first thing that an
interviewer is going to do is going to propose a
question for you to solve. And the question can
be very ambiguous. And your first job is
to clarify everything that that question is. So you need to make
sure that you understand what inputs you have, make sure
that you have the right data structures, the right data
types, that you understand what all of the requirements are,
and if you have any assumptions, stating them out loud. This sort of clarification
part is definitely the most important. Make sure that you keep
a good communication with your interviewer
throughout. Ask a lot of questions
and listen to the answers. Sometimes there’s hints
hidden in the answers that the interviewer
is giving you. After that, basically,
you can start sort of defining what you’re
going to be doing, what kind of data structures
you might be using, and what kind of approach. And from there, you kind
of go into the actual proposing a solution. You start saying, OK. So the first thing
that comes to mind is to solve it using this
or another type of solution. And it’s OK to start with
the simplest solution and discuss it. But then again, it’s
important to state everything because your interviewer
might change the requirements of the question as you
are proposing solutions to make it more interesting or
to explore a different area. And so this refinement
process in which you’re proposing alternatives
leads, ultimately, to your interviewer
and yourself sort of agreeing that
you both know what you’re going to be solving, and
then it goes into the coding. And we’re going to
see this in the mock. TSION BEHAILU: So what we’re
going to try to do next is demonstrate the technical
assessment of the interview, where Edgar will be playing
the role of my interviewer, and I will be the interviewee. And we’ll try to break it
up throughout the question to clarify what ideal
candidates should be doing. EDGAR DUENEZ-GUZMAN: Right. So the question that
I want you to solve is given a collection
of numbers, determine whether there
are two distinct elements in that collection that have
a sum equal to a target value. TSION BEHAILU: OK. So I just want to make sure
I understand the question. So is it OK if I
make some notes? EDGAR DUENEZ-GUZMAN: Please. TSION BEHAILU: Write
down inputs on this? So from my understanding,
I’m given some input. Can I make the
assumption that it’s going to be an integer array? Or how am I being given this? EDGAR DUENEZ-GUZMAN: Sure. Yeah, for now you can assume
that it’s an integer array. That’s OK. TSION BEHAILU: OK. So I’m given some int array. And you say that it has to
sum equal to a target value. So probably also some int n. EDGAR DUENEZ
GUZMAN: Sounds good. TSION BEHAILU: OK. And then you want me to
return True if in my array I find some pair
which sums to n. Is that what we’re looking for? EDGAR DUENEZ-GUZMAN: Yeah. That sounds good for now. We can later figure out
if we want to determine the actual pair or something. Yeah. TSION BEHAILU: OK. Let’s see. Can I pass a couple of
my assumptions by you? EDGAR DUENEZ-GUZMAN: Mhm. TSION BEHAILU: So will
n always be positive? EDGAR DUENEZ-GUZMAN:
Not necessarily. Yeah, it can be arbitrary. TSION BEHAILU: OK. So n can be any integer. OK. And then am I always
guaranteed to have a fixed length of an array? Or do I have to
account for streaming? EDGAR DUENEZ-GUZMAN: I see. Yeah, that’s an
interesting question. Let’s get it so that
you have a fixed array. TSION BEHAILU: OK. So it’s a fixed array. OK. All right. I think I have an
idea of the question. But just to make sure, let
me write a few examples. So I think the question
already has some. So if I was given input equals–
your example is 2, 4, 5, 9, and 1. I should be outputting True. And n equals seven, I should
output True because 2 and 5 sum to 7. EDGAR DUENEZ-GUZMAN:
That’s correct, yes. TSION BEHAILU: OK. I think I have a good idea. I’m ready to start
discussing some approaches. EDGAR DUENEZ-GUZMAN: OK. So let’s break character here. So you can see that
she did very well in stating her assumptions. In particular, sort of
asking whether the input was bounded completely versus
whether it was a streaming. It’s kind of very important. At Google, obviously,
we do things at scale. So very likely the
follow-up question could always be what happens
if the input is too big? Also, figuring out
whether it was integers and what the return
type was– I mean, the question was very
purposefully under-specified. So whether we want the pair,
whether we want a Boolean or not, those are important. And sort of the edge cases of
what happens with negatives and all of that is very good. Do you want to add
anything to this? TSION BEHAILU: No. I think this is the
way that I’d normally go and try to break
down a problem in a technical
interview, even when I don’t know how to solve
it at that point in time. It really helps me
to start by restating the question in a way that
could be written into a method. So that means I’m given
some input arguments, and I have to output something. So at the very least, I
know what should be given. And then stating
some assumptions, because there could always
be some tricks given. So before assuming
anything, I want to pass that by the
interviewer, make sure they know how I’m
thinking and what cases I’m considering before even
writing out some approaches. NOELLE TARDIEU: And then we have
a question from the audience. Tupperlicious asks, is better
readable code more important than performance-oriented code? EDGAR DUENEZ-GUZMAN:
Both are important. TSION BEHAILU: Yeah. EDGAR DUENEZ-GUZMAN:
Very readable code is definitely a big plus. In terms of optimality,
we don’t care about the absolute
optimal question. But again, discuss it
with your interviewer. If you are having a solution and
the interviewer is asking you for a better solution,
then it’s probably going to be a hint
that there’s something that you could be doing better. TSION BEHAILU: And
if you do believe that one of your approaches that
you’re going to implementing is sub-optimal, express
that to your interviewer and let them know
that hey, I understand that the runtime on this
might not be the best. But I can’t really figure
out how to improve it. So is it OK just
implement it so that we can assess my coding abilities? So by expressing that you’ve
thought through that, that that helps the interviewer
know that these are things you’re considering before
implementing the solution. EDGAR DUENEZ-GUZMAN: Absolutely. So if we’re ready,
let’s start discussing some of the solutions. TSION BEHAILU: All right. I think I’m OK starting to
discuss some approaches now. I’ll just jot them down
so we can talk over them. So I’m initially
looking at this. I think I could solve
it without really considering anything else. I could probably loop
through this array, compare every single element
to every subsequent element, and see if they sum up to seven. So that would be 2 to 4,
2 to 5, 2 to 9, 2 to 1. And then eventually,
go through it and output True whenever I run
into something that equals n. EDGAR DUENEZ-GUZMAN:
Sounds good. So what would be the
complexity of that solution? TSION BEHAILU: Well, since I’m
doing of every subsequent array for every single
element in the array, it would probably be quadratic. So I’m thinking O of n squared. I think that there could
be a better solution, but I’ll write that
down for the moment. EDGAR DUENEZ-GUZMAN:
OK, sounds good. TSION BEHAILU: So appraoch
one is compare every elem to every subsequent elem. And before I start
implementing that, I kind of want to see if
there’s something a little bit more optimal in
terms of runtime. So let me see. What I really want to know
is if I have a 2 in my array, I want to see if I’m going
to run into a 5, n minus i. So how could I do that by one
or two passes to improve this? Well, I guess what
I could do is save each element into
another data structure and check each one toward
that data structure to see if that would
improve the runtime. And it couldn’t be an array
list because then the runtime wouldn’t improve. EDGAR DUENEZ-GUZMAN: Yeah, so
what kind of data structure would you be using? TSION BEHAILU: Either a hash
map, hash set– yeah, hash map would need the key value. So a hash set is probably
a better solution for this. So maybe I could save every
element into the hash set and then compare it
on the second pass. But then that would
give me false positives because I could be comparing
four and four when n equals eight, and that wouldn’t work. So I guess what I could do
is save the elements as I’m going through it,
and see if it already has n minus my current
element inside. EDGAR DUENEZ-GUZMAN:
Sounds good. TSION BEHAILU: Yeah? EDGAR DUENEZ-GUZMAN: What
would be the complexity of that solution? TSION BEHAILU: Well, I’m
only passing through it once, so it would just be
the size of the array. So O of n? EDGAR DUENEZ-GUZMAN: Mhm. TSION BEHAILU: OK. So that would be– this is O
of n squared in terms of time. And this is O of n. And my second approach
would be save elem in hash set if n minus elem
is not already in the set. Yeah, and that has a better
time complexity than this one. So I think I would probably
go with this approach over that one. EDGAR DUENEZ-GUZMAN: OK. But let’s discuss. So in this one, you write that
the running time is O of n. TSION BEHAILU: Yeah. EDGAR DUENEZ-GUZMAN: So
this is time complexity. What about the space
complexity, the memory? TSION BEHAILU: OK, so how
much space is it taking up? EDGAR DUENEZ-GUZMAN: Yes. TSION BEHAILU: Well,
this one, I’m not really initializing anything, any
additional data structures. So that’s just constant. EDGAR DUENEZ-GUZMAN: OK, sure. TSION BEHAILU: But I guess this
one doesn’t perform as well in terms of space complexity. It would be O of n because
I have to save each element, and it could be a maximum of
the full length of the array. EDGAR DUENEZ-GUZMAN:
That’s right. The worst case is that every
element has to be added. TSION BEHAILU: Yeah. EDGAR DUENEZ-GUZMAN:
That’s good. So you can see that
there’s kind of trade-off between running time and space. And I wonder if there’s
any other approach that could improve on any
of these constraints. TSION BEHAILU: Well, if
I’m trying to improve time, if that’s quadratic and that’s
linear, something in the middle would probably be logarithmic. EDGAR DUENEZ-GUZMAN:
OK, sounds good. TSION BEHAILU: So if I’m trying
to– most logarithmic solutions are some sort of
search, binary search. EDGAR DUENEZ-GUZMAN:
Mhm, sounds good. TSION BEHAILU: OK. EDGAR DUENEZ-GUZMAN:
So just to clarify, we’re saying that
hopefully there is some n log n
solution that has some sort of space complexity. TSION BEHAILU: OK. So if I’m trying
to get n log n, how do I turn this into a
binary search problem? Well, that would be if I
would be assuming that they’re sorted because I would
either be searching a left or a right side. So maybe if I sort
of them, and then I try to find n
minus current element either on the left or the right. That could work? EDGAR DUENEZ-GUZMAN: OK, yeah. So if it’s sorted, it’s n log n. And then you can find it
also in n log n at the worst. Cool. So we have actually– what
would be the memory requirement, though, of sorting? Which sorting algorithm
would you be using? TSION BEHAILU: Probably
the most efficient. Well, you could do
quick sort, merge sort. EDGAR DUENEZ-GUZMAN: Do you
know the memory requirement of quick sort or merge sort? TSION BEHAILU: I believe
it should be log n. EDGAR DUENEZ-GUZMAN: Uh-huh. TSION BEHAILU: So
because we want to be– we’ll be comparing
either side of the array. EDGAR DUENEZ-GUZMAN: Right. So they’re recursive
algorithms and the recursion itself is stack memory. So yeah, cool. So now we have three
solutions that kind of have explored the trade-off
between space and time. But for implementation,
I think we should stick with this
approach two that we have here. That’s what I would like
to see some code for. TSION BEHAILU: OK. EDGAR DUENEZ-GUZMAN:
And again, we’re going to break character here
and sort of point out– so very good, very
well-organized, talking about the first approach,
the second approach, making sure that everything
is clearly spelled out, the interviewer has a
perfectly clear idea of what would be the solution
if I were to ask her to code this or this. I have a pretty good
idea of what it would be. The discussion of
space and time– obviously, she knows
her algorithms. Obviously, she knows
her data structures. And you can see sort
of the back and forth, that the solution
itself wasn’t– I mean, the fact that she gave me a
good solution didn’t mean that the conversation ended, right? So we were actually
now discussing the trade-off of one thing and
another and data structures and algorithms and all of that. Anything that you
would like to add? TSION BEHAILU: Yeah. So I started doing this
in my technical interviews when I was interviewing
for internship. And it just helped make
sure that the interviewer or the engineer always
knew what I was thinking. So even before I
started coding, I wasn’t going to be stuck halfway
through the middle changing my mind because we’d kind
of come to a consensus that this was the implementation
that was the most optimal. So yeah, in most
scenarios, just kind of writing out one
or two approaches, discussing a little
bit of the runtime is just as important as
actually coding it out. EDGAR DUENEZ-GUZMAN: Right. And another point
that I want to make is getting the perfect optimal
solution isn’t required. In fact, there is a sorting
algorithm, heap sort, that actually has O of
one space complexity. But the fact that the
candidate didn’t know that, it’s not a big problem. We are still sort of
exploring all of this. And that’s kind of a trivia
question, in a sense, knowing the right kind
of algorithm to do it. So what I did when I was
preparing for my interviews was make myself a
cheat sheet, when I was spelling out all of the
sorting algorithms and all of the data structures that
I could fit in one page and studying them
before the interview. It’s OK. You don’t need to know
everything perfectly. It’s absolutely fine. And so I think now we’re going
to go into the coding part. Oh, no. We have questions. NOELLE TARDIEU: We have a few
questions from the audience. EDGAR DUENEZ-GUZMAN: Awesome. NOELLE TARDIEU: So when you’re
first asked the question, would you suggest that the
candidate restates the question before solving it every time? TSION BEHAILU: It’s not
necessarily restate. But probably for the
purpose of clarification, it helps to kind
of break it down into making sure you understand
what exactly is expected. Like, what is the problem? Because sometimes it comes
in a paragraph format similar to this one. And so by just
clarifying, OK, well, the general idea of what
I’m supposed to be doing is given these things, I
need to produce this result. NOELLE TARDIEU: Great. EDGAR DUENEZ-GUZMAN: Yeah. NOELLE TARDIEU: OK, thank
you, Erica, for asking that. Then we have one from Ensei. How important is perfect syntax
while coding the solution? EDGAR DUENEZ-GUZMAN: I would
like to say absolutely not important at all. Just make sure that you
don’t have 10 mistakes. So missing a semicolon, not
remembering exactly the name of a function, not closing
up parentheses– these things don’t really matter. Again, it’s the
approach of problem solving that is most important. TSION BEHAILU: Yeah. And I’ve run into situations
where the engineer might not necessarily be the most
fluent in that language. So I’ve primarily done
most of mine in Java. But they might have done only
C. So they’re not themselves very picky about, oh,
you have to make sure all your brackets
are open and closed. So it’s more of a
general idea of you kind of know how to implement
it rather than making sure your semicolons and your
I’s are dotted and everything. NOELLE TARDIEU: Great. And then we’ve got
one from Kevin. So if you’re working
through your thoughts and you notice that you actually
made a mistake and went back and fixed it, would that count
against you in the interview? EDGAR DUENEZ-GUZMAN:
That would count for you. If you catch a mistake,
and you go back and fix it, that’s fantastic. That’s great because
that means that you will be doing those things
when you are in the job. You’re going to be looking
at yourself, second-guessing whether you’re right or not. The worst thing
that could happen is a person who believes
they’re right, and they’re not. So actually going back
and checking your work and backtracking,
it’s very important. In fact, I did that in
one of my interviews. I was halfway through it,
and the interviewer sort of was not telling me much. And I said, you know what? Could I just restart this? I don’t think I have
the right solution. And the interviewer said, yeah. It’s not very elegant, is it? Yeah. And it worked, right? I was hired. I’m here. And so I think it
actually counted for me. TSION BEHAILU: And
that’s kind of one of the points of expressing your
thought process is that they get to see you evaluating
your own solution and catching your mistakes. And what we’re
going to demonstrate during the implementation stage
is testing it out and talking it through before I go and
tell the engineer, I’m done. This is it. This is going to work great. It’s more I’m going to try to
be critical of my own solution, make sure I catch as
many edge cases as possible before turning
it over for their eyes. NOELLE TARDIEU: Great. And then just one more
before we get back into the notes section. From Annabella– do you
suggest the candidate gives more than one approach if
you only have one approach? Or does that count
against you in any way? TSION BEHAILU: I don’t think you
need to have– sometimes there has been situations where
I’ve only ever had one. And I will tell the
interviewer, the engineer, OK, this is kind of what
I’m thinking right now. And I don’t really see another,
more optimal way to do it. And discussing the
trade-offs for this. And if they’re like, OK. This kind of works fine for me. You can proceed. That’s why communication
is so key because you want to make it clear
to the engineer, I thought through everything,
and this is the approach that I think that I want
to continue implementing. NOELLE TARDIEU: Great. OK. EDGAR DUENEZ-GUZMAN: Perfect. TSION BEHAILU: Great. So I’m gonna work on
my implementation now. So I think what I’m
going to doing is write a method that does all of this. And we can just
name it [INAUDIBLE]. So this question is
really just a method that returns a Boolean,
if I understand correctly. And I’ll just name it
sumInPair– or PairWouldSum. And as we discussed, it
takes in an int array. And it takes in
another integer, n. And I’ll be returning
a Boolean if I ever run into a pair inside
of my own that sums to n. And the approach I’m
going to be going with is I’m going to save
each element as I’m looping through it
into my hash set, and then return True If
I do run into an element already in there that’s n
minus the current element. So let’s write that down. I guess I will just start off
by initializing my hash set. So I’ll just call it–
of integers– elems. And I’ll just get the idea. And then I’m going to–
I know I have to loop through every element in here. So I’ll just have some for
loop that kind of gives me a reference to the
current element. I’ll just name
that cur in array. And then what I want to do
is if elems, my has set, already contains n minus
cur, that means I’ve already run into this, a pair. I’m going to just return True. Else I’m going to save
my current element into my hash set. So let me kind of make
sure I have this right. Oh, I guess after I finish
I’ll have to return False because that means I’ve
ran through all my elements and I didn’t run into any pairs. So let me walk through–
let me make sure this is going to work for our example. So I think we had an
input of 2, 4, 5, 9, 1. So when I go in and moving
through my right here I have nothing in
my house that Yeah I check that a half second
seems to I mean picky things and it’s me I don’t
see I see there could be five it’s not so
I put you inside of there and then I do this
although it’s like it’s a fly I see if my have
six 7 minus 5, which is 2. It does, so I return
True, and then I’m done. because– can I assume that I
can return at the first one? Do I just need to
look for one pair? EDGAR DUENEZ-GUZMAN:
Yeah, that’s OK. TSION BEHAILU: OK. So in that case,
this works fine. And then this should also
work for empty arrays because it will return False. Yeah. And it should work
for all integers. EDGAR DUENEZ-GUZMAN:
Sounds good. What other test
cases would you use? TSION BEHAILU:
Yeah, I definitely would test with empty array. I would test with
0, n equals 0, just to make sure it works there. And then I would– let’s
see where it could mess up. Duplicates. I would make sure if I have
multiple of these numbers– so if I had 4 and 4 and n
equals 8– that it works then. Yeah. I think those would be
some of the test cases that come to mind initially. EDGAR DUENEZ-GUZMAN: OK. And finally, we’re
breaking character again. So again, you can see
she was explaining while she was coding. She was telling me every single
thing that she was doing. And she didn’t need to
finish up every single thing, like saying integer again. I mean, we know the syntax. It can be verbose. It’s OK to sort of say, OK. That’s understood,
what’s going to be there. The fact that she started
with the if and then put, that is one very important part
because if you flip this if, then you get a bug in which
you can be putting something in and then checking
if you have it. For instance, in the
other case, the 8 would have caught that
bug with n equals 8. The 4, if you put it
first, and then you check, then that would give
you a false positive. Very well structured,
very tight code. Again, usually the
problems that we’re going to be asking, if you need
more than a few lines of code, more than, like, 20,
maybe think about whether there’s a better way
of approaching the solution. We don’t try to
ask questions that require a huge amount of code. So that’s very good. Yeah. I think this is obviously a
very, very good quality code. TSION BEHAILU: Yeah,
so at least for me, I do like to talk while
I’m solving it out because keeping
that communication with your engineer
is really key. And when you do go
off track, then they can catch it very early
before you’re 15 lines in. 15 lines deep into your
solution, you can’t turn back. So yeah. And then at the end,
it really helps. That’s why initially,
you want to have a couple examples of making sure that I
know how it should be behaving. I know that when I’m
given this sort of integer that it should
return True or False. And so after you’re done, make
sure to just go back and walk through it a couple times. I know that at this point, this
is what my hash set looks like. I know that halfway through,
this is what it should return. So just walking
through it– make sure you catch your edge cases
before the engineer does. It’s not the most crucial
thing, but it really helps us know that you care
about catching everything that could go wrong
with your solution. EDGAR DUENEZ-GUZMAN: That’s
absolutely right, yes. NOELLE TARDIEU: OK. So we’re going to break
for a few questions. So from Lynn– is it OK to
use built-in library functions in the solution? EDGAR DUENEZ-GUZMAN: Absolutely. Please. TSION BEHAILU: Yeah,
I think it’s OK, but depending on the
interviewer and the role you’re interviewing for. Maybe if you’re going to be
for a much lower-level role, they might ask you, OK, pretend
you didn’t have this library. How would you do it? Or can you describe
a little bit of how it’s actually implemented a
little bit under the hood? But that’s more if you’re
not doing for a general role. So for general roles, if
you know your language and you know that there’s
a function that does this, you can say, hey, can
I use this function? And they’ll let you know
if they’re OK with it. EDGAR DUENEZ-GUZMAN: Yes. Two comments on the part. If you use something, make
sure that you understand how it works or at
least its complexity or something in rough sense. And the reusing of
other components is very important in
software engineering, right? You’re going to
be part of a team. You’re going to be
working with other people. You can’t reinvent
the wheel every time. So it’s very, very important
to reuse pieces, yes. NOELLE TARDIEU: Great. OK, and then from Ensei–
should our solution always account for a null value? TSION BEHAILU: I mean, you
can go very wrong with Null. So it’s good to just, in the
very beginning, when you’re doing those clarifying
questions, probably really good one to have
asked was, can I assume that I’m always given
an array and not a null value? So that’s actually a really good
clarifying question or a test case to account for. And by just saying that, you’re
interviewer will let you know, OK, don’t worry about
that, or yes, that’s actually a really good point. Thanks for pointing that out. EDGAR DUENEZ-GUZMAN:
Yeah, many, many times, you asking the question prompts
the interviewer to say, yeah, don’t worry about it. But the fact that
you asked– it only took you, like, five seconds. But it was good enough to give
a signal to the interviewer. NOELLE TARDIEU: Great. And then from Carlos
and Annabella– would it be wise to propose
a design of your code or flow your program
before starting to write the actual code
in front of the engineer? TSION BEHAILU: Yeah,
I think that works. I’ve done that a few times when
I haven’t been completely set on an implementation, where I’ve
just walked through, OK, loop through all of this,
and just in words so that all they have
left to evaluate you on is your coding abilities. So it might just depend
on how much time you have or how unclear you still are
with your implementation. But that works, too. NOELLE TARDIEU: Great. And then from Davina– if you
do a phone and Google Docs interview, would you suggest
emphasizing normal programming and not giving too much
time to coding by hand? EDGAR DUENEZ-GUZMAN:
Coding on a Google Doc, it’s almost like coding
by hand on a whiteboard. You don’t get any of the nice
autocompletions or anything like that. And again, we’re not asking to
write very sophisticated code with special libraries
or special things. So it’s probably a good idea
to still practice doing that. Again, we’re going for
the problem-solving skills rather than for the
purity of the code. NOELLE TARDIEU: Got it. And that being
said, from Renee, is this on par with the
difficulty of questions in these types of interviews? Or does it just vary
based on the interviewer? TSION BEHAILU: That’s
a really good question. I have gotten this
problem a few times– actually, more than once
from different companies. And depending on how long
your interview is, usually within a one-hour
time period, you can get something like this
as a warm-up question followed by a subsequent question
if there’s time. So I would say that this
is comparable to the level of difficulty that
you can expect from about a warm-up question. And if there’s time, depending
on how long it takes to solve, they might want to ask
a follow-up question. EDGAR DUENEZ-GUZMAN:
Yeah, and also, you can make the discussion
very open-ended. For instance, here,
we were discussing algorithms and
trade-offs between memory and running time. And we didn’t even
touch the possibility of having a stream
instead of an array. What happens if you have a
trillion elements that you need to be checking for? What happens if they
don’t fit in a hash set? I mean, a question that
is deceptively simple can still be extended
with follow-up questions into something that there’s
basically no right answer. Right? So you could definitely do that. So I personally like starting
with very simple questions that build up into a
research problem. But some people
do this other part of having a simple warm-up, and
then a more meatier second part question. It varies by interviewer. NOELLE TARDIEU: Great. And then one more
before we move on. This one’s from Chinadun. How do you approach
getting stuck on a question and not having a
breakthrough moment or alternative solutions? TSION BEHAILU: So getting
stumped, that does happen. So I think this is
why communicating with your engineer
or the interviewer really helps because
it’s supposed to flow like a conversation. So if you’re stuck, you want
to be expressing exactly what’s going through your mind. Why are you stuck? You can’t figure out how
to make it more efficient? You can’t really understand
what it’s supposed to output? So there’s a reason that
you’re not able to move on. And when the engineer knows
exactly what point you’re kind of hitting a
wall, they’re there to also give you a
little bit of a hint to move you along so that they
can much better evaluate you. EDGAR DUENEZ-GUZMAN:
What she said. NOELLE TARDIEU: Great. So we’ll pause there, and we’ll
ask a few more at the end. TSION BEHAILU: OK. EDGAR DUENEZ-GUZMAN:
Sounds good. So we’re going to show you
a second practice problem, and we’re going to discuss it. We’re not going to go
through the whole interview. But we’ll show you this. And so basically,
the idea is that you could be asked this one. So implement a set-like data
structure with three methods– insert an element, remove
an element by value, and return an element
chosen uniformly at random. And again, this question
has multiple solutions, some of which are
simple and some of which are more complicated. So if you want to
sort of start– TSION BEHAILU:
Yeah, so similarly to how we approached the first
question in the mock interview, I would probably start off by
doing a couple of clarifying questions, like, all right. So you just want me to
create a data structure. And I need to support probably
insert, remove, and return. Or that’s probably
kind of like a get. And then it seems like the
trick is that it’s at random. So maybe if I was dropping
things into a bag, it has to perform some
sort of way like that. EDGAR DUENEZ-GUZMAN: Right. So yeah, this data
structure basically behaves like a bag in
which you drop marbles, and you can sort
of pull them out. TSION BEHAILU: OK. EDGAR DUENEZ-GUZMAN: So that
kind of insight is important. And so the underlying
data structure, let’s discuss a
couple of alternatives of which underlying data
structure we could use. TSION BEHAILU: OK. So it seems like instead of
these marbles, what we’re actually inserting is integers. So in the example, it looks
like 1, 3, 7, 2, and 9. And we just want to have our get
function of this structure kind of just pick one at random. So I probably have to store
these things somewhere so I’m thinking
my data structure, along with having
the three methods, would probably need to store
these values somewhere. So I could do a list. I could do a set. EDGAR DUENEZ-GUZMAN: And
both of those solutions have some– like a hash
set versus an array list have a constant complexity
for two of the methods and linear time
for the third one. So if you have remove with
an array list implemented in a trivial way, then
it’s a linear solution. If you have a get
random from a hash set, then it’s also, again, linear
because you need to iterate. But there’s better
solutions, perhaps? TSION BEHAILU: Well, so the
trick seems to be that my get, which need to return
something at random, the way I have to do
that is I probably just want to choose
a random index. So a list might be
better than a set because then I can choose
a random index in my data structure. So I think what I
would probably do is inside of my data structure,
I would initialize some array list. My insert would be adding to
the end of the array list. My remove would be removing
an element in the array list. And then my get would be
getting a random integer from the length of the array,
and then removing that. EDGAR DUENEZ-GUZMAN:
That’s right. So the optimal solution in terms
of running time for the three is a combination of the hash
set with the array list. And you don’t actually have to
do that in an interview, again. Discussing the
trade-offs and everything is part of the solution. Basically, the idea
is having a hash map of the values where their
index is within an array list so that the remove can
be by index very easily. And you still have all of the
benefits of having the array list for the get random and
for the insertion in very fast time. But anyway, again,
it can be extended. There’s also a
logarithmic solution for the three operations
that can actually support even a fourth
operation for a follow-up. But again, this
discussion, this kind of approach of going through
things is the right way. Let’s see. How are we doing for time? NOELLE TARDIEU: We
have another question. EDGAR DUENEZ-GUZMAN:
We have questions. Perfect. NOELLE TARDIEU: So how many
questions would typically be asked in a
single phone screen, and would an interviewer ever be
concerned that the candidate is not coding quickly enough? TSION BEHAILU: So I think it
varies because it’s definitely candidate to candidate
and however the engineer likes to prep for it. So we do like to prepare–
most engineers like to prepare quite
a few questions, just in case we have a candidate
that goes through all of them very fast. But sometimes, one question
can take up the whole interview just from discussing
a lot of trade-offs or if the candidate took a
little bit more time writing their implementation out. But it’s definitely not the
deciding factor whether or not you’ll move forward. It’s just going to be, like,
it just took more time. So you can expect
that the engineer will have questions
prepped for you all the way till the end of time. But it’s OK to just take a
little bit longer and not go through all of them. EDGAR DUENEZ-GUZMAN: Yeah. One and two interview
questions is typical, I would say, especially for
a phone screen or an on-site. That’s kind of what
we were discussing– a warmup and a more
sophisticated question later, or just one that keeps
getting extended. That’s typical. In terms of the
speed, I would say don’t worry too much about it
if you are expressing yourself very clearly and
you’re expressing what your thought process. Of course, there is a
limited amount of time. The only problem with having
a slow coding candidate is that we get less time to
evaluate what the skills are. And I would say that’s– TSION BEHAILU: Our
goal is to figure out how you’re thinking,
how you’re approaching. And so there’s not really
a time limit on that. It’s more of if we
can’t really get that much out of
a candidate, then we don’t know how well they’ll
perform in various settings. EDGAR DUENEZ-GUZMAN: Yes. NOELLE TARDIEU: Great. OK, we have a few more. From Rachel– would
most interviewers hint at the optimal
solution or data structure or just want the candidate
to run with their instinct? TSION BEHAILU: I don’t think
they would sabotage you. EDGAR DUENEZ-GUZMAN:
No, I would say that it varies from interviewer
to interviewer, definitely. But most interviewers
want to give you hints because they’re very
excited about the question. They ask the question
because they like it, right? And if you’re almost
there, they will give you a hint of saying, oh, but
what if things were sorted? Or something, just sort of
to get the ball rolling. Again, that doesn’t
mean that you need to have the best solution. But be very, very careful. Listen very carefully to
what the interviewer is saying because sometimes
there are hints where you don’t expect them. I remember one
person was asking me, so how do you feel
about destructors? And I’m like,
well, they’re nice. And then after the
interview, I was like, oh! Of course! That’s what they meant. Argh. It’s OK. TSION BEHAILU: Yeah. NOELLE TARDIEU: Great. And then from Raghavan–
what do you expect in a dynamic
programming question, for the candidate to
solve it or go through it? EDGAR DUENEZ-GUZMAN: Goodness. I would say dynamic
programming is not a solution that you are expected
to come up with on the spot. If you can, well, all
the better for you. That’s great. But I don’t think
we ask questions with a specific
solution in mind. TSION BEHAILU: An ideal
question that an engineer gives is multiple ways of solving it. And it shouldn’t have a
gotcha factor where you’ve run into it at one
point in your life, and you know that there’s a
really trick solution to it. That’s not a very good question. And so if that is a
question you’ve gotten, it’s not a very well
thought through one. A question should
be able to– you should be able to
talk through it and come up with some
way of solving it. So a lot of engineers
prefer not to give those if they do seem like,
oh, it’s gotcha. I know the exact algorithm that
you have to do to solve this. NOELLE TARDIEU: OK. Then we have a last question
from Truth before we move on. Anything you recommend
the candidates do not do? So common mistakes, things
to avoid, et cetera? EDGAR DUENEZ-GUZMAN: Don’t
be absolutely silent. That’s a definite no-no. We cannot evaluate you if
you’re completely stuck or if you’re thinking about
the absolute best solution. There’s just nothing we
can assess in that case. Don’t be rude to
your interviewer. Definitely don’t do that. TSION BEHAILU: I think for me,
I run into a lot of candidates just starting a solution– don’t
preemptively just start coding. Because you’ll catch
a lot of these things that could go wrong if you
had just asked a few more questions in the beginning. And really stressed– I could
tell that sometimes they might have not really fully
understood the question or if they had just asked one or
two more questions to make sure that they knew what
they were doing, maybe discuss their approach
in a little bit more detail before coding that
they could have avoided starting a solution
and going to the end and using up a lot of time. EDGAR DUENEZ-GUZMAN:
Don’t assume a magical function that solves
the problem automatically. So if you’re going
to say, oh, there is a library that does this,
make sure that you understand what’s going on there. Usually, assuming that
something magically will just solve things for you
will not help you much. TSION BEHAILU: Any
more questions? EDGAR DUENEZ-GUZMAN: Yeah,
well, we can go for resume tips. Yay. NOELLE TARDIEU: So Melacu asks– EDGAR DUENEZ-GUZMAN: Oh. TSION BEHAILU: More questions. EDGAR DUENEZ-GUZMAN:
Oh, more questions. That’s good. NOELLE TARDIEU:
How much expertise do I need on algorithms. TSION BEHAILU: I
would say I don’t know how to quantify it other
than about the same as a data structures algorithms course. So you’d want to know your
search algorithms, tree traversals, things like that. But if you do enough of
these practice problems, I think you’ll get
an idea of the areas that maybe you need a
little bit more practice in. But yeah, I think if
I had to quantify it, it would be about
the same as a data structures algorithms course. EDGAR DUENEZ-GUZMAN: Yeah. I mean, it depends on,
obviously, your seniority. If you’re going
for an internship, we’re not going to expect you
to be an algorithms and data structures expert. That’s OK. And even if you are
a seasoned coder, maybe data structures
is not your thing. So as long as you know, sort
of, array lists, vectors, hash maps, and
sorting algorithms– something like
divide and conquer– and a little bit, like,
binary search, tree traversal, basic trees. Beyond that, not very– TSION BEHAILU: Yeah,
but the fundamentals because most of that,
the more complex things can be derived from
the fundamentals. EDGAR DUENEZ-GUZMAN: Yeah. Definitely hash maps is
something that you should know. But if you start getting
into more sophisticated data structures, that’s
probably not needed. Perfect. TSION BEHAILU: All right. So we’re going to be talking a
little bit about resume tips. So before you get the
technical interview, you have to get the
actual interview. So what should you
have on your resume? So this is a pretty good guide
for what probably should stand out the most on your resume. And I like to think
of your resume as sort of conveying these
four kind of information very clearly. So it can be as
fancy as you want, but just make sure that
at the end of the day, it’s conveying the fundamental
information that they need. So that could be your
school, major, GPA, expected graduation date, if
you’ve had internships before or you’ve worked on
research projects. That’s also really good. EDGAR DUENEZ-GUZMAN: Right. If you have, also, technical
projects on your hobbies, like you have open-source
contributions, you have been in
hackathons or things like that, that’s
also very important. It shows initiative. It gives us some flavor
of what kind of code you’re write, as well, in a more
sort of realistic environment than an online coding
session with an interviewer. Definitely if you
have activities that you want to highlight,
involvement of clubs, groups, or associations, if they’re
technical, if they’re relevant, that’s great. Try not to pad too
much the resume. Less is more. Definitely try to keep it very
clean with a lot of whitespace, bullet points with
phrase fragments rather than actual
walls of text. We receive literally
millions of resumes per year, and we have people
looking at all of them. And so they don’t have
a lot of time to do it. So a good practice
way of doing this is if you give it to a friend
and take it away one minute after, ask them what
they got out of it. So real estate in the page. Keep it to one page. It needs to be very
clean, and if you are going to be putting
something important, put it on the left of the page. Dates and things like that,
you can just leave on the right where they’re not
obstructing anything else. So name of the
university, degree that you’re pursuing,
important projects with two bullet points. That’s kind of the thing
that we’re talking about. TSION BEHAILU: And yeah, just
last thing about the resume– if you don’t have
the work experience, and maybe this is
the first internship you have, open source
and personal projects, maybe if you were setting
up your own small website, portfolio site, and
hackathon projects, that also works comparatively well. EDGAR DUENEZ-GUZMAN: Yeah. And one thing that
I forgot to mention is that it’s OK to say
which skills you have. So C++ and Java and
some sort of other part, like developmental
drivers or something. Anything that can
be sort of bullet pointed like that is good. Don’t put 10,000 languages. If you say, oh, well, I know
Java, C++, CSS, HTML, SQL– TSION BEHAILU: Can you
defend all of them? EDGAR DUENEZ-GUZMAN:
Yeah, that’s the thing. Everything that you
put in your resume, it’s fair game for someone to
be asking you in an interview. So don’t say that you’re an
expert in C++ because then you can get an expert in C++
asking you questions. So yeah, that’s, I think,
basically the most important part. Just be factual. Don’t boast. Just state the things that are. Questions? NOELLE TARDIEU: We
just have one question. For someone who’s a
junior in college, is it OK for them to
have a resume that’s longer than one page? Or would you suggest to
keep it at that length? TSION BEHAILU: That was me. I was a junior in college,
and I had a resume that was a page and a half. And the feedback I got
from every single recruiter at career fairs was, I
really like your resume, but you have to cut
it down to a page. And so I think a really
good way to get feedback on that is when you
do go to career fairs, ask the recruiters. You’ll get a general
consensus of what they like by just asking them,
at the end of speaking to them, do you have any more
feedback for me? How could I improve this? And they’ll more than
likely– you don’t usually have enough experience by your
third year in college that can’t be cut out into a page. EDGAR DUENEZ-GUZMAN: Yeah. I feel you. It’s very, very difficult
to cut those things that you’re so attached
to out of your resume. But think about it
this way– you don’t want to dilute your skills. You don’t want to dilute
your achievements. If you put everything
that you have done, then it’s very difficult for
a person casually looking at the resume to know which
ones are the most important and which ones aren’t. So if you have a Ph.D.
or three or four years experience in industry,
two pages might be OK. If you don’t, then stick
to one page at all costs. And even if you
have two pages, make sure that whatever you
put on the second page could be skipped. So the first page should be
standing on its own, basically. NOELLE TARDIEU: OK, great. And then Critical asks, I used a
language in one school project. Should I list that on my resume? I know the basics, but
not anything advanced. TSION BEHAILU: So
the question is should they include a language
that they’ve only mildly had experience with? One way that I’ve seen
students kind of present that on their resume is
by saying, I’m fluent, I’m proficient,
or I kind of have a little bit of experience. And so they know that if
they’re getting an interviewer that they wouldn’t know all
the nuances of that language. EDGAR DUENEZ-GUZMAN: Yeah. My suggestion would be
don’t put it in the skills, but put it in a bullet
point of the projects that you worked on. NOELLE TARDIEU: I think
we’re good for now. EDGAR DUENEZ-GUZMAN: Very good. TSION BEHAILU: All right. Make sure to mark
your attendance. Thank you so much for
making it through with us. We had a really great
time, and hope we helped. EDGAR DUENEZ-GUZMAN: Yeah. Thank you very much,
and join us tomorrow at 5:00 for another session. TSION BEHAILU: Thank you. EDGAR DUENEZ-GUZMAN:
Goodbye, everyone. TSION BEHAILU: Bye. EDGAR DUENEZ-GUZMAN: Hope
you found this useful.

Leave a Reply

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