CodePath EES2024 GOOGLE - Cracking the Code: Mastering the Technical Interview with Google

Hey everyone, how awesome was that keynote speak by VC? Oh my god, I learned so many nuggets. Welcome to day three.

We’re so excited to have you here. This breakout session is one I know that so many of you have been looking forward to. Cracking the code, mastering the technical interview with the Google team.

Yay. We are excited to have you join us today. I’ll introduce the speakers shortly, but first I wanted to go through some of the, you know, P’s and Q’s.

Please utilize the chat to have conversations and share your thoughts during the session. Please keep your messages relevant to the topic of the session and note that the presenters and speakers can see the chat. Our team will be monitoring the chat and questions may be answered live during the session.

Following the session, we ask that you complete the brief feedback survey because your feedback is super important to us. I’d like to go ahead and introduce our speakers from Google. Give them a round of applause.

Yay. Hi everyone. Very excited to be here.

Hey everyone. Very excited to be here as well. Awesome.

Well, let’s Josie, can you bring our presentation to the stage? Awesome. Okay.

Hi everyone. Today we’re going to be learning about the interview process for tech careers. So this deck has been created in partnership with Google, but it’s not specific to the Google interview process and will really help you gain a broader understanding of the tech industry at large.

Next slide, please. Awesome. So, who are we?

I’m Lindsay. I am a software engineer at Google. I work on compute.

So all of Google’s processing power. We power Google’s machine learning algorithms. Lots of different companies that run on Google Cloud, basically any computing power and been enjoying that team a lot.

I’ve been at Google for over five years and it’s been really rewarding. Okay, I’ll go next. Hi everyone, my name is Sonaki Pande.

I am a data and AI specialist with Google Cloud. I’m based in Seattle and I’ve been working in the cloud industry for over eight years. Prior to Google, I come from Amazon where I started my career as a software engineer.

And here’s a fun fact about myself. When I’m not working in after my 9 to5, I’m doing two things. Either I’m cooking something fun, some viral viral recipe I saw on Tik Tok or on YouTube or I’m creating content.

So yeah, that’s about us. And now I’m moving to the next slide. Okay.

So, before we get started, we’d love to hear a bit from all of you about your experience so far with interviews. So, feel free to drop in the chat what are some things that come to mind when you think about interviews? Do they seem like a fun new experience or do they make you a little worried or stressed about questions that people might know?

Seeing people a little nervous, a little scary, okay, a little stressful. Hopefully after this session, we’ll feel a little better about things. Have many of you interviewed in the past at all?

Have you attended any interviews or are you planning to attend some this year? Okay, seeing a lot of yes, but a bit of a mix. Had some recently.

Okay, great. So, this will be very top of mind for everyone. Okay.

So, in today’s workshop, we are going to focus on the technical interview and help you better prepare for it. By the end of today’s workshop, you’ll hopefully you should understand and be able to apply all of the interview techniques including knowing the structure and purpose of a technical interview so that you can know more what to expect. Learn general skills and attributes that companies are looking for in a technical interview so you can practice demonstrating those things.

You will learn effective problem solving techniques and areas for success in the technical interview questions. You’ll also learn how to use the STAR method to respond to behavioral or situational interview questions you may be asked in an interview. And also, we’re going to practice presenting and communicating in an interview setting so you’re ready for the real thing.

So, in these next few slides, we’ll be talking about the different motivations for interviewing. First, why do companies interview? Companies interview to identify candidates who may be a good fit for an open role.

Learn about candidates who have applied and determine how candidates may respond in certain situations. This isn’t an exhaustive list, obviously. So, as we go through the next few slides, we’ll think a little bit more about why companies would interview.

A candidate would also have many reasons for interviewing. And this is of course all of you. Interviewing provides a good opportunity for candidates to learn about the role in company and ensure the role might support their overall career goals.

Sometimes the candidate is interviewing the company as much as the company is interviewing the candidate to try and learn if it’s a good fit for them and what they might want. It’s also a great time for candidates to meet potential teammates or their manager and see where they might be working, who they might be working with, what that could look like. An interview is a two-way street for both parties.

And this last part of an interview is of course the interviewer actually carrying out the interview. So why might they choose to do that? Depending on the company and the role, interviewing might be a part of the interviewer’s job responsibilities.

Like every person has to interview a certain number of people. But and this is more common at large tech companies. Additionally, some folks find interviewing really fulfilling and a great way to give back to a company.

You get to talk to candidates and see who might be a good fit and help in that process. Interviewers might be eager to meet and assess potential teammates and have their voice be a part of that discussion. They also might be excited about the opportunity to travel for interviewing.

