Work at Google: How to Communicate in Technical Interviews & What to do When You're Stumped

Summary

In this YouTube session, Google software engineers discuss the interview process for full-time candidates, covering steps like coding samples, phone interviews, and on-site interviews. They emphasize the importance of clear communication, understanding the problem, and demonstrating thought processes. Tips for phone interviews and handling being stuck are also provided, aiming to make the process less intimidating.

Takeaways

• 😀 The interview process at Google involves an initial coding sample and survey, followed by phone interviews and an on-site interview day with multiple 45-minute interviews.
• 🔍 The purpose of the coding sample is to demonstrate the ability to write good code without using outside resources within a time constraint.
• 📝 Phone interviews are conducted using a Google Doc to write code, which tests the candidate's coding skills in a basic text environment.
• 🤝 On-site interviews are a mix of technical and behavioral assessments, aiming to understand the candidate's capabilities and fit within the team.
• 💡 It's important to communicate effectively during the interview, starting with a naive solution to a problem and then discussing optimizations.
• 🔑 Discussing edge cases early in the interview shows maturity and understanding of robust code writing.
• 📚 The interviewers are looking for fundamental programming concepts, appropriate data structures, and language proficiency.
• 👀 Reading and writing clear and concise code is crucial; the code should be easy for the interviewer to understand at a glance.
• ✅ The interview's main goal is to have working code by the end, with the interviewer guiding the candidate to a solution.
• 🗣️ Practice and preparation are key, with resources like 'Cracking the Coding Interview' and online platforms like TopCoder for mock problems.
• 🧠 It's okay to not know everything; interviewers are interested in how candidates handle unknowns and work through problems.

Q & A

What is the first step in the Google interview process for full-time candidates?

The first step is to complete a coding sample and survey. This is an online task where candidates need to write good code within about an hour without using outside resources.

How many phone interviews can a candidate expect during the Google interview process?

Candidates can expect to have a couple of phone interviews, usually two, maybe three. These interviews are conducted over a Google Doc where candidates write code.

What is the purpose of the on-site interviews at Google?

The on-site interviews are conducted over the course of a day with about three to four interviews, each about 45 minutes in length. The purpose is to get a well-rounded understanding of the candidate as an individual and a professional.

How should candidates approach problem-solving during the interview?

Candidates should start by giving the naive solution first to demonstrate their understanding of the problem. They should also discuss edge cases and then methodically talk about different ways to solve the problem.

Why is it important for candidates to communicate effectively during the interview?

Effective communication is crucial as it helps the interviewer understand the candidate's thought process, approach to problem-solving, and ability to present themselves clearly, which are all important skills in a team environment.

What are some tips for candidates during phone interviews?

Candidates should use a readable font like Courier New, reduce the font size, turn off spell-check and autocorrect, ensure they are in a quiet room with a reliable Wi-Fi connection, and use a headset if possible.

How can candidates prepare for the on-site interviews at Google?

Candidates can prepare by practicing coding on a whiteboard, ensuring their code is modular and easy to read, and understanding the fundamental programming concepts and appropriate algorithms for different problems.

What is the role of the interview committee in the hiring process at Google?

The interview committee reviews all the information from the interviews and decides whether or not to hire a candidate and at which level, based on a comprehensive assessment of their skills and performance.

How should candidates handle situations where they are unsure or stuck during the interview?

Candidates should be honest about their uncertainty, ask for clarification, and walk through their thought process. Interviewers are there to help and may provide hints or explanations to guide the candidate.

What resources are recommended for candidates preparing for a technical interview at Google?

Candidates are recommended to use resources like 'Cracking the Coding Interview' book, TopCoder, and Google's own resources such as videos on the Google Students YouTube channel.

Outlines

00:00

👋 Introduction to the YouTube Session

The session begins with Pierre St Juste, Jonathan Drake, and Lauren Long introducing themselves as software engineers at Google with varying tenures and roles. They explain the purpose of the session is to share insights on the Google recruiting process, including their experiences with interviews and recruiting events. The audience is encouraged to engage in the chat and ask questions, emphasizing the interactive nature of the session.

05:01

📝 Overview of the Google Interview Process

Jonathan Drake outlines the Google interview process for full-time candidates, starting with a coding sample and survey, followed by phone interviews using Google Docs, and culminating in on-site interviews at a Google office. He emphasizes the independence of each interview and the committee review process that follows. Lauren Long adds that communication during the interview is crucial, and Pierre St Juste discusses the importance of problem analysis and addressing edge cases.

10:03

🤔 Navigating Technical Problem-Solving in Interviews

Pierre St Juste provides strategies for approaching technical problems in interviews, such as starting with a naive solution and discussing edge cases. He stresses the importance of understanding fundamental programming concepts, appropriate data structures, and algorithmic complexity. The interviewer's role is to guide the candidate to a working solution, and code readability is highlighted as a key factor. Additionally, reiterating the problem-solving approach after 10 minutes is recommended to ensure clarity.

15:07

📞 Tips for Successful Phone Interviews

