Work at Google: How to Communicate in Technical Interviews & What to do When You're Stumped
Summary
TLDRIn 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
π 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.
π 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.
π€ 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.
π 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.
π« 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.
π§ 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.
π 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.
Mindmap
Keywords
π‘Software Engineer
π‘Google Assistant
π‘Recruiting Process
π‘Coding Sample
π‘Phone Interviews
π‘On-site Interviews
π‘Interview Committee
π‘Edge Cases
π‘Algorithmic Complexity
π‘Technical Interview
π‘Communication Skills
π‘Whiteboard Coding
π‘Optimized Solution
π‘Data Structures
π‘Interviewer's Role
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.
Browse More Related Video
How to Start Leetcode (as a beginner)
I solved 541 Leetcode problems. But you need only 150.
How to prepare for Machine Coding Rounds? | Tips from Ex-@Google SWE
Is Grinding LeetCode Worth It?
How did she crack Meta Software Engineer Role | Londonπ¦πΊ | Garima Rajput
How to standout in a DSA Interview ? | Important tips to crack DSA Assessment Rounds | @SCALER
5.0 / 5 (0 votes)