For example, it’s common for companies to interview at major com conferences like Gracehopper or Nesby. So we’ve gone over a few motivations, but I would like to hear from some of you, why are interviews mutually beneficial or what are other motivations to interview for a company, candidate, or interview? Feel free to drop in the chat.

Culture fit. Yes. Yeah.

Seeing if a candidate is a good ad to the company and see if they would work hard. Candidate might want to learn about the organization and team. Yep.

And maybe a candidate is swift switching between careers and trying to see if this new thing is a good fit. Yeah. It’s also potentially a good networking opportunity.

So, you’re talking with people and that’s a great point. Cool. Yeah.

Thank you all so much. Great. Thank you for all your responses.

So now that we’ve talked a little bit about motivations for those involved in interviewing from all sides, let’s move on to common types of interviews. So there are several different types. For early career internships, this may look more like a code reading interview to discuss what code does or supposed to do because your coursework may not have covered enough data structures and algorithms for an interview.

So this would probably be for first or second year students. It would be more reading a lot of things. Though when you join a company especially larger company like Google there is a large existing codebase and you need to be able to read that and then contribute to it and understand it.

You can also have a phone screen or phone interview where you’ll discuss a coding question usually around data structures and algorithms with an interviewer over the phone. For phone interviews and some on-site interviews, you may use a coding environment, which is a workspace for developers to create and edit code like a Google doc or online code editor. So, this will look this is a common starting stage for many companies to first interview over the phone or otherwise online.

But finally, if things go well, companies often do on-site interviews, which would be conducted in person at a company’s office or sometimes over video conferencing. In an on-site interview, you may use a whiteboard in place of a coding environment, especially if you’re in the office. This is another chance to see you in real time how you might write code and work through and solve different problems.

And while most interviews for technical roles will be technical interview questions, you may also be asked some non-technical interview questions. This might be at the beginning or end of the interview or it might be its own entirely own interview. Maybe with a recruiter, maybe with a manager or another person from the job trying to figure out who to choose between candidates that are all technically qualified.

The most common type of non-technical interview question are behavioral questions and hypothetical questions. A behavioral question asks how you’ve handled a situation in the past and might start with tell me about a time when you did some type of behavior. U hypothetical questions offer a hypothetical scenarios to understand what you would do in a situation or how you’ve handled similar situations in the past.

Companies like these types of questions because past experience are usually good predictors of future performance or behavior. Everyone could say, "Oh, I’m very hardworking and I love solving problems." But if you have a few times from your past when you can think of where you actually did that and you come to the interview prepared to talk about them, it’ll make solving these questions a lot easier. So preparing for interviews is an iterative practice.

It’s so different from what you’ll have in your classes and working hands-on with things. It’s really a learned skill that you need to practice and iterate on. You start with preparing move to practicing then to reflecting and whether it’s time to start the whole process again or what things you might have gaps on and need to improve on.

Each iteration helps you refine your focus to improve your skills and build confidence in the interviewing. So starting with preparing which ensures you have a sense of skills you need. You can reference a role job description to learn more about what the companies are looking for in a candidate.

You can tailor your interview preparation and practice to focus on certain skills a company is looking for. For example, if a job requires experience with Java, you might make a plan to learn or review Java. Similarly, you might think, oh, what are a bunch of data structures or algorithms that I want to know going into this interview?

Prepare those things and prepare all the things that you need to actually study and know beforehand. And then this practicing section means going through technical interview exercises until you feel confident with the format and skills. This might be solving leak code problems or problems from different books or from friends in mock interviews to get a good sense of what that looks like.

And really or practicing yourself, finding some problems and working through them. In an interview, you’re not by yourself. You’re with another person and you’re talking through your thought process.

Your interviewer might give you hints or ask you to explain something better and explain how you think about something before you actually code it. And all of this is part of the practice with that communicating and getting used to solving different types of problems. Then this reflecting stage is taking the information and feedback from your practice and incorporating it into the next cycle of preparing.

So we’ll kind of have a constant circle of hopefully getting better and better at interviewing each time. As you see what your gaps are, you identify them and you address how you can get better at them. You practice and you keep getting better and better at interviewing and solving these types of problems.

So, as you begin to prepare, practice, and reflect, there are a few common concepts you can focus on. Most software engineering interviews will ask questions about data structures and algorithms. Depending on your year in school, here’s a list of concepts you might see in interview questions.

