Applying to Google: How to Ace the Engineering and Technical Interview

By: Google Students

MATT BENNICE: Hi, everyone. This is how to ace the technical interview. Hopefully, you've already had the chance to sign in. But if you haven't, there's a link on the screen. Write it down or take a picture and make sure you sign in.

It's a great way to stay in contact with us. Today, we're going to talk about what to expect in a Google interview, talk about the types of questions you might see, and how to prepare for success. But before we get started, I want to draw your attention to the chat feature you should see in the upper right-hand corner of your screen. We've got a few Googlers here-- Michelle, Katie, Amy, Anthony, and Jonathan-- acting as moderators today on standby to answer your questions live. And we'll also be taking a few further into the presentation. And with that, let's get started. So I'm Matt. I'm a Google software engineer.

I graduated from Rensselaer Polytechnic Institute and majored in aerospace engineering in 2006. I joined Google in 2014. My favorite things about Google are the problems we solve and the environment we get to do it in. EDGAR DUENEZ-GUZMAN: And hi. My name is Edgar.

I graduated from the University of Tennessee. Before that, I graduated from the University of Guanajuato in Mexico from math and computer science. I graduated in 2009, and I was trying to be an academic for a few years. I joined Google in 2013 as a refugee from academia. My favorite thing about Google is the culture of self-criticism and openness that we have internally.

Applying to Google: How to Ace the Engineering and Technical Interview

So what we're going to be doing is trying to give you a good peek at how the interview is done at Google and we're going to try to explain to you what the process is and how you would prepare for it. So the first thing is an overview of how the interview is going to be processed. So at the beginning, you will be given a coding sample and a survey. And this is a new thing that we're doing.

If you have interviewed at Google before, you may not have had this, but bear in mind that this will happen. Then you will have two or three phone interviews in which you will be interviewed by an engineer. And then after that, you will be going for an on-site suite of interviews, which are generally three or four.

And overall, the total number of interviews that you have, both phone and on-site, shouldn't exceed five unless it's a special circumstance. After that, you will go for a committee review, and from there, hopefully, you will be getting an offer. The internship process is a little bit different.

But it has the same overall structure. We have also the coding sample at the beginning and two or three phone screens. In particular, the main difference between internship and a full time is that you will not have an on-site interview. After your phone screens, you will be assigned to a host for matching between your skills and their needs with multiple products potentially. And you will be able to choose one.

And from there, again, it's committee review and an offer. MATT BENNICE: OK. So Google interviews are 45 minutes long approximately. In general, they can feel brusque. You usually have a very short introduction of about a minute or two, at which point your engineer will generally give you the technical question. It's not because we don't want to talk to you or we're not interested in what you have to say. But that's the most important thing hiring committee is going to look at, is the outcome of technical assessment. So we want to give you as much time as possible to get through that.

And then, in general, we'll close with answering any questions you might have. Now, there's no points for asking any question. This is strictly for you because you are interviewing us as well. So please come with any questions you actually are concerned about.

You don't need to come with a fake question to ask me because it's not going to help your case. The types of things you're not going to see. We're not going to be asking you what happens if you fall in a blender. There is no puzzle or brainteasers. The questions are going to be problems that will revolve around computer science. The engineering skills we're looking for is we want to see proficiency in the programming language you chose, that you understand how to use the core libraries it gives you, and that you can basically handle any performance issues that are coming up. We also want to see that you can use algorithms and data structures to solve the problem.

And we want you to be able to break down a problem that might not have been a computer science problem directly into a computer science problem. So you're going to see a lot of different categories of questions. And generally, we give you a lot of interviews not so that we hope you screw one of them up, but because this way we can see you answer problems in a lot of different categories. So, obviously, we're going to be expecting to see you code. The big languages at Google are Java, C++, and Python. But we also have JavaScript.

And if you're an expert in another language, feel free to let us know, and we will find somebody to interview you in that. You can occasionally see math problems, where they're going to ask you powers of 2. You also will generally see something on the algorithm side where you're going to need to sort something or build me a data structure. You should definitely know things like stacks, queues, maps, graphs, hashing, big one. Obviously, the most important thing that we are testing for during your technical interview is your grasp of algorithms and data structures, because these are like the foundation that underlies your skills as an engineer. So the types of problems you're going to see are, how would you sort, search, or represent something? The trick to these different types of interviews is you want to strictly listen carefully to the problem.

If a simple, plain solution comes to head, go ahead, talk about it. See, maybe that is actually the best way to do it. Otherwise, have a conversation with your interviewer, just like we're going to show you later. We're here to help. So we're going to try and offer hints and suggestions if we think we can help you along to the right answer. This isn't a test. You're not getting graded, like 80%, oh, you made this mistake.

We really want to see how you solve a problem and how you work well with the other engineer in the room. So while you're coding, in general, it helps to verbalize your thoughts. We understand that some people prefer to code in silence.

And if that's the case, please say so. But if you think out loud and you explain to me what you're doing, I can catch your mistake and only cost you 30 seconds. But if I have no idea what you're doing and you're just putting code up on a whiteboard, it could be three or four minutes until I realize you're off track and that can be 10% of your interview time spent right there. The other thing is your interviewer, like I said, is trying to help you. We're going to give you hints. We're going to try and bound problems for you.

