If you Google anything along the lines of ‘coding interview prep for FAANG’ or ‘coding questions asked at Google’, you’ll soon be overwhelmed by the sheer volume of technical interview prep material out there. 

So, we jumped at the chance to sit down with Ava Katushka, a former Google Software Engineer and Technical Interview Coach, to pick her brain. She shared tips on what you should really focus on to ace your coding interview and land an offer from Google and other Top Tech firms.

What questions should you expect to be asked in your interview, and why?

Let’s take a closer look at a typical question Ava says you should expect to see.

Problem:
Given an encoded string, return its decoded string.
3[a]2[bc]=aaabcbc

In this question, you’re tasked with writing a program to decode this string. This seems like a relatively simple problem, and you’d be forgiven for wondering why it would appear in a Google SWE interview.

The key thing to remember when faced with this kind of problem is that solving this is just the first layer. Typically, in a Google (or other Big Tech) coding assessment, your interviewer will keep asking follow-up questions that become more and more complex as you progress. They aren’t just looking for you to solve the simple first statement; they want to see how deep you can go with this problem.

Example follow up question:

What about layered encodings?
For example,
3[a2[c]]=3[acc]=accaccacc

Sites like HackerRank and LeetCode have countless sample coding questions you can practice on.

‍

The Top 4 Topics for Coding Interview Questions

#1 Arrays & Strings

Example Question:

Given an encoded string, return its decoded string.
3[a]2[bc]=aaabcbc

#2 Graphs

About 30% of coding interview questions are about graphs, so you should be really familiar with tree structure. You’ll need to be able to iterate for graphs and to see graphs in the question.

Example Question:

There are courses you want to take. Some of these courses have prerequisites. Output the order, in which you would take them. 

#3 Recursion

A classic example of a question focusing on this topic includes the buying and selling of stock.
You’ll need to be able to optimize recursion, use a cash, and know how to use dynamic programming. 

Example Question:

You know the price of the stock on each day. Find the algorithm to buy/sell stock to maximize profit.

#4 Math and Geometry

Example Question:

Given a positive integer n, find the least number of perfect square numbers (for example 1,4,9,16…) which sum to n.

Why those questions?

A common topic of debate among software engineers is why interviewers concentrate on these types of questions in coding interviews. Questions that essentially focus on the basics of Computer Science. Even though you’re expected to have an in-depth understanding of the topics and be able to manipulate the information quickly, these questions don’t typically reflect the problems and tasks you’ll face once you land the job. 

There is, however, a method to the madness. These types of questions assess the traits and abilities that are markers for on-the-job success. 

• ‍Problem solving. Critical thinking as a vital ability for software engineers. To assess your competence in this area, it’s important that you face a task that is unfamiliar. The interviewer wants to see how you cope with struggling your way through a problem, how you manage the difficulties of problem solving on the spot. They want to see your thought process and how you tackle the challenge of finding a viable solution.
  
  If you happen to already be familiar with the example provided, Ava actually recommends letting the interviewer know. They can tell right away if you already know the answer, and the correct answer is not actually what they’re after here. It’s your problem-solving process they want to observe. If one of the practice questions you’ve worked on comes up in the interview, Ava says you should let the interviewer know and wait for their response. Sometimes they will say it's ok and for you to go ahead anyway, other times they’ll choose to rather give you a new question to work through.
  ‍‍
• Computer Science knowledge is useful. Sounds obvious, doesn’t it? But that’s exactly why interview questions focus on these Computer Science fundamentals. These concepts are everywhere – they underpin all the fields that make up the world of tech that a software engineer could find themselves in. Data centers, cloud computing, system design – the very internet itself exists through the ‘basics of computer science’.

• It’s a good proxy. As a Software Engineer the coding skills you’re tested on directly correlate to skills you’ll need to use on the job. Even if you won’t be faced with solving problems in the same format as your interview, the need to assess your overall coding proficiency is self-explanatory. The interviewers will be looking at how well you structure your code, how fast you work while still maintaining a high level of accuracy and producing few mistakes.

Should you ask your interviewer clarifying questions?

Likely one of the most important things to bear in mind, is that the person on the other side of the table, is also a Software Engineer – just like you. They’re not out to scare you or to trick you into failing the interview. They actually want you to have a great experience and to see you succeed. 

Ava says you should rely on your interviewer and interact with them before diving headfirst into solving a problem. If they give you hints, it’s absolutely ok to use those clues and ask questions to make sure you understand what’s expected. When presented with a coding problem, it's really important to spend a few minutes clarifying the requirements with the interviewer. Many times you'll get a question that seems very straightforward, but actually has a lot of nuances and gray areas that should be cleared up.