If you’re looking for a great way to practice and study, some of our recommended resources to use are hacker link code, the cracking the coding interview book, that’s what I use personally. It has a lot of problems you can use to practice on your own or with friends. It also has a lot of instructional material to bring you to refresh you on all of these data structures and algorithms.

So you’ll see as you progress in each year, year 1, year 2, year 3 plus, you’re expected to be familiar with more and more technical concepts and they’re really free game in an interview for a software engineering position. They could ask you about any of these things. So, it’s great to prepare and practice all of them so that you’re ready.

So, now let’s talk about the structure of most technical interviews. While some technical interviews may be longer or shorter depending on if they’re a phone interview, they’re in person, or some might spend more time on questions at the end. Most interviewers follow a similar structure.

So, we’ll break down each part of the interview into pieces, starting with introductions. So before even starting your interview, be sure to be polite, prepared, and on time with your interview. Your interviewer is the one writing feedback for you.

And of course, it’s always good to be very polite and set off on a good first impression. Being prepared for the interview means finding a quiet location with a charged device. Maybe you want to have a pen and paper handy if you like writing things down and to be make sure you’re totally prepared going into it.

I like giving myself a little pep talk beforehand, and doing some last minute review of different concepts I might want. When you begin your interview, the interviewer may ask you a question about your resume. Anything on your resume is fair game.

They might be trying to get a sense of your past experience, some of those behavioral or hypothetical questions we talked about. So if you’re not prepared to talk about something on your resume, don’t include it. Especially programming languages that you’re not comfortable interviewing in.

The interviewer is probably going to ask you to introduce yourself. And that introduction is a great time for your elevator pitch, which is a quick around 30 second introduction that highlights your experience and qualifications. It’s supposed to be short enough that you could say it in one elevator ride, which is where that name comes from.

And not only is the elevator pitch handy for interviews, but they’re also great for career fairs, networking, events, etc. Just a way to quickly convey who you are, what your experience is, and what your goal is. So, for example, an interview pitch could look like, "Hi, my name is Lindsay. I am a thirdyear computer science student at this university.

I’m passionate about using technology to solve real world problems. In my previous internship, I’ve worked on projects that have developed new educational tools and created more engaging user experiences. I’m looking for an internship where I can use my skills to make a positive impact on the world.

I’m particularly interested in working in healthcare technology. A pitch like that it conveys your past experience and also what you are looking for in a short concise way. And that is something that as mentioned can be used across many different fields.

So definitely practice that and get that honed in. And now I will actually be passing it off to Sinoxy. Thank you for that overview Lindsay.

It was very helpful. It set the stage for what’s to come next. So with interview questions, it is important to remember three things.

Your interview will generally ask you one to two questions depending on how much time is available. And one thing to note is there are more than like there is more than one right answer to the question. Generally technical interviews have more than one correct answer and different answer have different tradeoffs based on design based on efficiency but likely if you are early in your career early in your college career you don’t have to worry about that.

Another thing to note is your recruiter will typically ask you what is your preferred coding language. So ensure that you pick the strongest coding language, the one that you feel most comfortable with and use this language to do all the practice for your coding interviews. And lastly, the interview should generally avoid concepts that have not been covered in your courses.

So if you hear something from your interviewer that you’re not familiar with, tell your tell your interviewer that you know I don’t know about this concept and they will they may ask you a different question. So before I jump into like the secret sauce and strategies of how do you go on cracking your technical interviews, can you share with me what strategies have you heard of or which strategies do you find useful for your technical and behavioral interviews? Okay, I see a lot of people saying empire technique, star technique.

Okay. So looks like we have a quorum on empire and star. Awesome.

It looks like it’s a very common technique. Okay. So folks, I’m going to go video to ensure that the audio quality doesn’t suffer and you folks get a great experience.

So let’s let’s do that. Let’s give that a shot. Okay, I hope this helps the audio.

Now let’s jump into the secret source of how do you go on cracking your technical interviews. What are the three things to keep in mind? So the first technique is communication.

Communication throughout your interview is the key. So companies are generally interested to see how you approach the problem and they give equal weightage to how the actual solution of the problem. So what this means is you need to communicate your approach your problem solving technique during during your interview.

So communicating is of is of paramount importance. When you are in doubt, repeat your repeat talk back to the interviewer. Repeat things that you heard to confirm your understanding.

A lot of interviewers say that a good interview feels like a conversation and it doesn’t feel like a one-way chat where just one person is asking questions and the other one is other one is giving answers. Also a lot of people are internal processors. They love to like internalize information, gather their thoughts and and then walk them out.