Lauren Long offers advice for phone interviews, such as using a readable font in Google Docs, turning off spell-check and autocorrect, and preparing a calm environment with tea or water to maintain a smooth voice. She also suggests using a headset to free up hands and emphasizes the importance of thinking out loud and communicating clearly with the interviewer due to the lack of visual cues.

20:08

🚫 Avoiding Common Pitfalls During Interviews

Jonathan Drake advises against jumping straight into coding and instead taking time to ask clarifying questions, consider edge cases, and articulate a plan to the interviewer. He encourages candidates to write real code that could nearly compile, rather than pseudo code, and to avoid forcing solutions or prematurely optimizing. Pierre St Juste adds that it's better to draw from past experiences than to memorize and reuse specific solutions.

25:09

🧠 Handling Challenges and Uncertainty in Interviews

The speakers discuss how to handle being stumped during an interview, emphasizing that it's normal and providing examples of how they've overcome similar situations. They suggest walking through one's thought process, being open to learning new data structures during the interview, and maintaining a calm demeanor. The interviewers' goal is to help candidates succeed, so asking for hints is acceptable.

30:11

📚 Recommended Resources for Interview Preparation

Pierre St Juste recommends 'Cracking the Coding Interview' as a comprehensive resource to alleviate anxiety and build a foundation for the interview. He also mentions online platforms like TopCoder and Decode for practice. The importance of daily practice is highlighted, along with the goal of increasing familiarity with problem-solving.

🤝 Addressing Questions on Coding Versus Other Abilities

The panel discusses the balance between coding abilities and other skills valued by Google, such as communication. They emphasize that while coding is a significant part of the job, the ability to convey thoughts clearly and work within a team is equally important. The interview process aims to assess these skills alongside technical proficiency.

🔍 Dealing with the Pressure of On-Site Interviews

Lauren Long acknowledges the intensity of having five interviews in one day and provides tips to manage the experience. She suggests taking advantage of the lunch break to relax, staying hydrated, and ensuring a good night's sleep before the interview day. The lunch interview is a non-evaluative opportunity to learn more about the company or to rest.

📖 Examples of Code Activities in Google Interviews

Jonathan Drake confirms that there are many examples of Google interview questions available, both on the YouTube channel and through a simple web search. He mentions that while some questions may no longer be used in interviews, they still provide insight into the types of problems and the scope that candidates might encounter.

😅 The Challenge of the First Five Minutes in an Interview

Pierre St Juste identifies the initial five minutes of an interview as the most challenging due to anxiety and the pressure to perform immediately. He advises candidates to push past this mental hurdle by establishing a naive solution as a starting point for further optimization and discussion with the interviewer.

🖋 Tips for Coding on a Whiteboard

Lauren Long points out the difficulty of transitioning from coding on a computer to coding on a whiteboard and offers tips for effective whiteboarding. She recommends practicing on paper to ensure legibility, proper indentation, and syntax without the aid of a text editor, which is crucial for clear communication during interviews.

🛠 Acceptability of Non-Optimized Solutions

The panel agrees that while having an optimized solution is ideal, it is acceptable to present a working solution that may not be the most efficient, as long as it is somewhat efficient. The focus is on the thought process and the foundational computer science concepts applied to arrive at the solution.

🌟 Adapting to Unknown Data Structures During Interviews

Pierre St Juste shares his experience of being unfamiliar with a data structure during an interview and how he was able to adapt by asking the interviewer for clarification. He suggests that candidates should not be discouraged by unknown data structures and should instead focus on understanding their properties and incorporating them into their solutions.

📝 Evaluating Coding Quality in Interviews

Lauren Long discusses the importance of coding quality during interviews, emphasizing that while minor syntax errors are overlooked, the structure, modularity, variable naming, and appropriate use of algorithms are evaluated. She advises practicing writing code on a whiteboard to ensure it is readable and well-organized.

🤔 Number of Questions in Each Interview

Jonathan Drake explains that the number of questions in each interview varies and depends on how the interview is structured. He describes scenarios where one complex question might evolve into multiple parts or where several short, independent questions might be asked, highlighting the flexibility of the interview process.

📌 Final Tips for Interview Success

The panelists offer final advice for interviewees, focusing on communication, establishing a naive solution early, and leveraging the interviewer's help. They stress the importance of staying calm, moving on from any missteps in previous interviews, and understanding that interviewers are there to assist in finding a solution.

Keywords

💡Software Engineer

A software engineer is a professional who applies the principles of software engineering to the design, development, maintenance, testing, and evaluation of computer software. In the video, Pierre St Juste, Jonathan Drake, and Lauren Long all identify themselves as software engineers at Google, emphasizing the role's importance in creating and improving Google's various technologies, such as Google Assistant and search ranking.

💡Google Assistant

Google Assistant is a virtual assistant developed by Google that is capable of interacting with users through voice commands and providing information, managing tasks, and controlling smart home devices. Pierre St Juste mentions working on Google Assistant for Android, highlighting its function in responding to voice queries like 'OK, Google, what time is it'.

💡Recruiting Process