We're going to try and keep you to solving a problem that you should be able to solve in 40 minutes. We're not going to give you something that requires 10,000 lines of code. So if you think that's what you need to do, chances are you need to re-evaluate your solution. EDGAR DUENEZ-GUZMAN: Yes.

And Matt has explained to you what is going to be in the interview itself. So what I want to do now is tell you how to prepare for it. And so the most important thing that you can do, as you can probably have guessed given the content of the interview, is to review the fundamentals. You need to have your algorithms and your data structures very well on the tip of your tongue whenever you have something. Definitely practice writing code, not pseudocode. Pseudocode is great to organize your ideas and to think about a problem, but ultimately, you need to present code. And you're going to have to do that in a language. And I would suggest that you do it in the language that you're most familiar with because it's much easier to read code than to write code.

Don't try to match the code that you're writing to the interviewer that posed that question. And definitely, if you have expertise in Java, C++, or Python, those are the major languages that we use at Google. But if you have a different language, it's OK. Like Matt was saying, just discuss it with your interviewer. I have interviewed people in [INAUDIBLE], in JavaScript. That's perfectly fine. And definitely also would suggest very strongly that you code in a whiteboard, on a sheet of paper, or something like that.

And if you have some friends that you can practice with, that would also help. Because it's a different thing to say that you have solved the problem to yourself and convince yourself that you have done it. And it's a different thing to convince someone else. And if you have people that work at Google or work in the industry, ask them about their experience. Work your social network. They will be very good resources for your preparation. So what is the interviewer thinking? So now you have prepared and now you are in front of a person, and you don't necessarily know what they are thinking.

So what we are mostly focused on is in figuring out what the candidate is doing with the problem that we post. And particularly, how they are analyzing it. Are they looking at all of the special cases? Are they missing some? Did they look at the way of solving it methodically and logically, in particular were they're proposing solutions and trying to go back and improve them on their own? Do they have a strong understanding of the concepts in computer science? Do they understand well their memory system? Do they understand well what trade-offs they're doing when they propose a data structure or another? Do they understand that the problem can be either solved in breaking it into smaller pieces or not? These kinds of questions are what we are trying to evaluate.

And you also need to be producing good quality code. And in particular, since you're going to be joining a software engineering company, we want you to be doing good software engineering practices. So you should be testing your code. You should be talking about maintainability, re-usability. Try to write clean code. And also, you're going to be part of a team.

So we expect you to be able to explain your ideas clearly. And the most important part, perhaps, is that we want the candidate to be a pleasant person to work with. We are evaluating whether you would be a good team work, a good person to have in our team. And so in particular for phone interviews, since you have the barrier of having all of your communication go through the phone, I would definitely suggest that you have your phone charged, that you have a very good head set available, that you have tried a couple of times either with a friend or something to test that the call quality is good. You don't want your phone to die in the middle of the interview.

It would be a good idea to have a quiet location where you can hear what the interviewer is saying. And you can speak without the interviewer having to struggle to understand what you're saying. Remember to indent your code. You're going to be coding in a Google Doc, and sometimes, it can be frustrating the way it does auto correction and things like that. You can prepare for those ahead of time. And yes, since you're going to have the extra problem of communicating through the phone, think out loud and communicate throughout the process.

It's very, very hard to evaluate a candidate where you cannot know what they're thinking about and it's just long periods of silence. So with that, we're going to take some of the questions that you have been asking in the live stream. MATT BENNICE: OK, so the first question came from Tim.

How similar are technical interviews for APMs and SWEs? So for folks that don't know, APM is the product manager. And SWE is a software engineer. So as an APM, it will be less technical. You're not going to have to do as much coding, but you're going to be expected to understand what code would be and what solutions would be working.

So it would be much more like a design- and construction-type question as opposed to a SWE, where we're expecting to see very explicit code and very explicit data structures. EDGAR DUENEZ-GUZMAN: That's right. So we have a question by [? Tanicia.

?] For the phone screens, is it behavioral questions? So I would say that at the very beginning, you're going to have an interview with a recruiter in which you will be doing those code samples and things like that. But you will then go for a full, technical interview in which it will be you and an engineer discussing a problem. And there is no difference in terms of the content between a phone screen like that and an on-site interview.

It's going to be coding. It's going to be algorithms. It's going to be design.

It's going to be software engineering principles. MATT BENNICE: So [? Joydeep ?] asks, how does programming in class vary from programming on the job? The biggest one, and this is actually one of the things I talk about a lot, is your code has to work more than once. When you write something for class, it has to work once for your professor's limited set of test cases. So coding on the job, now imagine the professor, after you've handed in the homework, told you that the rules for the homework have now changed. Additionally you didn't write half the code.

And finally, it needs to work for the next 30 years. So you end up spending more time on the organization where when you're writing code for homework, you might use variable x, variable y, variable z. And that's great because it needs to run once. However, nine months from now, when you go look at that code to figure out what you did wrong, you're not going to understand what you did. So you spend more time choosing good variable names, choosing good function names, putting in really nice comments. Because nine months from now, even if you wrote it, you're going to look back and be like, what was I even thinking? So that is probably the biggest difference, is that the code needs to exist longer than a very finite period of time. And the rules for that code are going to change often.