If you are a internal processor, then what you should do is let the interviewer know that you’re processing, you’re taking your time and verbalize your thoughts when you’re ready. So that’s completely fine to do that. Another tip or takeaway during your interviews and before you actually jump into answering questions is first take time to understand the problem statement and the requirements.

Do not make any assumptions. Always clarify the interview question because since you have a limited time in the interview, it is important that you confirm your understanding and you solve for the right question. So here’s a tip that I love to follow.

Whenever you get get asked a question in the interview, you can use phrases like hey here’s what I’m hearing and then you can repeat back whatever you understand or you can say my understanding is that you are asking for a b is that correct? So this way you hear the question you repeat to the interviewer this is what you understand and if you are wrong or if you go somewhere wrong the the interviewer will correct you. So that’s about communication.

Now, now let’s say that you understand problem well and you have confirmed that the interviewer. What’s next? The next step is that you set up the solution for the problem.

Folks, give me one second. Okay. How in the chat is my good?

Is it better? I think we might still be having some problems. So, I might click over again for a little bit.

Okay. So we’re talking about setting up the problem. So as we Okay, getting some reverb.

We after we clarify the problem, we then set up the problem. And this is a really important part of the interview. You want to break the problem down into manipulable pieces which will make it easier to solve one piece of it at a time rather than trying to come up with the entire solution at once.

This is a really helpful trick in technical interviewing and also coding in general that you may have noticed yourself. You can start with the best solution you think of and optimize it later to build on your initial solution. Sometimes if candidates optimize too much too early, they might not have time to implement their solution or make something just too complicated.

So feel free to just start with one solution and you can iterate on it to make it better and better as you have time in the interview. It’s also really helpful to walk through an example. Sometimes the interviewer might give you an example, sometimes you might want to use your own and make one of your own.

But it’s a good idea to see, oh, if I have this sample input, what do I want the output to be? These examples also might help you notice if there’s different edge cases that you might need special handling for or make sure that your solution can solve them and you know exactly how it should be handled. They’ll let you know if the output you have is the expected correct output and you can keep that in mind when you’re building your solution.

If you’re a visual person, maybe it’s helpful to draw some kind of diagram or flowchart. Just remember to keep track of time and don’t spend too much time on it so you still have time to write your code. After you’ve talked through edge cases, you can start coding.

You’ve talked at this point, you’ve already talked through the solution with your interviewer. You’ve proposed something. Sometimes your interviewer might give you a heads up and say, "Yes, that solution, that’s a good solution.

Go ahead and start coding." this should feel straightforward and easy hopefully because you’re translating the solution that you’ve already talked about and communicated into coding language. While you’re writing code, continue to speak through each step so it’s easier for the interviewer to follow along and potentially help you out if you start going partly down the main track, the wrong track. Okay, so let’s chat through strategies specifically for coding.

As a reminder, you can usually code in any language you want. You might use pseudo co pseudo code to talk through your initial idea for a solution. It might be a plain language description of the steps in the algorithm that will later translate to actual code that you will need to write.

Talking through it beforehand lets your interviewer check the general flow of your code before you actually start coding. A lot of students ask about coding style in interview and your coding style is a set of rules or guidelines when coding like how do you indent things, how long do you keep certain lines, formatting, variable names, etc. generally you don’t need to focus on this too much. For example, you might not need to add comments to it or make sure everything is formatted in a really specific way, but keep in mind that your code needs to be readable to both you and the reviewer.

And it’s also there’s a little bit of judgment here a bit with you don’t need to overindex on your formatting and style because the content of your code is really much more important but you still need your code to be readable and make it look like it can’t be you can’t totally throw all formatting out the window. It needs to be easily readable and understandable. Also the messier your style is, the more likely it is that you might make a mistake and not noticing not notice it.

Also if you’re coding on a whiteboard, make sure you leave yourself plenty of space. Trying to cram code in on a whiteboard also might make it harder for you to make adjustments later if you need to go back and change a couple lines, add a line in between two points, etc. so after you’ve written the code, this is where you need to consider testing and debugging. If your interviewer gave you at least one example, you could use that to test your code and see if it performs as expected.

This also has the potential to play into that code reading part that we talked about earlier where you show that you really know how to read code. And it also it’s an easy way to find a mistake that you might have written while coding. If you’re actually walking through your code, say you wrote a bug the first time you implemented it in this testing stage, that’s an opportunity for you to fix that bug and make your code even stronger.

Show that you really understood what you were doing. You also, if you have time, try to come up with some edge cases and other examples to stress test your code. It shows you’re thinking about how to test it.