The recruiting process refers to the steps an organization takes to attract, screen, and hire suitable candidates for job positions. Jonathan Drake discusses his involvement in university recruiting and conducting interviews, indicating the structured approach Google takes to identify and select potential employees.

💡Coding Sample

A coding sample is a piece of code written by a candidate to demonstrate their programming skills as part of a job application, often used in technical roles. Jonathan Drake explains that the first step in Google's interview process is for candidates to complete a coding sample to showcase their ability to write good code within a given time frame without external resources.

💡Phone Interviews

Phone interviews are preliminary interviews conducted over the phone to screen candidates before they proceed to in-person interviews. The script mentions that after a successful coding sample, candidates go through phone interviews where they write code in a Google Doc, illustrating the early stages of Google's remote interviewing process.

💡On-site Interviews

On-site interviews are conducted at the company's premises and often involve multiple interviews with different team members. Jonathan Drake describes the on-site interview experience at Google, which includes a series of 3 to 4 interviews throughout the day, each lasting about 45 minutes, to assess a candidate's skills and fit for the company.

💡Interview Committee

An interview committee is a group of individuals who review and evaluate candidates' interview performances to make hiring decisions. The script mentions that after the on-site interviews, the candidate's information is reviewed by a separate group of people, the interview committee, who decide whether to extend an offer and at what level.

💡Edge Cases

Edge cases are the extreme or unusual scenarios in software testing that determine the robustness of the program. Pierre St Juste emphasizes the importance of discussing edge cases during an interview, as it demonstrates a candidate's maturity and thoroughness in writing code that can handle various input scenarios.

💡Algorithmic Complexity

Algorithmic complexity refers to the amount of time and space resources an algorithm needs to complete, often expressed in terms of input size. Pierre St Juste mentions the importance of understanding algorithmic complexity during interviews, as it reflects a candidate's grasp of fundamental programming concepts and their ability to write efficient code.

💡Technical Interview

A technical interview is a type of interview that assesses a candidate's technical knowledge and problem-solving skills, often required for positions in software development or engineering. The video script provides various insights and tips on how to prepare for and excel in a technical interview, particularly for a software engineering role at Google.

💡Communication Skills

Communication skills are the ability to effectively convey information and ideas to others. Pierre St Juste highlights that, in addition to coding skills, Google values a candidate's communication skills during the interview process, as it is crucial for team collaboration and task execution.

💡Whiteboard Coding

Whiteboard coding is the practice of writing code on a whiteboard during an interview to demonstrate problem-solving skills without the aid of a computer. Lauren Long suggests practicing whiteboard coding to get comfortable with writing legibly and following syntax without the assistance of a text editor.

💡Optimized Solution

An optimized solution in programming refers to a solution that is efficient in terms of time and space complexity. Pierre St Juste clarifies that while interviewers are interested in a candidate's thought process towards an optimized solution, they are not necessarily looking for the most optimized solution but rather a demonstration of foundational computer science concepts.

💡Data Structures

Data structures are specialized formats for organizing, processing, retrieving, and storing data. The script discusses the importance of understanding various data structures like hash maps, sets, and prefix trees in coding interviews, as they are fundamental to creating efficient algorithms.

💡Interviewer's Role

The role of an interviewer in the context of the video is not only to assess the candidate's skills but also to guide and help them arrive at a solution. Pierre St Juste and Jonathan Drake both mention that interviewers at Google are there to assist candidates and encourage them to ask for hints if needed.

Highlights

Pierre St Juste introduces himself as a software engineer at Google and his role in Google Assistant for Android.

Jonathan Drake shares his experience as a software engineer on the search ranking team and his involvement in university recruiting.

Lauren Long discusses her role as a software engineer on Firebase and her recent experience with the recruiting process.

The interview process at Google involves an initial coding sample and survey, followed by phone interviews and an on-site interview day.

Phone interviews are conducted over Google Docs, emphasizing the importance of clear communication and coding within the platform's limitations.

On-site interviews consist of multiple 45-minute sessions with breaks in between for questions and interaction.

Interviews are designed to be independent, allowing for a well-rounded understanding of the candidate's abilities.

Candidates are encouraged to demonstrate problem-solving by first providing a naive solution and discussing edge cases.

Interviewers assess fundamental programming concepts, data structures, algorithmic complexity, and language proficiency.

Code readability is crucial, with a preference for concise and maintainable solutions.

Interviewers provide guidance to help candidates develop working solutions during the interview.

Candidates should reiterate their approach and progress regularly to ensure the interviewer follows their thought process.

Google Students YouTube channel offers resources like 'How to Ace the Technical Interview' to prepare for interviews.

Tips for phone interviews include using a readable font, disabling autocorrect, and ensuring a quiet environment.

Candidates should think out loud, use comments effectively, and communicate their thought process clearly during interviews.

Interviewers prefer real code that could nearly compile over pseudo code, except for initial algorithm explanations.

Candidates should avoid trying to force-fit memorized solutions to interview questions.

Interviewers value a candidate's ability to learn and apply new concepts during the interview.

Candidates are encouraged to ask for hints and leverage the interviewer's help to reach a solution.

