You've done it. You've landed
an on-site interview with Google. Congratulations! My fellow Googlers and I
would like to share our tips and advice on how to best prepare. In this video,
we will cover communication, designing with scale in mind, concrete and quantitative solutions,
how you manage trade-offs and compromises, and overall best practices. But before we jump into
the core focus areas of this interview, here are a few things to note. You will not be coding in this interview. There will also be
significant time constraints. We'll expect you to gather requirements
and to develop an initial solution in the first 20 minutes. So please be sure
to use your time wisely. Communication is incredibly important
in the work we do at Google. And that's because it's key
to how we approach developing and building our products. In your interview, it's important
to demonstrate those qualities. Understanding a problem
and designing a solution are both valuable parts
of the interview process. We want you to think out loud. We don't just want
to see the final answer. We want to understand
how you arrived at it. Google is a collaborative workplace where projects are planned
and executed by teams. Those teams have
a mission to work together to solve big, often ambiguous problems. And those problems
can have multiple valid solutions. So, tell us how you plan
to solve those problems, and be sure to ask questions. And remember, we're not
looking for one specific answer. The problem you will
solve during your interview will be deliberately underspecified. We leave those questions
open-ended because real problems require you to dig deeper. You will need to ask clarifying questions. At Google, we deal with planet-scale data
and compute systems every day. Our applications serve
a global user base. Simply identifying a solution
is just the beginning. A solution must be scalable
enough to reach a wide audience, reliable enough
to meet our users' needs, and still make efficient use
of our resources. During this interview, we'll be
assessing you on your ability to design systems that scale. Questions you may
want to keep in mind include: How can we tell that
the system is working? Is there a bottleneck in the design? If there are multiple components,
what are the APIs and how do they work together? How can we provide great service
to users all around the planet? And long gone are the days
when everything you design could easily fit onto a single machine. So, we may give you
a large data set to work with and ask you to explain how it can be
sharded among multiple worker machines. Or we may present you with
a request which can be answered by any one of a pool of machines and ask you to identify the fastest
machine and discard the rest. You should also be prepared
to discuss system component properties such as latency, throughput, and storage. We want to see numeric
estimates for these properties, such as how many requests
per second the system can handle. Also be prepared
to provide clear justification of how the design
backs up these numbers. Our systems impact
users across the globe. We need engineers who can solve real world
problems concretely and quantitatively. So when designing, you should always
consider reality and the laws of physics. You should also have a general idea
of the costs and latencies of various operations such as:
read from disk, read from memory, local area network round-trip,
and cross-continental network. During your interview,
you will have access to a whiteboard. You can use this to estimate
the resources needed to run your system or to diagram your proposed design. You should know industry solution patterns
like sharding data, replication types, write-ahead logging,
separating data and metadata storage, and basic kinds of load distribution. As a systems designer at Google, you will have to make
trade-offs and compromises. In your interview, we'll ask you
to identify systematic shortcomings and describe how the system
responds to various failures. We want you to lay out
the trade-offs and compromises you made and explain your reasoning. Do you store data on a rotating disk
and pay less money for the storage at the cost
of increased latency? Or do you put the data on a flash drive where you're able to retrieve it quickly
but pay more money? These are questions that could
come up during your interview. We're looking for systems designers
that can consider multiple solutions, commit to one, and then iterate on it. Now that you have the focus areas, here are some overall
best practices to keep in mind for your actual interview day. We want to understand how you think, so it's important to explain your
thought process during the interview. We're not only evaluating
your technical ability but also how you solve problems. Many questions will be deliberately
open-ended to give us an idea of how you solve technical problems. We encourage you
to ask for clarification. And we all know that our first solution
may not be the best one. So, once you've come up
with an answer to a question, think about ways to improve upon it
and let your interviewer know what you're thinking. And lastly, practice
on paper or a whiteboard. During the interview, you may not have
access to resources you normally use. And those are our tips to help you prepare
for a systems design interview at Google! If you have any questions
about your upcoming interview, you can always reach out
to your recruiter. We're here to help. And we look forward to seeing you at one
of our offices around the world soon.