Thinking about all of these different angles. Again, if your code has some bugs, that’s not a big deal, but ideally you’ll catch them and resolve them during this testing phase. Your interviewer might give you more examples and just walk through your code step by step.

They might be giving you a case that causes some issues to see how you handle it. And of course, never just assume that something works. Okay, so we’ve had a chance to talk through some tips and tricks for the technical interviews.

Now, let’s reflect on what we’ve learned. So which of the strategies seem most important to you and which strategies can you commit to trying or what are some things that you learned about the technical interview? Communication.

Yes. Yeah. Communicating your thought process so important.

It helps the interviewer hopefully try and get you back on track and also get more signal about what you might be like what you might be thinking. Also in real life you work on a team with many people as a software engineer and being able to communicate your technical ideas to them is really important. Testing edge cases.

Yeah. Make sure let them know if you’ve seen done the question before. That’s a good point.

Don’t want to cheat. That is not good. Write readable code.

Yeah, setting it up, clarifying the question. Yeah, these are all great points. I am going to hand it back to Sinoxi again and this is going to be great.

Okay. So can you folks give me like a quick you know message is is this audible? Is it better?

I got like traditional headphones. I’m wired. Okay.

Okay. Okay. I see lots of thumbs up.

Okay folks. So we are going to move next. So what’s going to happen is I don’t want you folks to start coding right now or start coding problems right now but hang around with us till the end of this session.

We will share with you a interview workbook and this interview workbook has many steps. What my recommendation is is look at that interview notebook and when you set aside time to practice coding specifically go and look at step number four. Step number four will walk you through all the strategies that Lindsay mentioned earlier.

They’ll help you define the problem, write your analysis, think about how you want to approach the solution, write the code and then also write ideas on how you want to test it. So hang around with us till the end. We will share the link for the interview workbook with you folks.

Okay. Now let’s move on to the star method. I know a lot of people said like you are already familiar with umpire and star technique.

However, for those who are not familiar I want to share what this is and I’m going to run one interview question with you folks. So with star technique you generally use this method to answer non-technical or behavioral questions. When your interviewer gives you like a situational question, you use this technique to answer the question and it is broken down into four parts.

The first one is you talk about the situation on what’s going on. Second, you talk about the task at hand. Then you explain what was the particular action that you took in that situation.

And last one is you then justify your results. So the STAR technique is a very useful way to talk through your behavioral interview questions because it helps you describe your impact in every stage of the process. So now let’s take an interview question.

Let’s say I am asked how have you solved an interpersonal challenge in a classroom. If I get asked this question now here is one potential answer. Let’s start with the situation.

I will say I had a group project in school where one group member wasn’t completing their portion of the group work the task and like even though when I’m explaining you this answer I’m saying situation task action you don’t need to say that in the interview however you have to use this format to say your story. So the task here is rather than going to the professor and getting them involved in this situation, I directly went to the group member and I talked to them oneon one. Instead of framing it as hey you’re not doing your work, I asked them what parts of the group project are most engaging to them so that we can redistribute the work amongst us.

So the action here is by focusing their attention on something that they were excited about, I was able to frame this solution from an issue to a positive one. And what was the result? That team member pulled off their weight in the group project and we were able to complete the assignment on time.

So this is how I dealt with the interpersonal challenge. I was I dealt it with it with with it in a positive manner and I took ownership instead of going to the professor. I helped the person work on something that they were most excited about and get a positive result.

So this is how you use this star technique in action to s to answer questions. And now here’s what you remember. There are like you will run into situations where you are asked hey share what you’ve learned in this situation and what you will handle you know differently next time.

So be open to talking to that and one tip here is you know always be honest and turn around all the situations even though the question is negative turn around all the situations on a positive note and be very strategic with your answer. Provide relevant examples. Provide recent examples and provide examples that are relevant to the job or that that are you can mention about projects that are relevant to the job you’re interviewing for.

So yeah, this is about the STAR technique. I hope this makes sense. My audio audio is still clear.

And now with that, let’s move on to the next thing. So you were you introduced yourself well, you crack the technical part, you set up a set up the problem, you communicate well and you also use star technique to you know to talk to the to talk to the interviewer to talk them through your behavioral questions. Now what you need to remember is your you should end your interview with a bang as well.

Remember again once again communication is key. Communicating your thought process is paramount. So always keep on doing that.

There is no such thing as overcommunication during the interview. So if at the end of the session there’s one thing you take away. Take away that communication is the key.

Now the second thing to remember is your recruiter is is your resource. They are there for you. They are there to help you succeed.

So anytime when you need special accommodations, let them know. And if you have any questions, let them know and they will be there to help you. Also remember, I know Lindsay mentioned this, I mentioned this as well, interviewing should seem like a two-way street.