The interview committee reviews all interview feedback to make hiring decisions, emphasizing the importance of diverse opinions.

Final tips include communicating effectively, starting with a naive solution, and staying calm throughout the process.

Transcripts

PIERRE ST JUSTE: All right.

Welcome, everyone to our YouTube session.

First thing, please go to the RSVP link

and fill out the form.

If you are watching a recording, you

don't need to worry about that, just sit

back and enjoy the show.

And we have a chat.

Make sure you go and engage in the chat.

We have chat moderators which will answer your questions,

and want this to be as interactive as possible.

So feel free to use the chat as we go.

So I am Pierre St Juste.

I am a software engineer at Google.

I've been at Google for about a year and a half.

I work on the Google Assistant for Android.

So if you have a pixel phone and you say,

OK, Google, what time is it, I help make that happen.

And I am here because I do a lot of recruiting events.

I've been to different schools, I do a lot of interviews,

and I'm really excited about sharing

of my wisdom about the process.

JONATHAN DRAKE: Yeah.

Hi, my name is Jonathan Drake.

I'm also a software engineer, and I work

on the search ranking team.

I'm also involved in university recruiting

and been at Google for a little over two and a half years.

And for a lot of that, I've been doing about one interview

a week, interviewing new candidates,

and I think this will be my week of my 50th interview.

LAUREN LONG: What?

So hey, everyone.

My name is Lauren Long, and I'm also a software engineer.

I work on Firebase as the developer product.

I've been in the San Francisco office for eight months now,

so I've recently gone through the recruiting process

and looking forward to talking to you more about that today.

JONATHAN DRAKE: All right.

So I'm going to tell you a little bit about your interview

experience here as a full-time candidate.

So let me just explain the way we have this process set up.

The first step is to complete a coding sample and survey.

Your job is to send us a sample of your writing good, nice

code.

This is an online thing that you'll complete.

I think you have about an hour to do it.

You're not allowed to use outside resources.

The point is just to show us that you can write good code.

And then assuming that goes well,

then you have a couple of phone interviews,

usually two, maybe three.

And these are done over a Google Doc,

and you'll write code in this Google Doc,

fighting a little formatting.

The point is to show us that you know what you mean well enough

to even do it in a Google Doc.

And this will be followed up by coming to a Google office

to do on-site interviews.

So over the course of a day, starting in the morning,

having lunch, going through the afternoon,

you'll have about three to four interviews.

These are each about 45 minutes in length,

and you have a little bit of time

between to ask questions to your interviewers.

It's as much a time for you to get

to know us as it is a time for us to get to know you.

And in that process, I'd say try to have fun.

Each interview is independent, not only from each other,

but from your phone interviews and your coding assessment.

It's all separate.

The idea is to get a bunch of different opinions

to allow no one bad or especially good

experience, either just mess up anything overall.

You want to have a nice, well-rounded understanding

of you as a candidate.

And that's how the on-site process goes.

After that, your interview packet, all this information,

now goes to a separate group of people who review it.

And this committee decides whether or not

to hire you at which level, and hopefully, then

you get your offer after that.

I think that's all for that.

LAUREN LONG: So one thing that we want to address

is how you communicate during this interview.

And you might be doing some practice questions,

you might be learning a lot of technical things,

but you'd also want to focus on ensuring that you communicate

and present yourself effectively during this process.

So Pierre is going to cover that a bit.

PIERRE ST JUSTE: So how do you do this?

The way you do this is we want to see how the candidate

analyzes the problem.

And what this means is one very easy trick

is when you get the question, you

give the naive solution first.

So you said, OK, this is the problem.

One very basic way to do it is to solve it this way.

So that way right out of the gate,

you give the interviewer an understanding

that you see how to approach the problem

and you know how to solve it.

It is also very important to talk about edge cases.

When you talk about edge cases, you're

demonstrating that you have some maturity with writing code.

So are you going to get null inputs, empty strings,

or whatever the different quantifications are,

and that's something you want to handle first.

When you start writing your code, at the very beginning,

you handle your edge cases.

That's very important.

And once again, as you go through the process of first

having the naive approach, then you can start more

methodically, talking about the different ways

you think about the problem to solve the issue.

So we spend a lot of time looking

at making sure you understand the fundamental programming

concepts.

Do you know the right data structures to use,

do you understand algorithmic complexity.

and do you have proficiency in that particular language

that you're using?

The main goal of the interview is

to get you to have working code at the end.

So at the interview, what the interviewer tries

to do is help you along the way, make

sure you have proper comprehension,

and gives you the right guidance to make sure

you have a working solution.

Another piece that's extremely important

is, is the code easy to read?

A lot of the solutions that we're looking for,

in many cases, you can write in about [INAUDIBLE] lines

of code.

And is it something that the interviewer can just

look at and understand.

If the code is getting too complex

and it's hard to either read or maintain,

you have a lot of unnecessary variables and things

like that going on just cluttering the solution,

then that's a sign that maybe you

don't have a clear idea of what the solution could be.

And finally, as you're writing code,

I would say after 10 minutes or so,

