Join me to stay up-to-date and get my new articles delivered to your inbox by subscribing here.
Explain – We want to understand how you think, so explain your thought process and decision making throughout the interview. Remember we’re not only evaluating your technical ability, but also how you solve problems. Explicitly state and check assumptions with your interviewer to ensure they are reasonable.
Clarify – Many questions will be deliberately open-ended to provide insight into what categories and information you value within the technological puzzle. We’re looking to see how you engage with the problem and your primary method for solving it. Be sure to talk through your thought process and feel free to ask specific questions if you need clarification.
Improve – Think about ways to improve the solution you present. It’s worthwhile to think out loud about your initial thoughts to a question. In many cases, your first answer may need some refining and further explanation. If necessary, start with the brute force solution and improve on it – just let the interviewer know that’s what you’re doing and why.
Practice – You won’t have access to an IDE or compiler during the interview so practice writing code on paper or a whiteboard. Be sure to test your code and ensure it’s easily readable without bugs. Don’t stress about small syntactical errors like which substring to use for a given method (e.g. start, end or start, length) — just pick one and let your interviewer know.
Beyond the technical preparation, you’ll also be asked questions on leading teams and projects. People management interviews dive into how you would support and grow your teams, covering:
Leadership – Be prepared to show examples of how you’ve resolved complex situations. How did you ensure you dealt with team challenges in a balanced way? You may also be asked some more hypothetical questions, so be prepared to talk through how you would influence, solve problems and drive improvements. How would you take ownership and stay creative while moving quickly?
Working with people & teams – Think about how you develop and retain team members. How would you address a skills gap or personality conflict? How would you ensure your team is diverse and inclusive? How could you spot burn out? How would you organize day to day work activities? How would you convince a team to adopt a new technology?
Googleyness – We also want to make sure this is a place you’ll thrive, so we’ll be looking for signs around your comfort with ambiguity, your bias to action and your collaborative nature. Be prepared to talk about how you would support a team to help them navigate tough challenges and changes. Think about how to effectively lead in a non-hierarchical team environment and what your personal leadership style is.
Applying the right framework – What’s your personal Project Management philosophy? How do you apply your framework to projects you manage? Be prepared to explain and justify your methodology. Be able to discuss and compare different project management methodologies and their relative merits (e.g. tradeoffs between flexibility and process in an agile environment). Why did you use a particular approach?
Navigating complexity and ambiguity – How do you deal with ambiguous situations and problems? How do you handle projects without defined end dates? How would you prioritize multiple projects of varying complexity? How do you balance process versus execution? What are signals that too much or too little process is in place? Can you give examples of projects where you demonstrated leadership even if you weren’t a formal manager?
Delivering results – Give examples of projects where you were the end-to-end owner. How do you evaluate the success or failure of a project? What are some strategies for handling competing visions on how to execute a project? Be prepared to discuss how to use data effectively to move critical decisions forward and how to measure impact.
The STAR method is a structured manner of responding to a behavioral-based interview question by discussing the specific situation, task, action, and result of the situation you are describing. Write out five to seven examples of your successes using the STAR format outlined below. Writing these out before your interview will help you recall all the details and stay on track when you tell your story in the interview, and the STAR approach will help you frame each story you share with a beginning, middle, and end. You can use these stories to answer almost any question in this portion of your interview.
Situation: Describe the situation that you were in or the task that you needed to accomplish. You must describe a specific event or situation, not a generalized description of what you have done in the past. Be sure to give enough detail for the interviewer to understand. This situation can be from a previous job, from a volunteer experience, or any relevant event.
Task: What goal were you working toward?
Action: Describe the actions you took to address the situation with an appropriate amount of detail and keep the focus on YOU. What specific steps did you take and what was your particular contribution? Be careful that you don’t describe what the team or group did when talking about a project, but what you actually did. Use the word “I,” not “we” when describing actions.
Result: Describe the outcome of your actions and don’t be shy about taking credit for your behavior. What happened? How did the event end? What did you accomplish? What did you learn? Make sure your answer contains multiple positive results.
Make sure that you follow all parts of the STAR method. Be as specific as possible at all times, without rambling or including too much information. Oftentimes students have to be prompted to include their results, so try to include that without being asked. Also, eliminate any examples that do not paint you in a positive light. However, keep in mind that some examples that have a negative result (such as “lost the game”) can highlight your strengths in the face of adversity.
Situation (S): Advertising revenue was falling off for my college newspaper, The Review, and large numbers of long-term advertisers were not renewing contracts.
Task (T): My goal was to generate new ideas, materials and incentives that would result in at least a 15% increase in advertisers from the year before.
Action (A): I designed a new promotional packet to go with the rate sheet and compared the benefits of The Review circulation with other ad media in the area. I also set-up a special training session for the account executives with a School of Business Administration professor who discussed competitive selling strategies.
Result (R): We signed contracts with 15 former advertisers for daily ads and five for special supplements. We increased our new advertisers by 20 percent over the same period last year.
Practice using the STAR Method on these common behavioral interviewing questions:
Just like preparing for a tech screen, the most important thing you can do to prepare for your onsite interview is to practice coding. Even the most experienced engineers need to prepare and practice to do well in an interview. For example, if you haven’t practiced solving new problems under time constraints, interviewers may think you’re unqualified when you’re simply unprepared.
Coding – You should know at least one programming language really well, preferably C++, Java, Python, Go, or C. You will be expected to know APIs, Object Oriented Design and Programming, how to test your code, as well as come up with corner cases and edge cases for code. Note that we focus on conceptual understanding rather than memorization.
Algorithms – Approach the problem with both bottom-up and top-down algorithms. You will be expected to know the complexity of an algorithm and how you can improve / change it. Algorithms that are used to solve Google problems include sorting (plus searching and binary search), divide-and-conquer, dynamic programming / memoization, greediness, recursion or algorithms linked to a specific data structure. Know Big-O notations (e.g. run time) and be ready to discuss complex algorithms like Dijkstra and A*. We recommend discussing or outlining the algorithm you have in mind before writing code.
Sorting – Be familiar with common sorting functions and on what kind of input data they’re efficient or ineffcient. Think about efficiency means in terms of runtime and space used. For example, in exceptional cases insertion-sort or radix-sort are much better than the generic QuickSort / MergeSort / HeapSort answers.
Data structures – You should study up on as many data structures as possible. Data structures most frequently used are arrays, linked lists, stacks, queues, hash-sets, hash-maps, hash-tables, dictionary, trees and binary trees, heaps, bloom filter and graphs. You should know the data structure inside out, and what algorithms tend to go along with each data structure.
Mathematics – Some interviewers ask basic discrete math questions. This is more prevalent at Google than at other companies because counting problems, probability problems and other Discrete Math 101 situations surround us. Spend some time before the interview refreshing your memory on (or teaching yourself) the essentials of elementary probability theory and combinatorics. You should be familiar with n-choose-k problems and their ilk.
Graphs – Consider if a problem can be applied with graph algorithms like distance, search, connectivity, cycle-detection, etc. There are three basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list) — familiarize yourself with each representation and its pros and cons. You should know the basic graph traversal algorithms, breadth-first search and depth-first search. Know their computational complexity, their tradeoffs and how to implement them in real code.
Recursion – Many coding problems involve thinking recursively and potentially coding a recursive solution. Use recursion to find more elegant solutions to problems that can be solved iteratively.
Your interviewer will be thinking about how your skills and experience might help their teams. Help them understand the value you could bring by focusing on these traits and abilities:
Communication. Are you asking for requirements and clarity when necessary, or are you just diving into the code? Your initial tech screen should be a conversation, so don’t forget to ask questions.
Problem solving. We’re evaluating how you comprehend and explain complex ideas. Are you providing the reasoning behind a particular solution? Developing and comparing multiple solutions? Using appropriate data structures? Speaking about space and time complexity? Optimizing your solution?
Coding. Can you convert solutions to executable code? Is the code organized and does it capture the right logical structure?
Verification. Are you considering a reasonable number of test cases or coming up with a good argument for why your code is correct? If your solution has bugs, are you able to walk through your own logic to find them and explain what the code is doing?
Interviewers can only assess your skills and abilities based on what you show them during your interview, so it’s important to plan and prepare to best showcase your strengths.
Schedule time to study and practice. Block out time every day to write code. Target medium and hard problems. Prioritize breadth over depth. It’s much better to practice solving fewer example problems of many problem types than to become very familiar with one type at the expense of the others. Set aside time to review what you’ve practiced. As you solve problems, make cheat sheets or flash cards to review later. Revision and repetition will strengthen your understanding of core concepts.
Everyone could use a refresher in at least one area.
Algorithm design/analysis. Consider different algorithms and algorithmic techniques, such as sorting, divide-and-conquer, recursion, etc.
Data structures. Make sure you’re using the right tool for the right job. Keep in mind how and when certain data structures should be used and leveraged, and why some are preferred over others.
Other CS fundamentals. Review foundational techniques, including recursion, graph theory, tree traversal, combinatorial problems, and so on.
Reading through sample questions, recognizing concepts, and having a vague understanding of these concepts won’t be enough to help you shine. You need to practice! Make sure you’re setting your practice sessions up for success by following these tips from engineers who’ve been through the process.
Practice coding the way you’ll code during your interview. You’ll most likely be coding at a whiteboard, but check with your recruiter.
Code in your strongest language. Avoid trying to learn a new language in a few weeks.
Practice talking through the problem space and possible solutions before you dive into code, and practice talking through your decisions out loud as you code. This can be unnatural in an interview setting, especially if you’re used to coding alone. But your interviewers will be evaluating your thought process as well as your coding abilities, so explaining your decisions as you code is crucial to helping them understand your choices.
Practice a variety of different problems—and understand why we ask them—so you’re prepared to solve them during your onsite interview.
Don’t be surprised if the questions sound contrived. Problems may be different than what you’re probably tackling in a day-to-day job. We won’t ask a “puzzle” question, but questions may be different than real-world questions because they need to be described and solved in 10-20 minutes.
Problems may assess the depth of your knowledge and your versatility. For example, your interviewer might ask you to solve a problem any way you want. Then, they could add constraints on the running or space characteristics and ask you to solve it again.
Problems may focus on edge cases. You might be asked to parse some data format or mini language. Your answers demonstrate your ability to handle multiple states in your head.
Problems may test how well you know how things work under the hood. For example, you might be asked to implement well-known library functions.
It’s easy to be overwhelmed by the number of online resources or the detail in an entire theoretical algorithms book. For example, CLRS has excellent info—but it may not be the right resource for your study needs and timeline. Pick two or three resources and focus on those.
Your interview is a conversation, not a test! Your interviewer wants to find out what it would feel like to work with you and solve a problem together, so approach problems like you’re working on a team together and collaborating to build the solution.
Before you jump into building a solution, be sure you’ve taken the time to fully understand and talk through the problem.
Ask clarifying questions. Talk through the problem and ask follow-up questions to make sure you understand the exact problem you’re trying to solve.
Let us know if you’ve seen the problem previously. That will help us understand your context.
Talk through the problem and your approach, and frame both like you’re working with your interviewer. Try using words like “we” and “our” instead of “I” and “my” when you walk through the problem and solution to make the interview feel more collaborative.
Get your thoughts down in code and explain your decisions and actions as you go.
Don’t forget to talk while you code! It’s crucial to help the interviewer understand your choices and thought process.
Iterate. Don’t always try to jump immediately to the most clever solution. Talk through multiple possible solutions, then decide which will work best and explain your decision.
Leave yourself plenty of room. You may need to add code or notes between lines later.
Consider different algorithms and algorithmic techniques, such as sorting, divide-and-conquer, recursion, etc.
Think about data structures, particularly those used most often (array, stack/queue, hashset/hashmap/hashtable/dictionary, tree/binary tree, heap, graph, etc.)
Be prepared to talk about O memory constraints on the complexity of the algorithm you’re writing and its running time as expressed by big-O notation.
Avoid solutions with lots of edge cases or huge if/else if/else blocks, in most cases. Deciding between iteration and recursion can be an important step.
Use descriptive variable names. This will take time, but it will prevent you from losing track of what your code is doing.
Simplify. If you can’t explain your concept clearly in five minutes, it’s probably too complex.
Draw out a sample input. Draw a picture or write out the variable values to see how the variables change as your code executes. You’ll see insights and bugs faster and be less likely to lose track when you’re thinking through edge cases in your head!
Everyone, even engineers with years of experience, will get stuck at some point. Relax—it doesn’t mean you’ve failed! The interviewer will be assessing your ability to methodically approach the problem from several angles and ask the right questions to get unstuck.
Draw pictures. It’s easy to lose track when you’re thinking through an edge case or how variables change as your code executes, so use the board! Writing everything out helps you see insights and bugs faster and make fewer mistakes. Draw several different test inputs. Capture how you would get the desired output by hand, then talk through your approach and translate it into code.
Ask questions. For example, if you don’t know the exact syntax, you can ask the interviewer for help.
Think out loud as a way to slow yourself down. Use phrases like “Let’s try doing it this way” or “We need to consider all the possibilities” to give yourself time to think while still making progress. Talk through what you know.
Talk through what you first thought might work and explain why it won’t. You might think of a way to modify your original solution so it works or another question to ask to help you decide on your next steps.
Talk through the bounds on space and runtime. For example, say: “We have to at least look at all of the items, so we can’t do better than X.” “The brute force approach is to test all possibilities, which is X.” “The answer will contain X items, so we must at least spend that amount of time.”
Call a helper function and keep moving. If you can’t immediately think of how to implement some part of your algorithm, big or small, just skip over it. Write a call to a reasonably named helper function, say what it will do, and keep going. If the helper function is trivial, save it for the end. You can even ask your interviewer if they’d like to help implement it.
Solve a simpler version of the problem. Not sure how to find the 4th-largest item in the set? Think about how to find the largest item and see if you can adapt that approach.
Propose a solution that’s naive and potentially inefficient. Consider optimizations later. Use brute force. Do whatever it takes to get some kind of answer.
Remember that it’s ok if you don’t know! No one who works at Facebook is perfect, and we on’t look for perfection in people we interview. If you aren’t sure if something is true or if it’s the best solution, then say that. Explain what you do know, and your interviewer will ask you follow-up questions.
You don’t get more credit for doing this in your head! Testing your solution on the board, out loud will help you find bugs and clear up any confusion your interviewer may have.
Walk through your solution by hand, out loud, with an example input. Write down what values the variables hold as the program is running.
Look for off-by-one errors. Should your for loop use a “<” instead of a “<=”?
Test edge cases. These might include empty sets, single item sets, or negative numbers. Don’t forget about software verification—formal or otherwise!
Ask yourself if you would approve your solution as part of your codebase. Explain your answer to your interviewer. Make sure your solution is correct and efficient, and that it clearly reflects the ideas you’re trying to express.
There are two types of design interviews: systems design and product design. Interviewers will evaluate your ability to determine what you should build and to solve large problems. Your interviewer will ask you a very broad design problem and evaluate your solution. We aim to match people interviewing with engineers who have related experience, so your conversation will be based in an area you’re at least slightly familiar with.
This portion of the interview will consist of one or two conversations, 45 minutes each. You will only need to practice these skills if you are interviewing for a position which requires these competencies. Your interviewer will let you know whether you need to prepare for this portion of the interview.
If you have deep, specialized knowledge, we may ask something specific to that area. More often, we’ll ask you to design something you’ve never built before. And the scope will be large enough that you won’t be able to cover everything in detail.
System design questions are used to assess a candidate’s ability to combine knowledge, theory, experience and judgement toward solving a real-world engineering problem. Sample topics include feature sets, interfaces, class hierarchies, constraints, simplicity, robustness and tradeoffs. The interview will assess your deep understanding of how the internet works and familiarity with the various pieces (routers, domain name servers, load balancers, firewalls, etc.).
This is an interview where the interviewer will assess your ability to design at scale. The interviewer will give you a design challenge, and would like you over the next 35-40 minutes to come up with a design, and would like you to work under the assumption that right after this meeting, he / she and colleagues will implement your design as you describe it. At the end of the interview, the interviewer will ask you to explain what key components they will need to build, and at a high-level, what hardware they’ll need to run the system. For you to be successful in this interview, the interviewer will need to believe that your design is fleshed out enough that what he / she builds will work at scale.
The question may seem open ended, but part of this interview is also clarifying the problem and so the interviewer will expect you to translate his/her request into something that is solvable by a technical system.
Interviewers will focus on your familiarity with complex products or systems and assess your ability to arrive at answers in the face of unusual constraints.
You should be familiar with the areas below—but we’re not looking for you to be an expert in all of them. You should know enough to weigh design considerations (and understand when to consult an expert) for:
Due to the wide variety of projects we offer at Google, it is important our design questions are relevant to both your background and the role you will be exploring. Be sure to discuss with your recruiter the role you’re pursuing and which system design question is best suited to assess your skills. Depending on your area of expertise, one of the following types of design questions will be asked:
System design is a general category which means “big enough systems that you have to operate on a high level of abstraction to get the basic architecture down.” A distributed system question is related to problems of coordination between autonomous systems while system design can include problems constrained to a single execution.
Distributed systems questions focus on cross-task coordination, communication, synchronization, and failure modes. System design questions are more weighted toward managing the complexity of large bodies of software. You can find some of the Google research around distributed systems here.
Example Distributed System Design: Design a distributed unique ID service.
This type of system design question is typically asked when exploring our embedded software engineering roles here at Google. Expect a very broad question that doesn’t have a single right answer but can go in a number of directions. Your interviewer will probably drill down in more detail in a few areas.
A low level system design interview covers areas of design that span issues of scaling, details of integration with hardware and integration with higher level components. You might come across questions that relate to OTAs, boot, reliability, power management, the kinds of issues that any low-level team will be dealing with on a constant basis. The interview will assess understanding of high level concepts, file storage, encryption, signing, how devices boot, how disks are laid out, how power management functions, etc.
Example Low Level Design: Design an automated failover system for a replicated database.
Candidates who have experience with Machine Learning technologies may be asked a Machine Learning design question. These questions are generally open ended so you can dive deeper into the solution. It is important to design a solution thinking about data analysis, potential use cases, the users, scalability, limitations and tradeoffs. The Machine Learning Design question may focus on one specialization within machine learning. These may include computer vision, deep learning/neural networks, recommendations/ranking systems, natural language processing, speech/audio or reinforcement learning.
Example Machine Learning Design: Design a near-duplicate image detection system.
Mobile application design questions are targeted toward mobile focused candidates (iOS and Android developers). A mobile application design interview gives the candidate a chance to display their design skills within this domain. The goal of a design interview is to assess your ability to combine knowledge, theory, experience and judgement toward solving a real-world engineering problem. Interviewers may ask the candidate to specify the design of an entire mobile application, subsystems within a specific application or a solution to a difficult aspect of mobile application development.
Reflect on the design decisions you’ve made in the past and think about the justifications and rationale for those design details. Study any published and available designs for mobile application problems. Think in some detail about how you would architect some of the applications that you use often and are familiar with. Practice with top-down and bottom-up design approaches and consider how various layers of a system interact with each other.
Example Application System Design: How would you speed up the startup time for the YouTube app?
A front end design interview will typically involve problems that require an understanding of key front end concepts such as web serving systems, client-side technologies and languages, and common design patterns for UI development.
The problem analysis could involve a break-down into sub-problems, identification of areas of risk, or a discussion of requirements and goals. The solution could involve (but not limited to!) system diagrams, state diagrams, data-structures, or algorithms. Explaining the solution crisply is as important as coming up with the solution, and informs us how well candidates are able to collaborate. Code may be involved to describe a solution, but this may not be the objective. In some cases, a portion of a design problem may translate into a coding a problem.
Example Front End UI Web Design: Design a web system to sell concert tickets.