It shouldn’t feel that one you are being questioned or you are being interrogated. It should feel like an, you know, it should feel like a conversation. So, try your best to do that.

I know at first it does feel awkward, but as you practice, you get better. And trust me, it should feel like a conversation. And the last one is showing gratitude is also very personal and very important.

So we recommend that you send up a follow-up email sharing a nice idea sharing what you learned from the interviewer sharing like just saying thank you for their time. It just makes you look at this in a positive manner and also for the interviewer and the interviewing company it’s like someone is expressing gratitude. So they also feel very good about the whole process.

So remember that you have to end your interviews well as well. Now let’s jump on to the next thing. So how do you get better at this?

I know when Lindsay asked people were saying interviews seem stressful, people feel tense and trust me it is the same way with me as well. I’m 8 years experience. Anytime if I have to interview I feel the same.

But like how do I get better? How do I you know become a master of cracking interviews? The answer is practice.

You have to give a lot of ma mock interviews. And so how do you do that? First make a plan.

Find your friends, find a neighbor and schedule time for your mock interviews. Then what you do is for every mock interview, go prepared with at least one to two questions which cover both technical and behavioral aspect of your interview. And do a lot of practice.

And now here’s the third thing and the most important part. Record your progress. See, giving mock interviews is one thing, but learning from them, taking away chunks where you performed well, what is it that you can improve upon is very very important.

So after every mock interview, take a few minutes, you know, just think about what went well, what are my strengths, what am I missing, what I need to work on. And in the next mock interview, focus on things to get things you want to work better at, things you want to get better at. So record your progress and then use them to you know get better in your next interviews.

Now let’s move to the next part which is troubleshooting. So even though like you know these situations may not occur, I think we still feel that it is good to talk about this so that you know what to expect when you get into your interviews. The first one is if your interview asks you a question which is very like something that you haven’t heard of before or sorry if your interview asks you a question that you previously have heard before or a previous interview has already asked you that question then openly tell tell it to them mention them hey I have already been asked this in the previous interview you know why you should do it you should do it because when when company interviews you they are actually gathering data points to learn more about you and to assess whether you are a best candidate or not.

So from your side, it is your responsibility that you give them like lot of data points. But if you’re if they are asking you the same question again and again and if you’re answering the same question again and again, you’re not really giving them any extra data points. So that is why if you enter encounter a question that you’ve already heard before, make the interviewer know and they’ll ask you a different question.

Second, if you get asked a question that you don’t know, just let the interviewer know that this concepts have not been covered in your coursework and they’ll ask you a different question. Now, number three, if you are asked a design question, if you are early out, let’s say you are a first, second year student, if you’re interviewing for an internship, generally design questions are not something that you’ll encounter. Design questions are more common for senior engineering roles, for senior interviews.

So that is when you know you will encounter design questions. What you do in this case is have a very open conversation with your recruiter and let them know that let let them know what to to share with you what to expect in your interviews. If design is something that they’ve mentioned that then you will know that you need to prep for it.

If they don’t mention design then you don’t need to spend time on the design aspect of the questions. And number four, if your interviewer is late, if they are rude, if you hear something unexpected in the interviews, always let your recruiter know. Sometimes, you know, you get asked questions that just you feel like bonkers.

You don’t understand the question. Let your recruiter know that you encountered that. So, here’s one example.

Google does not ask brain teaser questions. So in case if you’re in an interview with Google and if you get asked a brain teaser question you should bring this up with your interviewer and you should recruit her and you should let them know in most of the cases if you have like a unpleasant experience the companies try to give you another interview round where you are able to go through the interview again. So these are a few troubleshooting tips to keep in mind as you proceed with your interviews.

With that, I think that’s pretty much like we are getting to the end of it. Lindsay and I would love that if you could, you know, scan this code, take the survey and give us feedback on how you found this particular session. Also, if you complete the survey, you will get into our database and you get you may get an invite to the career exploration day that will happen with Google.

So, like be sure that you fill the survey out for sure. So, I’m going to pause for like a few seconds to ensure like most of you go grab the survey and give us some feedback. It looks like there might be a problem with the QR code.

So we can follow up on another way to provide feedback afterwards. Thanks. Perfect.

Okay, let’s move on to the next thing. So I know folks, we shared a lot of information with you. Now I would love to hear from you in the chat.

What was your biggest takeaway? Like I know I said communication so I hope I drove the message home but like what was your biggest takeaway and what are the areas of growth that you identified for yourself through this session? Let me know in the chat.