make sure you reiterate what you're trying to do.

Make sure you say, OK, this is the overall idea I'm

trying to make, and this is the step that I am

and to make sure that the interviewer is always following

and understand how you're presenting.

So that is very important.

JONATHAN DRAKE: And on the Google Students YouTube channel

here, there's resources out there to help you.

For example, there's a video called Applying to Google,

How to Ace the Technical Interview.

And that's another resource for you

to see how to go about this process

and not be intimidated by it and learn lots of good skills

for doing well.

LAUREN LONG: I want to talk a little bit about the phone

interviews, in particular.

So you might be especially nervous about these being

you're on the phone.

You're not able to see your interviewer.

Here are some tips to ensure that you

make the most of this interview as well.

First is we do use Google Doc for you

to show your code to your interviewer.

So some things you can do before you even hop on the phone

is changing your font to something readable,

Courier New is one that we would recommend.

Reduce the size so that you can fit more code into one screen.

You also want to be turning off spell-check and autocorrect,

so that while you're coding, you're

not getting your variable names corrected

to a different spelling.

So that's very important.

And some things I always like to do before a phone interview is

I like to have a cup of tea and a cup of water nearby.

And that ensures that my voice stays smooth

because I notice when I'm nervous,

I tend to crack at my voice.

So if that happens to you too, you

don't want to be sounding like Darth Vader on the phone.

That won't be making for a very pleasant interview.

experience.

So ensure that you've got what you

need for you to feel relaxed.

You want to ensure that you're in a quiet room.

If you live with roommates, tell them

that you're going on a phone interview.

Make sure you have a reliable Wi-Fi.

Charger your phone.

Charge your computer.

Use a headset, if possible.

I found that was better than holding up the phone

because my hands were free.

So those are just some tips to get you more

comfortable with the setting.

Other things you want to ensure is because you're on the phone,

you're not able to communicate as much by drawing

on the board, for example.

So you want make use of things like commenting within the code

to tell your interviewer exactly what you're doing.

You also want to, just for your own sake,

have some paper and pen nearby, so you can jot down ideas

as you're going forward.

Maybe write down things you want to come back

to remind yourself.

And we have one tip here using copy and paste.

What we mean by that is sometimes

you'll be asked do a solution and then improve on it

for another iteration.

Don't delete the previous solution,

first fall, and don't rewrite it because that takes up time.

You are very welcome to just copy your previous solution

into a new page and improve upon that.

And finally, the most important thing

is to ensure that you are really thinking out

loud and communicating.

If you need a moment to think, make

sure you tell your interviewer because they can't see you

in person and you suddenly go silent on phone,

they might think the connection is cut off.

So make sure you just communicate a lot more than you

would be if you were in person.

JONATHAN DRAKE: Yeah.

And a few more tips, I think, that

are based on situations that you can easily avoid

are when you first walk into the interview

or when you first pick up the phone,

you're going to have a little bit of time

to do an introduction, and then you're probably going

to jump right into a question.

And your instinct might be to jump straight

into just spitting out code.

Try to, instead, take a little bit of time

to ask clarifying questions.

Gather requirements about whatever the problem is.

Think of edge cases.

Think of test cases.

Try to articulate your plan, and get your interviewer's opinion

on it because that way we can prevent you

from going down a path that will lead you nowhere.

We can save you some time.

We can even offer you hints if you give us the opportunity

to do that.

So try to resist that urge to jump straight

into just a quick solution.

That said, it's OK to start with here's a brute-force approach.

I can say that to you in five seconds.

That's great.

But when you get to the part of having a real big algorithm you

want to try and explain, don't start writing it

because we can help you.

We can simplify it, and that will save you a lot of time

and hopefully, make it easier online.

Definitely go through examples at the beginning.

If your interviewer doesn't give you an example,

you should generate one yourself.

Ask them, hey, is this what you mean?

Is this one example representative of all of them,

or could it be much more general?

Is this a reasonable example?

What do you think?

Ask them specific questions about what the problem is

talking about more than you would

asking for just general help.

Ask them something about what they've said.

Repeat what they've said to you in your own words

so that you can make sure you've understood

and they can know that too.

Another thing we like to see is real code in the sense

that it could nearly compile.

I'm not actually going to be mad at you

for missing a semicolon or something, especially

on a Google Doc, but that said, don't write

purely pseudo code, except maybe as an initial explanation

of an algorithm.

There's lots of reasons for this.

One is that at some point, you do actually

have to be able to talk to the computers,

and they need real code.

And so we look for that in our interviews.

That's how we see where your skills are

reflected in an interview.

But beyond that, another reason to write real code

is that you can get away with stuff in real code

that you can't with in pseudo code.

For example, you can say, hey, is it all right

if I have a subroutine that does this functionality?

The interviewer might say, yeah, sure

you can assume you have a method that does that.

And then you can come back to it later,

or if you've run out of time, your interviewer

might say, yeah, I feel like you can finish that.

Let's not even bother flushing out that tiny subroutine.

Real Quick has real advantages, so use it.

PIERRE ST JUSTE: So another thing

that I think people tend to do is