So you learn to not write what's called fragile code, where things are very subject to their input conditions. You start making lots of little modules, which can be interchanged and moved. And if I have to change one of them, I don't have to worry about breaking the others. EDGAR DUENEZ-GUZMAN: OK. So we have a question by [? Arshad.

?] Do you recommend reading "Cracking the Coding Interview" to prepare for the technical interview? Yes. I would definitely recommend that book. I used it when I was preparing for my interviews here. I would say there's all sorts of interesting resources online.

There's practice questions in CareerCup, which is the website companion of that book. There's also questions in Glassdoor. MATT BENNICE: Project Euler. EDGAR DUENEZ-GUZMAN: Project Euler.

There's TopCoder. There's Code Jam. There's all sorts of platforms for training. And competitive programming is a way to prepare. But again, remember that in competitive programming, you are targeting a solution that will be run once, like what Matt was saying. So you also need to prepare for testing things and making things readable code, modular code, good practices. MATT BENNICE: I would also say read an algorithms and data structures textbooks just cover to cover. Because that is the core of almost all of these interviews.

If you come in with solid data structures and algorithms knowledge, it's like having a nice, big toolbox coming into the interview. You're ready to handle everything. EDGAR DUENEZ-GUZMAN: Yes. So we're going to repeat the sites-- Project Euler, CareerCup, Topcoder, Code Jam. There's-- MATT BENNICE: Glassdoor has some. EDGAR DUENEZ-GUZMAN: Glassdoor.

MATT BENNICE: Hired is another good one. They have those little-- EDGAR DUENEZ-GUZMAN: HackerRank as well, they have some. Good practice. So we're going to move on.

Austin is asking, if you spot a mistake during the coding portion of the interview, do you point it out or wait for the interviewee to notice it themselves? MATT BENNICE: It depends on the level of severity. If it's like a small little glitch that I can have you catch at the end without totally affecting your algorithm, then I'll leave it alone. But if you're clearly going off path, I'm going to stop you sooner rather than later.

EDGAR DUENEZ-GUZMAN: Right. And it also depends on the interviewer. There are some interviewers that are much more hands on and some interviewers that will let you hang yourself. It's OK to make small mistakes as an interviewee, and it's even better if you catch them yourself. MATT BENNICE: OK. And then our last question for now from Oliver. How important are concrete examples of work for first-year students? Are we evaluated more on our portfolio or your interview? Your portfolio gets your foot in the door. Your interview's what counts.

So if you have some good concrete examples of your work, great. That will get a recruiter's eye, and that'll get you an interview. But the interview is what matters. We're expecting to see you be able to produce and read code.

Assuming you're saying first year students, you're probably talking engineering practicum. In general, you have a reading code interview and a writing code interview. So those are what we would be looking to see, is more the interviews. But don't think you're-- getting in the door is still tricky.

EDGAR DUENEZ-GUZMAN: OK. With that, I think we're going to go into the practice question. So we're going to be giving you some flavor of a mock interview. We're going to try to make it as realistic as possible. And give us a second while we prepare. Here we go. MATT BENNICE: And we're back.

EDGAR DUENEZ-GUZMAN: Perfect. So the question that I would like you to solve is imagine that you were transported to the Middle Ages and the print of movable characters by Gutenberg has just been invented. And you want to change the future. So instead of printing Dante's "Inferno," you want to give them a copy of "The Art of Computer Programming" by Knuth. And so you want to figure out if you can print that book given the sets of characters that Gutenberg had already set aside for printing Dante's "Inferno." MATT BENNICE: OK. So looking at this problem, I think the first thing is, how am I getting my inputs? Am I getting a string, Dante's "Inferno"? And then I'm going to get a string of "Art of Computer Programming." And then I'm going to try and see if I can match it. So if I have hi, my name is Matt. And I am hungry.

I want to be able to say I can take an I. I can take an A. I can take an M. Am I allowed to re-use letters? I can take an H. EDUARDO DUENEZ-GUZMAN: So that's an interesting question. So one of the things that I can see is that case may matter. MATT BENNICE: So we can say, the assumptions here are going to be case matters. And then additionally, I can't re use letters.

Because it's a printing press. So if I use an A here-- EDUARDO DUENEZ-GUZMAN: Let's say you can't-- MATT BENNICE: [INAUDIBLE] EDUARDO DUENEZ-GUZMAN: --reuse letters. MATT BENNICE: Awesome. So now, if I think about this, I can come up with a brute force solution, which is basically for every letter I need here, I can go through the previous one and say, OK, H, I, and eliminate the I. The next one I can go through is A.

And I'll read through here, and when I find an A, I can cross it out. Then when I go through an M. So off the top of my head, that's going to be O of m times n, where I've got m is my source and n is my destination. EDUARDO DUENEZ-GUZMAN: OK. MATT BENNICE: But I want to think-- EDUARDO DUENEZ-GUZMAN: Yeah. MATT BENNICE: There might be a better way to do this. So I guess, primitively, I could sort the letters in each message. So I could say the first one would then be m log m plus m log m lookups.

But I think even better is-- seeing as I don't need to know where the letters are, right? EDUARDO DUENEZ-GUZMAN: Right. That's correct. MATT BENNICE: So instead, I could just simply count the letters because you said case matters. But one H is the same as any other H. So I'll have 52 possible buckets.