Yes, you learned that. Let your interviewer know when you’re not familiar with concepts. Interviews are not a oneperson thing.

Yes. Awesome. Troubleshoot.

Yes. Yes. Learn, be effective, follow up, show gratitude.

Awesome. Awesome folks. I see so many great things that you folks took away from this session.

Now, I know I had shared with you that we’ll be sharing with you the interview workbook. I’m pretty sure that link works because I tried it out before this session. So, go ahead, scan that code.

If that code doesn’t work, go to that link and get your interview workbook. This workbook has very helpful tips that you can use to prepare for coding and also for your mock interview. So, be sure you grab this particular workbook.

Okay. And with that, I think that’s pretty much it, folks. That’s pretty much it from our side.

Lindsay, I think maybe we can take take up Q&A. Does that sound good? Yeah, sounds great.

Thank you. All right. Are you ready for the Q&A?

You guys ready? All right. Perfect.

All right. What are some good questions to ask the interviewers at the end of the interview? So I can start with this one.

Great question, Yara. So this is an opportunity for you to learn more about the role that you might be interviewing for. You might want to ask the interviewer like, oh, what does the day-to-day look like for you?

What kind of technologies or things are you working on? What is the team like? Any questions about the team and the dynamics with the people on it?

What kind of opportunities there might be or any more details about what specific projects or what specific work you might be working on. I think especially at larger companies sometimes things are very broad and this is your opportunity to learn more about the specific role you might be interviewing for. Yep.

100% Lindsay. All right. Is it possible for a candidate to not get the solution for a problem but do everything else right and still pass?

I I can take a stab at it Lindsay. So ideally ideally solution is what the interviewers are looking for. However it depends.

So let’s say if it’s an internship and maybe it is not a very coding intensive role. Maybe the role is a data analyst role. If you’re at least able to articulate your approach well, you’re able to show them that this is these are the five steps, you’re able to write the pseudo code well, and if you’re able to show them the approach, there are chances that you might pass, but I would say that you you should aim to get to a place where you are able to successfully show them a piece of code that works.

But it it depends. You may get a pass at it, but aim for aim to get the code correct. Lindsay, anything you would like to add?

Yeah, I think to add on to what Sinoxi said, often these questions have many different possible solutions and some may be more optimal optimal than others. So candidates often get to different points in that and also sometimes you may be asked a very hard question where it’s not even really expected that the candidate may get to a completely optimal solution and maybe just getting some kind of brute force thing is enough. So, it does depend on the question and also like with a company like Google, if we have an on-site interview day where a candidate has multiple interviews all in the same day and they maybe do poorly on like one of them or something, if there’s enough other signal that the candidate did really well in these other interviews, they could definitely still be considered.

So basically try your best and be confident because you guys are cop students and you know what you’re doing. All right, next question. Google send autoon online assessments to everyone or select individuals.

I’m not a recruiter so I don’t know. Yeah we we are not sure actually what I have seen I’m just sharing my experience again I’m not sure about this you get a online assessment when you are kind of shortlisted by the recruiter so if you if you’re seeing that assessment I don’t think everyone gets it a few select folks get it but this information needs to be reconfirmed so check with your recruiter for sure yeah you can stop by the booth and check and ask the question because the recruiters will be in the booth. What are some common mistakes candidates make during technical interviews and how can they be avoided?

I think one common mistake I see sometimes is candidates jumping right into coding immediately before they’ve really clarified the question. Thought about potential edge cases, talked about what they’re coding and how they might solve it. Because your interviewer doesn’t really know what you’re doing and he also might be going down the wrong track.

Where it’s better to talk about this talk about your approach and how you might solve it beforehand. All right. How is the Google interview process different from other tech companies?

That’s a good question. I would say it’s generally somewhat similar. Obviously we have our own specific questions that we might ask.

But I think there is a lot of overlap for sure. Sakshi would you like to add anything to that? No, I think it is pretty standard as you said Lindsay.

I’m just trying to remember what was different about Google when I interviewed for it. And there’s one thing that stood out to me for Google interviews that I went through and that was that when I was talking to my interviewers and when I was asking them questions, I saw so much passion that they had working for Google. They shared their actual experiences with me and they shared why they are so excited about what they do in their day-to-day and about the company and the culture the whole company culture.

So I think what was different was I felt people were very kind. They were very open to sharing their experiences and that is something that stood out to me during the interview processes. But I mean the technical interviews number of rounds wise it is pretty standard.

Okay. So, I have the best next follow-up question to that answer. Can you share any memorable experiences or stories from your own interviews or career at Google?