they go and do a bunch of practice questions,

and they try to set the interview

question to a practice question that they've seen before.

So they go and they memorize this particular way

of solving this problem, and they just hope

and pray that they can just reuse what they've done

to that particular solution.

So in many cases, that doesn't work,

that doesn't translate one to one that way.

You definitely need to draw from your previous experiences

of writing code and solving different problems

to understand when to use a hash map,

when to use a set, things like that.

But don't think, OK, this is this exact problem,

therefore, I need to remember this dynamic programming

approach that I coded last night.

So do not try to force fit a solution

that you know very well to that particular problem.

So some people, for example, they study recursion a lot

before the interview.

They study dynamic programming a lot,

or they the study prefix tree a lot or red-black tree.

And they think, OK, whatever question they ask me,

I'm going to throw in the red-black tree.

It's balanced.

[INAUDIBLE]

Let's do it.

I'm in there.

Try not to do that.

Definitely, practice a lot, but whenever you see the problem,

try to have a fresh look at it, and try

to think of different components.

The other thing that people do a lot is they

tend to right at the beginning, they

want to have the most efficient solution.

And a lot of times they try doing this

before they even fully understand

the parameters of the question.

So that's why it's always good to first give the naive

approach to make sure you understand the problem,

and then from that try to think of the different components

of that naive approach and how you can solve it.

So a lot of times, I have to tell interviewees,

can you tell me what the naive approach

would be because they may try to use a prefix tree or one

of these advance data structures or dynamic programming.

And then they would tell me what the naive approach is,

and then I would ask them what was the complexity

of this naive approach.

They would give me the complexity.

Then I ask them, what is the complexity

of this other solution you're trying to propose

that uses dynamic programming.

In many cases, they would say, oh, wow.

Actually, the dynamic programming approach

is less efficient than the brute-force solution.

At that point, then they realize that maybe they're

trying to do the wrong thing.

So definitely, being able to show us

that you can do dynamic programming or recursion

or use prefix trees are important,

but make sure that you don't prematurely try to apply them.

Because in many cases, in many problems they're not necessary.

So just a traditional data structure

is a traditional binary search, maybe heaps,

and other data structures, hash maps,

that can get you a long way.

So definitely, do not feel like you have

to pre-optimize that early.

So now what if you're stumped?

LAUREN LONG: What if you are stuck?

First of all, it happens.

It's happened to me many times as I was interviewing

for companies eight months ago.

It happened while on my Google interviews,

actually, where I was asked to code up a solution as a warm-up

to print a Fibonacci sequence.

And I was so excited to code, I jumped right in.

After I wrote it, the interviewer was very confused.

And then I realized I just coded a factorial.

So that was definitely something I was not supposed to do.

But I took a deep breath, explained that I had wrongly

assumed what I was supposed to do,

clarified my understanding of what a Fibonacci

sequence actually is, proceeded to code it,

and I was, obviously, successful in that interview process.

So that is to say, do you not worry

if you end up going down a wrong path in the beginning

of the interview.

Do not worry if you completely mess up on your interviews.

As we mentioned earlier, your interviews are independent.

So especially when you come on site,

you're going to have five in a day.

Those interviewers do not talk to each other

before they write feedback on you.

So if you really felt like you messed up on one,

just take a deep breath, go into the next one

with a blank slate, and hope to do well on that one.

So that's the most important thing is to keep cool.

Other things that you can do to help you get unstuck

is to walk through what you've do.

So sometimes I find it helpful to just reiterate exactly how I

get there, how I got there.

And part of that talking process sometimes

helps me to see a new direction, or that gives my interviewer

a chance to then jump in and suggest I try something else.

PIERRE ST JUSTE: Yeah, I can add to that too.

I think, for my own personal example of me getting stuck,

when my first interview, when I came on site,

someone gave me a question and the solution required

using a prefix tree.

The person said, have you thought

about using a prefix tree?

And I did not know what a prefix tree was.

I was stuck.

And I said, I am not familiar with this data structure.

I know a bunch of different data structures.

It just so happened I never really used a prefix tree

before.

And the interviewer explained what a prefix tree was.

Because I was comfortable enough with graphs and different graph

and tree-based data structures, once he

explained what the prefix tree was, I was able to get unstuck.

So it's OK if you're exposed to a data structure

that you've never heard of before, because for the most

part, data structures, most of them can be modeled as graphs.

So one thing I do recommend, make

sure you're comfortable with not just doing this linear linked

list or array list type of algorithms, Make Sure?

You're comfortable with graphs.

Depth first search, breadth first search,

if you can understand graphs, many data structures,

once explained to you and you realize is a graph,

you can apply that.

And that's what I was able to do.

And I think I was able to impress the interviewer

because even though I didn't know what a prefix tree was

at the beginning, once he explained it,

I was able to write a solution that used a prefix tree.

So the other thing that's very important

is the fact that by the time your package goes

to the interview committee, you probably

want as many different opinions as possible.

So many six or seven.

By the time you do the final interviews,

it might be six or seven different inputs

and you want them to be as independent as possible

because that gives more breath, a better