In fact Carrus Coach Phil Verghese, himself a former Google Software Engineer and Engineering Manager, says not asking these kinds of questions is one of the biggest mistakes he’s seen in coding interviews. Learn more about Phil’s insights into the Google Software Engineering interview process.

How much time do you need to prepare?

When we surveyed a group of software engineers on how much time they thought you’d need to prepare for a technical interview at Google (or any other FAANG or Top Tech company), the answers ranged from 2 weeks to a year, with 6 months being the most popular response. 

Ava says that her answer to this question assumes you have a foundation in Computer Science knowledge – either through a university degree, online courses or some form of self-study. Without such a foundation, you’d really struggle and the time spent on prep work would be really unproductive and demotivating. 

If you can dedicate yourself to full-time preparation and working through sample problems like it’s your job, Ava says 2-3 months should suffice. If however, you’re only able to work part-time on your coding prep, which let's be real here, is most people, then you should aim for 1 year.

It’s important to be realistic about the time and effort that you need to invest in preparation and upskilling in order to land these kinds of roles. When a group of fresh hires at Google were asked how many practice questions they solved in preparation for their SWE interview the answer was 200-300.

The Google Software Engineering Hiring Process

It's worth bearing in mind that your coding interview is only half the battle. One that definitely requires adequate preparation and planning, but making sure you’re ready to conquer the remaining steps is equally important. 

Familiarize yourself with the entire process. Be certain that you know what to expect and are fully prepared. 

Step 1: Get noticed

• Via a Recruiter on LInkedIn. 95% of recruiters use LinkedIn to discover talent for the vacancies they’re looking to fill. Make sure your profile is optimized for landing Top Tech jobs.
• Referrals. If you know someone who works at the company you’re targeting they can refer you for the role.
• Website. You can apply directly through the company website. It’s important to note though that your chances increase 8-1 if you apply via referral or are working through a recruiter instead.
  

Step 2: Phone Screen

• 1-3 telephonic coding interviews. You can expect to be asked the kind of questions we cover in this article in your phone screens. They typically last about 40 minutes.
  

Step 3: Onsite Interviews

• 2-4 coding interviews with various people. Again you can expect the same kind of questions and topics we’re covering here.
• System design interview. There are some great online resources available to prepare for these questions. Carrus Coach Phil recommends Grokking the System Design Interview, Fundamentals of System Design, and The System Design Primer (which includes good questions with solutions).
• Behavioral interview. Apart from technical questions you’ll need to answer situational and behavioral questions to make it to an offer. Getting comfortable with the most commonly asked Google interview questions is a good place to start. You’ll also want to make sure you’re familiar with requirements that are unique to Google, such as Googleyness. Using the STAR method to refine and practice your storytelling for behavioral interviews is guaranteed to set you up for success. 
  

Step 4: Offer

Hiring committee reviews your offer and decides on the annual salary, relocation bonus and stocks offered to you. At this point you might want to enlist the help of an offer negotiation specialist to ensure you secure the best possible offer.

The most common interview mistakes (and how to avoid making them)

Ava says there are some coding interview mistakes that are frequently made yet easily avoidable.

#1 Not knowing what to expect.

Turning up for your interview not knowing what kind of questions you’ll be asked is one of the most frequent mistakes Ava sees. 

It’s important that you’re familiar with the interview structure as well as the types of questions the interviewers will pose and that you’ve practiced these kinds of questions.

#2 Not taking enough time to prepare

Ava says she gets many requests for mock interviews where the person has only a week (or maybe two) before their coding interview and has done no prior prep. Unfortunately the honest answer here is that you can’t prepare adequately in this time frame if you’re only looking to start now. 

#3 Not using the interview time efficiently

In the interview, time management is crucial to get through everything you need to cover. You have 40 minutes to solve an unfamiliar question, explain what you’re doing to your interviewer, write working code, test it, clarify time and space complexity and ideally go beyond the task by suggesting alternatives. 

The only way to get better at getting through these tasks within the constraints of the interview structure is to practice using that structure through mock interviews. 

There are several ways you can do this:

1. 1-1 coaching from a coach with personal experience with the FAANG interview structure like Ava.
2. Using free online platforms.
3. Ask a friend to practice a mock interview with you – remember to practice out loud.
   

#4 Solving the wrong problem

This can happen to the best of us, but the easiest way to avoid making this mistake is clarifying the problem. Before you start solving the problem, give the interviewer your inputs and outputs – make sure you understand the problem and that you and the interviewer are on the same page. 