I I can start and I’d like to say don’t get discouraged if you might not get the offer you want right away because I actually interviewed for an internship every single year at Google when I was in university. But I never got an internship, but then later was able to keep keep practicing skills and then get an offer for full-time after college. So, don’t be unmotivated if things don’t work out right away.

Keep trying and improving and learning from those mistakes and you can get there in the future. So, that was a memorable experience from my interview past. Now I have the similar experience.

I never got into Google in my first try. I got here the second time trying to get into Google. So yeah, plus one to what Lindsay said like keep trying, don’t give up and it is a process.

So you have to be very patient and like go go for it, keep practicing and you’ll I’m sure you’ll get there. I don’t know. The Google team is on it today because my next question just back piggybacks on your answers.

What would you suggest to students getting rejections after interviews? And do you have any tips on how to best reapply to the company the following recruiting season? Yeah, I think we covered this a bit, but I would say definitely be sure to continue learning, continue pushing yourself.

Ideally you can show some kind of delta of what you’ve learned or achieved in the past year. Whether that’s more classes you took, other work experience at other companies, different clubs or things you did to push yourself, learn more and be better prepared for not better but more learn more and be ready for this next round as well. I will share one quick tip with you folks.

When you get rejected, so every anytime you get rejected in an interview, take a step back and reflect on what is it that went wrong. A lot of times what I like to do is after the interview, I create notes and I write down all the questions that were asked and also like try to remember what I answered and what I can improve upon my answers. And then a lot of times I’ve realized okay maybe I didn’t really answer this question that well but that will only happen after the interview when you reflect on what was asked.

So create like a rejection notebook and or like after interview notebook write down all the questions and next time when you go to a new interview ensure that if if you get the same question you like nail it down. So like do that every time you get rejected. And other than that, I mean to what Lindsay said, like you have to practice, you have to get better.

And trust me folks, you get better with time. You get better at failing and then eventually you succeed. So don’t be afraid of failure.

Be proud and be happy. Okay, I failed three interviews. What the hell?

I learned from three interviews and I’ll pass the fourth one. So, yep. Let’s normalize rejection.

Yes. Normalize rejection. Normalize rejection for sure.

Yeah. I love that and I love the rejection notebook. That’s great.

I think every student here should have one of those. All right. Is asking too many questions during interviews considered as a concern?

So asking questions to understand the problem is totally fine and like I mean I would advise ask ask questions until you understand the understand what the interviewer is looking for and you understand the problem correctly and generally all the interview all the interviews will give you time slot towards the end to voice out your questions as well. So I mean if there are questions about the company, about the team, about the work, about the position, I will say park them towards the end of the interview. You can also set up a separate call.

If you feel those questions are not answered during the interview, let the recruiter know and like set up a separate clarifying call. But during the interview, I would say keep the questions limited because it you have limited time. You just have like 30 45 minutes to get the interview done and if you ask too many questions you may derail it.

So my advice is ask questions but don’t ask too many questions. Yeah I think also in the technical portion of the interview it’s definitely normal to ask a lot of clarifying questions and solidify your understanding. I think if you also ask too much to the point where the interviewer feels like you’re asking them for the answer and if they answered your question, they would just be doing your interview for you, they will they’ll usually say so.

And they would just say, "Oh, I don’t think I can answer that." Awesome. All right, ladies. We’ve come to the end of our time.

Do you have any final thoughts you want to share with students? Thank you so much all for attending. I hope this session was valuable for you.

We yeah we appreciate your time so much. Thank you. Yeah, thank you for bearing with me with my audio issues.

I appreciate all of you sticking with us towards the end. And I think one final takeaway is like don’t be scared about the interviews. Be excited about them.

Go in charged up, fire up with all your energy. Be authentic and just give your best and don’t be afraid to fail folks. It’s okay to fail interviews and it is important to learn from your failures.

So yeah, I mean I we wish like good luck to all of you through your like starting your careers and with all your interviews. Awesome. Thank you so much to the Google team.

This was really really an amazing presentation. You dropped so many nuggets about interviews and how to prepare and we really appreciate it. We encourage all students to go visit the Google booth during booth time and take a minute to talk to those recruiters.

To close out, we’ll now have a brief video from our host, Bobby Deep. Thank you for joining us in this session. I got some information before you leave.

It says, "Please take a moment to complete a brief survey to share your feedback. Remember how valuable feedback is. I’m trying to come back three years in a row and it’s all based on feedback, right?

To see what comes up next. I want you to head back to the main stage and check out the schedule. See you soon in the next set of sessions.