scope of your capabilities.

So therefore, if you mess up--

it's when you're taking an exam, there's

only five questions in the exam and then

you don't know one question, that's automatically

you're getting 80%.

If you have 20 questions, damn right,

so I like exams with more questions.

So that's the basic way I would approach.

The more interviews, is actually a good thing.

JONATHAN DRAKE: I would add to that

and say that a difference between quizzes and tests

and interviews is that you're not actually supposed

to know already how to do it.

We're not going to say something like, what

is an array list necessarily.

Hopefully, we're going to give you a problem that you actually

haven't seen before, something you don't quite

know how to do it.

So the prefix tree example is great

because I didn't know what a prefix

tree was until last year.

If I had that interview, I would've been freaking out.

So this is a perfect example of how

you're supposed to be able to--

we'd love to see you able to take something

that you don't know and wrangle that unknown into something

that you do know.

And that's totally what we do every day,

and so that's a wonderful thing to see in an interview.

PIERRE ST JUSTE: So now, in terms of resources,

I highly recommend "Cracking the Cutting Interview."

That textbook, just makes you feel less anxious.

Because you felt like you've gone through this somewhat

comprehensive, was not a very big book,

but it covers all the highlights.

It makes you feel like you have a good foundation

for the interview.

So definitely, just to relieve some anxiety,

just go through the book and skim through it.

If you have time to do all the different questions,

definitely do that.

There are also other guides.

One of them is TopCoder and other different web site,

Decode, where you can create an account

and solve different types of problems.

And once again, the more practice you do, the better.

Before my interview, I practiced almost every day

for about a month just to get in the mode

of solving little things.

LAUREN LONG: All right.

And we're going to jump into answering some questions.

So as a reminder, you have that chat box in front of you.

Feel free to type a question in there.

PIERRE ST JUSTE: OK.

Now, it's question time.

The first question is from Eden Freiner.

The question is, "How does Google value coding abilities

versus other abilities?

Obviously, one needs to know how to code,

does Google care about the one--"

LAUREN LONG: "--the way that one thinks?"

PIERRE ST JUSTE: "--the way that one thinks?"

I thank you for that because everyone thinks differently.

LAUREN LONG: You're stuck.

PIERRE ST JUSTE: I got stuck.

"--and if they do, how do you test different abilities?"

That is a great question.

We do value coding a lot because as a software engineer,

the vast majority of the job is coding.

However, we do value communication skills.

We do value ability to clearly--

so as you communicate with the interviewer

and explain your approach and your ability to understand,

that's something that as an interviewer

we assess your ability to communicate clearly.

Because what we try to do is envision you

in our team and you being given a task

and how you go about addressing that.

So I would say through the interview,

we try to assess, not just your coding skills,

but also communication and things like that.

LAUREN LONG: So we got another question from David.

He says, "I'm nervous about the on-site interviews.

It's five interviews in a day.

Seems kind of overwhelming."

So I agree.

I also thought it was a bit crazy when I first

heard about five interviews in a day,

and there are some tips that I would suggest

for getting through the day.

So first of all, I won't lie.

It is a very long day, but we do put a break in between,

so you will have lunch with what's

called lunch interviewer.

So you'll have a current Google employee pick you up, take you

to one of our cafes.

And this is not evaluated at all.

So that person that has lunch with you

does not write anything up about you.

So take that as an opportunity to get

to know the company, to relax a little bit,

or you can simply say, I don't want to actually say too much

right now.

I want to have a moment of silence,

or I want to take a nap.

My lunch interviewer said, do you want to take a nap?

I can take you to a nap pod.

So that is an option as well if you feel like you need that.

Secondly, hydrate a lot during the day.

So we've got a ton of micro kitchens

all around with coffee, tea, water, all kinds of juices.

So make sure you have those in the room with you at all times

and just sleep a lot the day before.

JONATHAN DRAKE: Yeah.

And I also have a question.

Dana Hickson asks, "Are there some examples

of the types of code activities we will be writing?"

So yes.

There's plenty of examples of interview processes

that show the type of questions we ask even

on this YouTube channel.

You can also basically just Google Google Interviews

and see a bunch of questions that, because they're now

public, we've actually banned from the real interview

process.

With that said, it's still a wonderful way for you

to see the types of questions we ask

and the scope of a question.

There's also books out there.

There's one called "Cracking the Code Interview" or something

like that.

"Cracking the Technical Interview."

LAUREN LONG: Yeah.

It's on the previous slide.

If you re-watch it, it's in your [INAUDIBLE].

JONATHAN DRAKE: Check out those links,

and definitely, there are lots of resources out there.

PIERRE ST JUSTE: So this next question is from Anzel Chris.

"What was the hardest part of the technical interview

to you?"

I would say the hardest part of the technical interview

was probably the first five minutes.

Because you're going to be given a question and you're

just anxious and worried that you may completely blank.

And the other thing that happens is, during that first five

minutes, mentally, you have to get over

that hurdle of thinking, oh, my gosh, I'm completely

going to fail this interview.

So if mentally you're able to get over that hurdle and say,