We're assuming English, right? I gather we were in German back then. We'll assume English for our sake. So that's 52 possible situations. So that's easy to put in the dictionary. So I could effectively have one uppercase H, two lowercase Is. And then I can compute this for the source and then compute another for the destination.

EDUARDO DUENEZ-GUZMAN: OK. So you're building a histogram of all the letters that you have. OK. MATT BENNICE: And I think that one's going to be O of m plus n, because I have to read through the first one and then read through the second. EDUARDO DUENEZ-GUZMAN: Right. Yeah. OK. So what are the memory requirements of these three solutions that you posed? MATT BENNICE: The first one would be O of m plus n, or m plus n.

And then I would say this one, depending upon how you sorted it, would be O of 2m plus 2n, if you used merge sort. And then-- EDUARDO DUENEZ GUZMAN: So let's say additional memory. Not taking into account the input, but what additional memory are you using? MATT BENNICE: This would be O of 1, no additional memory.

This would be O of m plus n, if I use merge sort. And this would be O of approximately 1, because the dictionary is going to very small compared to the other ones. EDUARDO DUENEZ-GUZMAN: OK, but what would be the difference if you had a more general character set? MATT BENNICE: The larger the character set, it would be an order of the size of the character set. EDUARDO DUENEZ-GUZMAN: OK. So this sounds good.

I think what I would like you to do is code the one with the histogram. Yeah. MATT BENNICE: So now, just to break and explain what happened here, we spent about three minutes going through and analyzing the problem. So we talked a couple of different solutions. You saw how I was verifying my assumptions against my interview. Otherwise, him and I could have been on different pages, which could have led me to spend 10 minutes coding something that isn't going to be what he asked me for. So always try and give a concrete example showing, hey, this is what I think you're really asking for. And then, like we said earlier, I knew a brute force solution right away, but then I had to work my way to the actual solution.

Now if a faster solution, or a good solution, feel free to go straight to it. But in general, you can work your way down and say, OK, I'm here. This is the cost. Can I think of anything to make this better, and try it. Like, can I divide this in half? If I divide the top string in half, is it making my life any better? No. Is there a heuristic I can use, like greedy method? No.

In this case, dynamic programming and an indexing solution were the two best solutions. EDUARDO DUENEZ-GUZMAN: Right. And you can see that it was a lot of back and forth. The interview wasn't just me saying the problem and then going to coding it. It was much more about, OK, what happens when this changes? What happens if the character is different? What happens if uppercase or lowercase are different? All of these are questions that I've intentionally left unanswered at the beginning so that he would have to clarify them. And you can see that by clarifying all of them, now, all of a sudden, he has a very good grasp of what the possible situations for the problem are and how to solve them. And what we're going to do now is-- [INTERPOSING VOICES] MATT BENNICE: OK. The first think I'm going to do here is I'm going to make myself a helper method.

So we'll say, the first thing I'm going to do is compute that dictionary. So public-- this is in java, by the way, folks-- public map of character to integer. And we'll just call this compute map. And that's going to take in a string of a message. And then, I can say my return is going to be map of character to integer [INAUDIBLE] equals new.

And we said earlier I'm going to use a hash map because of its cost characteristics and memory usage. So then, what I'm going to do is I'm going to say for every character in the string-- notice I'm closing my brackets. Keep in mind, it's a lot easier to do this because you're not going to have an ID to keep track of yet. So now we're going to say if my map that contains key C-- if my map does not contain the character, then we're going to say, my map [? output ?] C 1. So in this case, I'm saying, for the first letter I find, if it's not in the map, then I have one of them. Else, I need to increment my count. So I can say my map dot put C.

My map dot get C ++. And then, once I'm done building this map, I can return it. So this will go through, and given a string, turn it into that histogram that we were talking about, where I can have a count of each of the letters.

EDGAR DUENEZ-GUZMAN: OK, so how convinced you are that this is correct? MATT BENNICE: I'm pretty comfortable. It looks like if I give it string ABCA, it will go through and say, step one, initialize a new map for every character in the message. So the first one would be C would be A. So we'd say it's A. Does my map contain C? No. So it's going to say, add A, 1.

Skip the else. Next in the loop will be B. So we'll say, does my map contain B? No. B, 1. If not, it's going to say C. It will do the same thing, C, 1. And then when I get to A again, it's going to say it does contain it. So it's going to say, put C, the existing value of A, plus 1.

So we'll find A, and then put 2 here. EDGAR DUENEZ-GUZMAN: OK. I'm just a bit confused about that, then. MATT BENNICE: So my map dot get C, in this case, would return 1.

++-- oh, OK, so you'd rather +1 instead of ++? EDGAR DUENEZ-GUZMAN: Well, ++ is-- so what is the difference between ++ and-- MATT BENNICE: OK, so in that case, I++ means, increment this by 1. Ah, I see what you were saying. No, yeah, it means, increment this by 1, and then return it. The ++I means return the value and then increment it, I believe. EDGAR DUENEZ-GUZMAN: OK. MATT BENNICE: In either case, this is clear. So this is the more reasonable solution. OK, so this is our function.

EDGAR DUENEZ-GUZMAN: OK. MATT BENNICE: And now, to make it a little easier, we're now going to use this helper function to do our job. So hopefully you would have enough room. If not, you can feel free to erase your notes like we just did. So OK, now I'm going to say, we wanted to simply know whether or not it would work. So public Boolean check message. And we're going to say, string source and string destination, bracket-- sorry, started to run out of space there.