If you think you understand the problem, but it’s not the problem that the interviewer intended for you to solve, and you end up solving the wrong problem, that’s a major red flag. It tells the interviewer that you rush into action, before actually clarifying the problem and making sure your effort is going into creating a viable solution.

#5 You don’t test your code

Instead of saying “Okay! I think it’s done!” you should be saying “Okay, I think it’s done, but let me test it.”

When you finally come to the point where you’ve written some code in such a stressful interview, feels like you’ve won the battle. It’s very tempting to sit back, let out a sigh of relief and say you’re done.

Here’s the thing, your code is likely full of mistakes, that your interviewer may have already noticed, but you haven’t. How often have you sat down, reviewed an unfamiliar problem, formulated a solution and written the code for your solution with zero mistakes first time round all in under 40 minutes? Add to that interview nerves and the ticking clock and the need to test your code, before handing it over as done, becomes obvious. Its far better for you to find your mistakes and fix them, than to have the interviewer point them out to you.

#6 You don’t know your language of choice deeply

You need to be extremely comfortable with the language you’re writing in and know it beyond the surface. You’ll be expected to know the code style, memory management, invisible copies, mutable / immutable types in your language etc.

Steer clear from writing in a language that is not your first or primary language as when you don’t know a language very well it will show in your interview. On the flip side, when you do know a language deeply that also shows – choose to work in the language you love and know exceptionally well.

#7 Not estimating time/space complexity (or estimating it incorrectly).

Perhaps you’re familiar with this famous example:

It’s very common to think that this algorithm would have linear complexity, but its actually square because strings are immutable in Java. Strings are not only immutable in Java but also in Python and JavaScript, so you really need to be aware of the constraints of the language you’re working with and estimate these kinds of algorithms correctly. 

#8 You don’t suggest alternatives

If you want to go beyond the minimum that is asked of you and leave a lasting positive impression on your interviewer, you’ll want to suggest multiple solutions for your problem.  

You’ll also want to compare the solutions you’ve come up with and pick the best one based on your constraints. This goes back to asking the right kind of questions. In order to select the best solution based on the constraints of your problem, you’ll need to ask question like: How big is the array? How long is the string? What kind of string are we dealing with?

Coding interview time management.

A framework for answering coding questions – how to approach a coding interview.

1. First 5 minutes - Ask clarifying questions and come up with examples – give the inputs and outputs you would use later for testing. Your aim here is to make sure you and the interviewer are on the same page.
2. Next 10 minutes (max) - Suggest the solution. Start with suggesting the obvious solution and work to improve from there. Even if you think of an optimal solution at first, you ideally don’t want to start there as you’ll have no room for demonstrating improvement. A good candidate will present numerous design alternatives, each with pros and cons on tradeoffs between time, space and code complexity.
   
   If you can only think of a brute force solution, Ava’s advice is to just move ahead and start coding. While you’re coding you might get some better ideas, or your interviewer might give you some hints. You can also ask your interviewer for hints if you’re really stuck. Ava says it’s totally allowed, and you won’t fail your interview for asking for a hint.
3. Next 20 minutes - Write good code, say what you’re doing. Your aim is to write readable, production ready, structured code that would work and another software engineer could understand. You want to start coding by the 15-minute mark. Typically, people who leave it later than this point to start writing their code don’t finish in time and don’t have time to test their code.
4. Last 5 minutes – Test out loud. This will help you catch your mistakes and develop good intuition. 

Additional resources

• Our in-depth 6 part series on using the STAR Interview Method to Nail Any Tech Interview
• Cracking the Coding Interview: 189 Programming Questions and Solutions by Gayle Laakmann McDowell
• The Google hiring committee (rework)
• Software Engineering at Google: Lessons Learned from Programming Over Time by Titus Winters (Senior Staff Software Engineer at Google), Tom Manshreck (Staff Technical Writer within Software Engineering at Google), Hyrum Wright (Staff Software Engineer at Google)

Other Google related reads on Carrus:

• How to Crack the Google Sales/Business Development Interview (With sample Q&A)
• What is Googleyness?
• Top Google Interview Questions You Need to Know for 2022
• How to land an interview at Google
• Interview Insights from an ex-Google Software Engineer
• Top Tips on Nailing the Technical Interview from ex-Amazon & ex-Google Engineers
• How to Ace your Google Product Manager Interview
• Insider Advice on Crafting Your Resume to Catch the Attention of Hiring Managers at Google, Apple, & Amazon
• The Pros & Cons of Being a Temp or Contractor at Google