OK, I've seen the question.

I can think of the naive solution that

gives me a starting point and then I can build upon that.

Once you get a naive solution that you and your interviewer

see eye to eye on, make sure you understand the question,

then you can iterate over that naive solution

and try to find different parts that you can optimize.

So just getting to that step is the most important piece.

LAUREN LONG: Yeah.

And to add on to that, I wouldn't

say this is the hardest part, per see,

but definitely one that takes some practice

is coding on the whiteboard.

Because you're often used to coding on your computer

where there is nice text editors that help

you do a lot of things magically.

So you want to make sure you get comfortable

when you're practicing.

I recommend writing it out on a piece of paper

as if you were writing on a white board and just practice

how you're going to make sure your writing is legible,

how you're going to indent, follow the syntax

without having a text editor in front of you.

JONATHAN DRAKE: And if you do get into a situation where

you're like, oh, my gosh, I can't remember the word

for putting something onto hash set .

Is it add, put, or offer or what is it?

Just say, I can't remember what it is.

I know I would look it up in the Java Doc or in the C++

reference.

I just can't remember what it is.

Explain to your interviewer what you mean,

and that will be 99.9% of the whole thing.

PIERRE ST JUSTE: Yes.

So the next question is from Aiushi.

The question is, "Is it OK to not

have the most optimized solution, but the code works?"

That is perfectly OK.

It doesn't have to be the most optimized,

but it has to be somewhat efficient.

So I think as long as it's not the naive solution, the most

inefficient solution, what the interviewer

looks for is your thought process

to the more optimized solution.

So don't think the interviewer is

looking for one solution, the most highly optimized solution

in order for you to do well on the interview.

It's more about what are the different foundational concepts

of computer science you're using to get

to an optimized solution.

JONATHAN DRAKE: We're not out to trick you.

So also don't assume that because we've asked something

that you feel like you know the answer to that

you need to overthink it.

It could be the answer is fairly straightforward

and that problem will grow into something else.

Maybe we'll change the requirements

to make it a little bit more interesting after you

say the first solution.

It's [INAUDIBLE].

PIERRE ST JUSTE: So the next question

said, "If you haven't used a specific data structure

and you know you have to use it to solve

the problem because you've heard of it before,

how do you proceed to solve the problem?"

This was the typical case that I ran into.

I did not really understand how that data structure was used

and how to--

and I asked the interviewer.

And then they said, well, this is what

the data structure looks like.

It's actually more impressive, to me,

if the person is told what the data structure does

and what it looks like, it has logarithmic inserts

or whatever the case is, and they were able to,

based on me giving them maybe three bullet

points about the data structure, they're

able to incorporate that into their solution.

So you don't have to memorize every single data

structure, like AVL tree.

You don't have to do that.

It's OK.

LAUREN LONG: So we have a question from Ling Siong.

"During the interview, does the interviewer

evaluate an interviewee's coding quality?

For example, it's not too long or too hard to read?"

So you do make a good point.

We do care about how well you code.

That being said, we do not go all knit picky on you.

So we will not care if you forgot a closed a bracket,

you're missing a semicolon.

That doesn't matter, but it does matter

that you structure in a way that is modular, so you break up

long functions, you name your variables well,

not just A, B, C, and that you use

the appropriate algorithms for the problem that is at hand.

Again, I would practice doing this,

writing on the white board, make sure that interviewer

can actually read what you're writing.

That is also going to help to evaluate you.

JONATHAN DRAKE: Yeah.

Martha Corneko asks, "How many questions are

asked during each interview?"

This varies.

How do you measure what's a question?

So sometimes I might ask a question that starts out

as a straight forward thing, and then

I complicate it by saying, well, what

if instead of having only one value per key,

you could have many values per key?

What if you could have duplicates

or what if they weren't sorted?

That could be considered one question that has many parts,

or you could think of it as two or three little questions.

Different interviewers might have different things

they want to do.

You could have three questions that

are each short and self-contained,

or you could have one long one.

PIERRE ST JUSTE: All right.

So I guess some final tips would be one, definitely communicate.

Definitely try to come up with a naive solution as early

as possible just to demonstrate that you

understand the problem.

And [INAUDIBLE].

That's what I think.

JONATHAN DRAKE: I'd say my biggest

tip is show your interviewer how you start with what you know

and transform that into something that you don't know

and then figure out on the course of the interview.

LAUREN LONG: My tidbit is keep your calm.

So like I said, if you screw up one interview,

move on to the next one.

It's OK, and you haven't lost your chances.

PIERRE ST JUSTE: And finally, the interviewers

are trying to help you get to a solution.

We want to see you succeed, and it's OK to ask for small hints.

That's totally versus just trying to figure it

all out by yourself.

So definitely understand how to leverage the interviewer,

and we want to see you have a working solution in the end.

And with that said--

LAUREN LONG: Thanks for tuning in.

PIERRE ST JUSTE: Thanks for tuning in.

Please go to the link and fill out the form.

And yeah, enjoy.

JONATHAN DRAKE: Bye.

PIERRE ST JUSTE: Bye.