Giving myself plenty of room here. So the first thing I'm going to do is I'm going to say, map of character to integer source map equals compute map source. And then I'm going to say, map of character to integer dest map is equal to compute map of my destination. And then what I'm going to do is I'm going to loop through my destination map and make sure that I have enough values in my source map. So for character-- actually, a better way to do this would be, for entry character, integer e in dest dot entry set. All right, so this is going to get me a list of tuples in my destination map.

I'm now going to say, if source map does not contain-- if it does not contain the key I'm looking for-- so it'll be e dot get key or source map dot get e dot get key is less than e dot get value, return false. So here now we have, I'm going to go through. I'm going to get my histograms, like we talked about. And then I'm going to loop through all the entries in the destination histogram.

And then, for each character, if the source doesn't have any of it or the source doesn't have enough of it, return false. It means I can't make it. If not, return true, which means I can. EDGAR DUENEZ-GUZMAN: Sounds good. How would you test this? MATT BENNICE: OK, so the easiest way to test this would be to give it two input strings. So we could say, like we did earlier, Hi my name is Matt and I am hungry. So this would be the source. This is the dest.

And then what we'll end up doing is computing the histogram. So we'll have H, 1; lowercase I, 2; lowercase M, 2; Y, 1; N, 1-- EDGAR DUENEZ-GUZMAN: Excellent. MATT BENNICE: And I think we'll have gone far enough at this point. Because we're going to hit here. So then we can say-- actually, no, we need to go all the way to [INAUDIBLE]-- A would be 2; two As. And then I'm going to have, my other one is going to be uppercase I, 1, lowercase A, 1, lowercase M, 1, uppercase H, 1, lowercase U, 1.

So now I would have computed these two maps using this function we already tested. And then I'm going to say, for every character in my destination, I'm going to walk down. And it's going to be uppercase I. I don't have one-- fail. Now, if this was a lowercase I, to test a slightly more positive case, lowercase I would then test. And I have two of those, so I'm good to go here. Lowercase A, I have two. So it would pass.

Lowercase M-- I have two-- would pass. Uppercase H-- I have one. It would pass. And then lowercase U, I don't have, at which point, that would fail.

EDGAR DUENEZ-GUZMAN: Any other test cases that you would use? MATT BENNICE: Maybe just an exact ABC to ABCA, And then we could just do AABC. So then this would compute into A, 2, B, 1, C, 1. And this would compute into A, 2, B, 1, C 1, at which point, it would work because you could go through and the source map contains the key. The source value is greater than the destination value. Therefore it'll eventually return true. EDGAR DUENEZ-GUZMAN: Sounds good.

So you can see that the code was well-structured. Having this helper function helped a lot for the solution. It was broken up into these pieces that were easily tested independently. There were a semicolon that was missing here, and there was a little thing here. Those are not important at all. That's a good thing to show those? I don't know if you even-- MATT BENNICE: Yeah. We intentionally make small syntax errors through these types of things. But we want to show you that those-- your interviewers are going to care in terms of, they want to see clean code.

They want to see that you're making good efforts and stuff. But if you miss a semicolon, not the end of the world. Parentheses and brackets are a little more important because they really control the flow of the code. Same thing-- if you don't know a function-- so say you didn't know entry set, but you know that the feature exists-- don't get hung up on it. Tell your interviewer, this is what I'm looking to do. Either your interviewer will give you the syntax for it, or say, I'm going to make up a function called get the entry set, which will do this for me.

And I will try and figure it out later. Don't spend 10 minutes harping over a piece of syntax that you don't need to worry about. EDGAR DUENEZ-GUZMAN: Exactly, yeah. And also, you can see that there wasn't that many lines of code written. It was one of the things. If you are writing more than 20 lines of code, maybe re-evaluate what you're doing. MATT BENNICE: Especially if you start writing very repetitive lines. So if I had to write this helper function out twice, that would have been a lot of writing.

Meanwhile, by making the helper function-- spend a minute structuring your program in your head before you go into coding. Because otherwise, if I was like, oh, I need to make a histogram. I need to make another histogram. Let me just keep writing this same code. The other thing is you don't have copy and paste on a whiteboard. None of that exists.

So if you make a mistake, try and leave extra room for things so that, if there was a mistake, you can correct it rather than trying to-- oh, wait, I have to erase six lines and move all six lines down. Try and intentionally leave yourself a little white space between every line so that you can fill in the gaps. EDGAR DUENEZ-GUZMAN: Mhm. And the test cases-- same order, same number of things. Edge cases like that-- having them in different order, having them some repeated, some missing, some in there-- those are all very good edge cases to look for.

Yeah, I think-- MATT BENNICE: I think that's it. So let's go-- EDGAR DUENEZ-GUZMAN: We probably should be taking some more of their questions. MATT BENNICE: Yeah, let's go hit some questions. EDGAR DUENEZ-GUZMAN: OK. We have a question by [? Ronak. ?] Which data structure and algorithms book study material would you recommend to study? MATT BENNICE: I've read "Data Structures and Algorithms in Java" cover to cover, but that is not an endorsement. It was a good book.

