September 18, 2022
Coding & Algorithm Interview Leadership & Behavioral Interview Resume Preparation System Design Interview
Resume Preparation
Resources
General Interview Tips
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.
Resources
Leadership Interviews
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.
STAR Method
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.
Sample STAR Response:
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.
How to prepare for a behavioral interview
- Recall recent situations that show favorable behaviors or actions, especially involving course work, work experience, leadership, teamwork, initiative, planning, and customer service.
- Prepare short descriptions of each situation; be ready to give details if asked.
- Be sure each story has a beginning, middle, and an end, i.e., be ready to describe the situation, including the task at hand, your action, and the outcome or result.
- Be sure the outcome or result reflects positively on you (even if the result itself was not favorable).
- Be honest. Don’t embellish or omit any part of the story. The interviewer will find out if your story is built on a weak foundation.
- Be specific. Don’t generalize about several events; give a detailed accounting of one event.
- Vary your examples; don’t take them all from just one area of your life.
Sample behavioral interview questions
Practice using the STAR Method on these common behavioral interviewing questions:
- Describe a situation in which you were able to use persuasion to successfully convince someone to see things your way.
- Describe a time when you were faced with a stressful situation that demonstrated your coping skills.
- Give me a specific example of a time when you used good judgment and logic in solving a problem.
- Give me an example of a time when you set a goal and were able to meet or achieve it.
- Tell me about a time when you had to use your presentation skills to influence someone’s opinion.
- Give me a specific example of a time when you had to conform to a policy with which you did not agree.
- Please discuss an important written document you were required to complete.
- Tell me about a time when you had to go above and beyond the call of duty in order to get a job done.
- Tell me about a time when you had too many things to do and you were required to prioritize your tasks.
- Give me an example of a time when you had to make a split second decision.
- What is your typical way of dealing with conflict? Give me an example.
- Tell me about a time you were able to successfully deal with another person even when that individual may not have personally liked you (or vice versa).
- Tell me about a difficult decision you’ve made in the last year.
- Give me an example of a time when something you tried to accomplish and failed.
- Give me an example of when you showed initiative and took the lead.
- Tell me about a recent situation in which you had to deal with a very upset customer or co-worker.
- Give me an example of a time when you motivated others.
- Tell me about a time when you delegated a project effectively.
- Give me an example of a time when you used your fact-finding skills to solve a problem.
- Tell me about a time when you missed an obvious solution to a problem.
- Describe a time when you anticipated potential problems and developed preventive measures.
- Tell me about a time when you were forced to make an unpopular decision.
- Please tell me about a time you had to fire a friend.
- Describe a time when you set your sights too high (or too low).
Resources
Coding & Algorithm Interviews
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.
What the interviewer is looking for:
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?
How to Prepare
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.
- Before you practice, plan! Be honest with yourself—only you know how much prep time you’ll need. Make the most of your prep time by following these steps to plan your approach before you start practicing.
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.
- Review core areas
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.
- Focus on key practice strategies
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.
- Understand the types of problems you may encounter
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.
- Decide what resources you’ll use to prepare
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.
How to Approach Problems During Your Interview
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.
- Analyze the problem
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.
- Code up your solution
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!
- Stuck? Try these approaches!
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.
- Verify your solution
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.
Resources
- Prepare for Your Google Interview: Coding
- How to: Work at Google — Example Coding/Engineering Interview
System Design Interviews
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.
What is a system design question and why is it important?
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.
Important topics you should be familiar with:
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:
- Concurrency (threads, deadlock, starvation, consistency, coherence)
- Caching
- Networking (IPC, TCP/IP)
- Abstraction (understanding how OS, filesystem, and database works)
- Real-world performance (relative performance RAM, disk, your network, SSD)
- Availability and Reliability (durability, understanding how things can fail, types of failures, failure units, how failures may manifest, mitigations, etc.)
- Data storage and data aggregation (RAM vs. durable storage, compression, byte sizes)
- Database partitioning, replication, sharding, CAP Theorem
- Kernel
- File Systems
- Byte Math
- QPS capacity / machine estimation (back of the envelope estimates), byte size estimation
What the interviewer is looking for:
- Can you arrive at an answer in the face of unusual constraints?
- Can you visualize the entire problem and solution space?
- Can you make trade-offs like consistency, availability, partitioning, performance?
- Can you give ballpark numbers on throughput / capacity for RAM, hard drive, network, etc using a modern computer?
A good design shows that you:
- Clearly understand the problem
- Propose a design for a product / system that breaks the problem down into components, that can be built independently and you can drill into the any piece of the design and talk about it in detail
- Identify the bottlenecks as the system scales and understand the limitations in your design
- Understand how to adapt the solution when the requirements change
- Draw diagrams that clearly describe the relationship between the different components in the system
- Calculate (back-of-the-envelope) the physical resources necessary to make this system work
How to Practice:
- The design interview is often the hardest interview to study for.
- Work with a fellow engineer on mock design sessions.
- Dig into the implementation and performance of an open source system, understand things like how the system stores data on disk and how it compacts data
- Be familiar with how databases and operating systems work
- Practice on a whiteboard
- To practice, take any well-known app and imagine you work for a competitor. Your job is to figure out where most of their money is spent (compute? people? bandwidth? storage?) and the fundamental bottleneck of their system. Answering those two questions will necessarily force you to think about how a system is actually implemented. Answering only cost and bottlenecks forces you to focus on important areas and not nerdy details of the design.
- For example, YouTube spends a ton of money on bandwidth, and secondarily on storage and compute. On the other hand, their long;tail traffic pattern means that their fundamental bottleneck is random disk seeks. Netflix also is a bandwidth hog but most of their traffic is at night (when it’s cheap) and their library of videos is much much smaller, so disk;seeks are probably not an issue at all.
- Work out the above problems on a paper and just think about the ways to break them down. It also helps to read up on common large scale systems, like watch the public videos about and learn how search engines work. But during the interview, don’t parrot back what you read; make sure your solution actually answers the question being asked.
- Review the complex systems you’ve already designed. What would you change about your approach if you did it all over again? What worked well?
- Think about how you’d design one of Facebook’s (or any other large tech company’s) existing systems. It’s a good practice to think through the complicated, high-scale systems you already use every day. How would you design one from the ground up?
- Weigh multiple approaches and reflect on the tradeoffs in your design: Performance vs. scalability, Latency vs. throughput, Availability vs. consistency
- Take any well-known app and imagine you’re going to build the primary feature. For example, imagine you’re going to build video distribution for Facebook Video, or group chat for WhatsApp. Now figure out how you would build the various pieces out:
- How would you build your backend storage? How does that scale to Facebook’s size?
- How would you lay out the application server layer? What are the responsibilities of the various services?
- How would you design your mobile API? What are the hard problems in representing the data being sent from server to client?
- How would you structure your mobile client? How do low-end devices and poor network conditions affect your design?
- As you’re designing these systems, run through the list of things we’re looking for and make sure you’re able to answer them all for each piece of each app.
Some example questions:
- Design a key-value store
- Design Google search
- Architect a world-wide video distribution system
- Build Facebook chat
- You’ve had experience working in Fraud Systems. Please design a system to reduce fraud from compromised accounts
- You’ve had experience building a system that takes payments. Please design a system to support “Facebook Credits”
- You’ve had experience building a music sharing service. Please design this feature in Facebook.
Interview Tips and Expectations:
- The system design question will ask you to take an abstract question in a formerly unseen problem and present a high level framework to solve the presented problem. In doing so, follow these steps:
- Gather key requirements
- Identify key design elements
- Identify tradeoffs of different decisions
- Dive deep into a specific sub-problem AND/OR demonstrate what process to use to arrive at a solution
- Identify the major components of an overall system design and deeply describe at least two of them. Suggest which technologies and systems should be used to solve a relatively common problem (i.e. relational database, document-based database, etc.), and if relevant, share a story about a time you have solved a problem using these technologies.
- When defining a system, include as many non-functional requirements as possible. For example: performance, latency, legal, privacy, maintainability, capacity, security, geographic, and cross-DC consideration.
- Develop a framework you can use to answer most questions.
- Approach the problem with an open mind: Be mindful that your familiarity (if any) with the problem may make you take shortcuts (even verbal ones when explaining your approach); the interviewer may not share the same context as you. If there is a more succinct approach, feel free to explain to the interviewer the route you’re taking and the context behind why.
- Problem Solve: The interviewers are looking for problem solving and approach as much as they are assessing your solution. So, ask clarifying questions about the problem, express ideas verbally, and think out loud. Constantly challenge your own design. Be prepared to justify every decision you make. Practice going through problems with a friend.
- Listen: Design questions are typically open-ended and the problem may be ambiguous. If the interviewer gives a hint or asks a question while you are solving the problem, listen intently and do not ignore. They are most likely trying to guide you or looking for a particular awareness.
Role-related design questions
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:
Distributed System Design
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.
Low Level System Design
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.
Machine Learning Design
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 System Design
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?
Front End UI Web Design
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.
Resources