But most of the good data structures and algorithm books, it doesn't really matter the language. Pick one that is good for the language you're working in. And then look at the preview, or go check it out at Barnes and Noble or something, and see.

You're going to want to make sure you go over linked lists, vectors. You're going to want to go over maps, hashing, graphs, all of those different types of things. Algorithms, you're going to want to know all the sorting algorithms. You're going to want to know divide and conquer, branch and bound. You're going to want to know dynamic programming, greedy method.

Just make sure you're hitting all of the big topics. Otherwise, there's several really good ones out there. You don't really need to read something as esoteric as "Art of Computer Programming." You can be a little more on the practical side.

But if you really like assembly and made up assembly languages, then please, feel free. EDGAR DUENEZ-GUZMAN: Yes, absolutely. I would just add up to that, when I was preparing for my interview, I did myself a cheat sheet with information about all of the main algorithms and their complexity and their memory requirement. And I got that from Wikipedia. So there's plenty of resources online. You don't need, necessarily a book for preparation.

MATT BENNICE: I recommend coding yourself a copy of all of the data structures and then implementing most of the big algorithms on the data structures you coded. Because if you can get through doing that, you know it solid. EDGAR DUENEZ-GUZMAN: Mhm. Sounds good.

MATT BENNICE: OK, next question is from Matthew Crosby. How much does it count against you if the right way to a solution doesn't come to you immediately, and you might take a bit longer to think things through on your own? That's fine. We were doing it a little quicker, because guess what? One, we've seen this question before-- hint, hint. And two, we work on this kind of stuff every day.

So we were trying to do it quickly so that we had more time to answer your questions. But normally, when I used to use this interview question-- it's now banned. None of you should get this question-- when I used to use this question, it would generally take about 30 minutes or so, 35 minutes, for a normal person to get through it. And then the advantage with this question-- and we didn't really get into this-- is that this question can be made a lot harder. What happens if your source message is a petabyte long and your destination message is 10K? What happens if they're both a petabyte long? How can I change this program to work in those cases? So that's a good Google interview question, is when if you finish it in 10 minutes, great. I can make it a lot harder for you. If you're dragging and taking a while, we can make some assumptions that will make it cleaner. Think the GREs if you ever took it.

We're going to try and tune the question just to the point where you'll finish it right at the end. EDGAR DUENEZ-GUZMAN: Right. And another thing I want to mention is that we're not looking for the perfect answer to a problem.

The conversation and the discussion with the interviewer is the most important part of it. We go back and forth. You understand the trade-offs. You realize that the solution that you're proposing is-- for instance, the first solution that Matt proposed was quadratic, but had the advantage of not requiring much memory. That's fine. If you don't think of anything else, at least you will be showing the interviewer that you are aware of the trade-offs and things like that. That's definitely an important part of it. MATT BENNICE: And I guess that kind of answers Mike's questions.

Know while the optimal algorithm is great, if you're also the kind of person that-- OK, we know-- we can tell if you've seen this question before. Yeah. So like he says, it's really much more, how do you approach the problem? How do you break it down? Because we also realize that in your day-to-day life-- obviously, we're trying to prove whether or not you would work well in Google-- you're not going to be on a 30-minute timetable to solve this problem on a whiteboard. Good luck. You're going to have an infinite amount of support with all the other engineers around you and all the tools and resources we have to come up with the best possible thing. And a lot of times, the optimal space or time complexity algorithm isn't optimal for a Googled case problem where, really, parallelization is the optimal case for us. EDGAR DUENEZ-GUZMAN: Yeah, definitely think about large, large problems. Scale them up.

That's a very Google way of doing things. OK, so we have another question by [? Tushita. ?] Does the difficulty of interviews get higher as you do the second or the third? No, that would definitely be not. MATT BENNICE: Your interviewers don't even talk to each other between interviews. They hand a sheet of paper back and forth, you'll see. But on that sheet of paper is simply a list of the questions you've been asked-- EDGAR DUENEZ-GUZMAN: --so that they don't repeat it.

MATT BENNICE: --so that they don't repeat it, exactly. And in general, when they assign the interview, they'll say, oh Matt, you're good at data structures and algorithms and Java. So you're going to ask a data structures and algorithms question. But someone else might have done graph theory or image compression. They're going to go through your resume and try and see if they can pick out the best types of interviews for you to get through. EDGAR DUENEZ-GUZMAN: Yeah, so we have another question by an unpronounceable handle-- brrrf.

Would you generally do the same thing in a Google Doc? Would you still need to write out example input, et cetera? Or are phone interviews different than in-person? No, they are not different. MATT BENNICE: I would do the exact same thing. EDGAR DUENEZ-GUZMAN: Exact same thing. The only difference is that in a Google Doc, you can actually do copy-paste. So that helps with all of the brackets, character, integer. You can just do that. MATT BENNICE: And as a hint for that copy-and-paste thing, please don't Google the question and try and find yourself an answer on Stack Overflow. It happens.

We can tell. It's not that hard. So another question for [? Tushita.

?] Am I going to be asked questions on topics I haven't learned, like operating systems or networking? Will I be asked on what I mentioned I know in my application? So in general, you should have some concept of how operating systems and networks work. You should know how to use a computer. You should understand that information can be sent across a network and that, depending upon the speed of the network and the amount of information, it's a trade-off. But for the most part, we're going to tailor your questions towards what you said you were good at. Now, if you say you are an expert in JavaScript-- I guarantee you most people watching this video are not experts in JavaScript.

So when you say "expert," you say, I've written a book on this. And people have bought my book. And it has four stars on Amazon.

Then you can call yourself an expert. EDGAR DUENEZ-GUZMAN: Don't call yourself an expert. MATT BENNICE: But realize when you do call yourself an expert, that actual JavaScript experts are going to be there.

And you are going to be getting some of the most esoteric questions you've ever heard of. EDGAR DUENEZ-GUZMAN: So there's two aspects of this. One is, don't claim that you're an expert.

MATT BENNICE: Like the guy that wrote Python sits down the row from me. EDGAR DUENEZ-GUZMAN: Yes. So everything that you put in your resume is fair game to ask during an interview. So be mindful of what you put there. But the other thing is that we are going to be getting interviewers who are able to evaluate you. So if you are a new grad, or if you are a junior or senior who is trying to go for an interview, or if you are a person who has three years of experience in the industry, the interviewers and the questions that you are going to be asked are going to be very different. So we try to tailor the interviewers to your skill level and your competency.

MATT BENNICE: And then last question from now comes from Alex. What are the concepts to study in order to prepare specifically for an interview in engineering practicum? In general, they're the same, just maybe with a little less depth. So you're going to need to be able to read code. So maybe find one of your junior friends to show you some of their computer science homework, and read through it, and say, hey, this is what I think your code is doing.

The other thing is to practice coding some things. Make sure you can sort an array. Make sure you can look up something in a sorted array.

We're not going to expect you to necessarily be able to implement me a linear hashing function or find the median in linear time. We're not going to expect that. We're going to expect you to be able to give me a good guess of relatively simple algorithms. EDGAR DUENEZ-GUZMAN: And be able to use your data structures.

If you are able to use, effectively, lists, array lists, maps, hash maps, things like those, that's going to be-- MATT BENNICE: Even if you just treat them-- EDGAR DUENEZ-GUZMAN: --the most important. MATT BENNICE: --as black boxes, that's great. EDGAR DUENEZ-GUZMAN: Yeah, that's correct.

Well, OK, let's go back to our slides. MATT BENNICE: Back to the slides. EDGAR DUENEZ-GUZMAN: So yeah, like you saw, interviews are messy. We want to reiterate that small syntax errors are not important. They're not going to be what decides whether you are hired or not.

Try to get the details right. If you have one mistake, it's not a problem. If you have 15 mistakes in 10 lines of code, then it starts to, obviously, look worrying. Write as cleanly as you can. Like Matt was saying, leave extra room. Draw arrows to inserted code where it's appropriate. Try to be conscious of time. Speaking out loud and trying to express all of your thought process usually takes longer than you anticipated.

So be careful with taking up all of your time with just expressing the first thing that came to mind. And of course, the very important thing is that we don't have this policy of one strike and you're out. We take the whole packet of interviews, and that's what goes for review. It's not that when you do badly in one interview, then you are out. And I can speak to that from personal experience. One of my interviews, I'm pretty sure I bombed it. MATT BENNICE: Ditto. Oh, I'm pretty sure I bombed one, too But that's OK.

The whole point of Google isn't that we're trying to find what you suck at. We're trying to figure out what you're really good at. So that's why you get five or six interviews. It has nothing to do with waiting for you to fail. It has to do with us waiting for you to knock one out of the park. EDGAR DUENEZ-GUZMAN: Yeah, and some final tips-- remember, there's no shortcuts. You need to practice, practice, practice. Write code.

Have your data structures well-studied. Be ready for anything. Like I was saying, questions related to what you have in your resume, don't say you're an expert. But do highlight the things that you're most comfortable talking about. Because we want to know, what are your skills, what are your strengths. Those are the things that we want to talk about. And over-communication is better than not communicating at all.

And make sure that both your interviewer and you understand what you're doing. So explain what you're trying to solve, and ask what the question was. Keep this conversation open, back and forth with your interviewer. It's probably the most important thing that you need to do in an interview. And so we have here some additional resources. Obviously, we have the tech dev guide at Google.

And we have the suggested text, as we've been discussing it already, "Cracking the Coding Interview," the sixth edition. It keeps growing. It keeps getting more in-depth. It also has the CareerCup site associated with it with practice questions. And we have another couple of resources here that we also discussed-- TopCoder, Project Euler, for tutorials and questions.

And this last one I haven't personally checked myself, the LeetCode. But it's apparently very good. MATT BENNICE: Yeah, I haven't used it either. I'll check it out for the next one. OK. So obviously, how to apply-- please go to g.co/studentcareers to find the best roles for you.

Upload your resume and transcript. We don't need a cover letter. We get that all the time. We don't actually want one. And then, click Submit. If you don't apply, you'll never get a chance.

So please, even if you're on the fence, spend the 20 minutes and apply. EDGAR DUENEZ-GUZMAN: And with that, we thank you very much. I hope you enjoyed this session. I hope you found it interesting and useful. MATT BENNICE: Yeah, thanks a lot, everybody. Are we still doing any more questions? Yeah, I believe we still have a couple more questions here. So we'll go through and try and see if we can resolve these.

And if anyone else has any questions, please post them. Obviously, this time is for you. So we want to make sure we're getting everything resolved. So [? Stephen ?] asks, Have you found the types of interview questions you were asked in your interviews map well to your day-to-day tasks as an employee? Yes and no. Very rarely have I ever had to worry about reshuffling letters. But the type of situation where someone comes to you with a problem that isn't a computer science problem, like, hey, how do I hide comments in G+ that are spammy? Or how do I route drones? All of those are very real-world problems that you then need to deconstruct into a computer science problem.

And then those types of things like coding on a whiteboard or working with somebody you do every day of the week. You spend at least half of your time as a Google engineer asking another Google engineer for help, guarantee it. Because so much of your time is interfacing your system with their system, or their system with your system, that you generally need to spend a lot of time making sure the two of you are on the same page.

Because my end of the interface and your end of the interface have to meet in the middle. If not, we're going to have a bridge that has a gap in it. And that's not going to make anybody happy. EDGAR DUENEZ-GUZMAN: Yes. And Michelle has a question. Can you give you an example of what you, as the interviewer, like to see in an interviewee, both on the phone and in person? I would say that my ideal candidate would be one that takes my very nebulous question and clarifies it until the point where it's very, very obvious what the code should look like, a candidate that expresses the trade-offs between different solutions clearly and correctly, and that writes very clean, very well-thought-of code. MATT BENNICE: Agreed. The big thing-- obviously, please clarify those assumptions.

Sorting a list of integers, if I ask you to sort of list of integers, your first question shouldn't be, oh, I'll use quicksort. It should be, what are the integers actually representing? Because sorting a list of zip codes is a very different problem than sorting a list of 64-bit integers because you simply need to count the zip codes. You don't actually need to store each of them. So clarifying the question will often be the trick to a lot of interviews that a lot of people don't generally get. It's that first step of, hi, yeah, you gave me something I've never seen before, but I'm going to work with you to turn it into something I know how to solve. EDGAR DUENEZ-GUZMAN: OK, we have another question from Oliver. If you go through one interview round and don't make it-- you don't hired-- and you get interviewed again in the future, does your past attempt count? Should you reapply? And yes, yes, yes, you should reapply. In fact, probably, Google will go back and bug you a year after, and say, hey, are you still interested? Because it makes sense.

If we have identified you as a potential employee, you have talent. And people grow. One year, two years, people learn new things.

People have different experiences. And obviously, we want to bring you back, because we want that talent here. So it does count, what you have done in the past, but probably not in the direction that you're worried about.

It doesn't count against you. It counts for you. It shows growth. MATT BENNICE: We won't ask you the question again. It's just like how your previous interview doesn't count to the current interview as you're going through your four or five interviews. It's simply, we're not going to ask you the same questions again so that we can see what your new skills are. EDGAR DUENEZ-GUZMAN: Yes.

And we have some last-minute tips. So remember, practice, practice, practice. Interviewing is a skill that you can perfect. So problem solving is something that you can get better at. Again, practice your data structures. Practice your algorithms. Practice writing code on that whiteboard. Practice speaking out loud your thought process.

MATT BENNICE: Over-communicate. Please-- if we know what you're doing-- like we said, this is a conversation-- we were going to help you. If you are off in left field and you're not telling us anything, we won't know you're there. So please, tell us what you're doing. Obviously, we understand if you want to think quietly. That's fine. Just plan, like every five minutes or so, to re-sync with your interviewer.

Don't just write me 500 lines of code and expect me to be like, oh well, on line 3, you made a mistake. But because I didn't know what you were trying to do, I couldn't tell you you were wrong yet. EDGAR DUENEZ-GUZMAN: Mm-hmm. And the last thing is, pay attention to your interviewer. Your interviewer might want to give you hints.

And he will not necessarily be aware to tell you, hey, you may have had something wrong here. But he'll say something. And he's saying something, or she's saying something, listen and figure out why they were bringing that up. So we try to give you hints. We try to make you succeed. We are interested in getting you to perform the best you can. So listen. Listen and keep communicating.

And I think with that, we're going to close this. MATT BENNICE: Yeah, I think we're done. EDGAR DUENEZ-GUZMAN: Thank you very much for joining us. MATT BENNICE: Thank you, everyone. EDGAR DUENEZ-GUZMAN: I hope you had fun.

Views: 38 531 Likes: 519 Dislikes: 14
98% Likes
2% Dislikes
Illinois Vice Chancellor of Student Affairs Video Blog

Greetings to Student Affairs and other staff, faculty, and students. As we start this new semester, what is foremo st in my mind is the change in the administration in Washington and…

Views: 78 By: Illini Union
15. Introduction to Lagrange With Examples

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make…

Views: 233 634 By: MIT OpenCourseWare
#WelcomeToStanford

[MUSIC]. I remember when I was a freshman coming to Stanford. I, was pretty jittery. I was really nervous. And I was just thinking, wow, I do not know anybody out here. And that can…

Views: 289 780 By: Stanford
Lecture 1 | Introduction to Convolutional Neural Networks for Visual Recognition

- So welcome everyone to CS231n. I'm super excited to offer this class again for the third time. It seems that every time we offer this class it's growing exponentially unlike…

Views: 130 927 By: Stanford University School of Engineering