How to: Work at Google — Example Coding/Engineering Interview

By: Life at Google

25212   2055   1813605

Uploaded on 11/07/2016

Watch our video to see two Google engineers demonstrate a mock interview question. After they code, our engineers highlight best practices for interviewing at Google.

Learn more about how we hire at, then head over to to find your role.

Also check out our companion video, How to Work at Google: Prepare for an Engineering Interview (

Subscribe to Life at Google for more videos →

Follow us!
Google Plus:

Comments (6):

By bhuga    2017-10-16

I just went through a round of interviews and came away with a better opinion of these "toy" interviews than I started with[1], so I'll play devil's advocate here: these questions have a place. The main reason to use these questions is that they're studyable.

Google and Facebook both put out content that walk you through how to solve problems like this. When you get an interview, you can delay it as long as you want, they can tell you the sort of problems to study: go read "Cracking the Coding Interview". Facebook sends you a link to it and a video of the author working a problem. Google sends you stuff like There are thousands of toy questions, and it's not feasible to memorize them all. The correct _and expected_ thing to do is study up for the category.

Now that your candidates have in theory studied, you'll get a studied, "best" performance for each candidate, and interview outcomes can be compared in a very low-bias, apples-to-apples way. I can't imagine the success criteria for a pairing being clearer than for toys. I think the potential for toy question interviews to be managed in a low-bias way is the main reason they're used.

In comparison, how do you ensure that your exercise in go is exactly as hard as your exercise in Java? Or do they need to know go, or some other language? Or that they didn't spend longer on the take home than you asked? Or 100 other factors of your particular exercise? It's really hard to let every candidate shine on a level playing field using "real world" stuff. [2]

That said, there's good reasons to do pairing, or a bug squash, or a take home, or juggling, or _anything different_. The first is that candidates with 15 years of experience don't show up better than college grads on "toy" questions, even if they've studied. You can only do so well on them, and experienced candidates tend to have options and won't put a lot of time in to studying. And the corollary to that is that the biggest tech employers are leaving some great candidates behind, because they interview better doing "real world" stuff. And your company can go get them, just because you bothered to do something different. Most companies won't outbid Google and Facebook, so why would your interview process try to find the same candidates they do?

[1]: And to be clear: I did not get any offers from my interviews based entirely on this sort of question. I'm not the worst but far from the best.

[2]: Triplebyte's long-ish video chat interview is the best thing I've seen at "standardizing" this.

Original Thread

By anonymous    2017-09-20

I remember, I was watching the official Google video about this problem. Although it is not demonstrated in java, it is explained step-by-step in different variations of the problem. You should definitely check it:

How to: Work at Google — Example Coding/Engineering Interview

Original Thread

By anonymous    2017-09-20

As explained in the Google video that Alexander G is linking to, use two array indexes. Initialize one to the first element (0) and the other to the last element (sortedArray.length - 1). In a loop, check the sum of the two elements at the two indexes. If the sum is the number you were looking for, you’re done. If it’s too high, you need to find a smaller number at one of the indexes; move the right index one step to the left (since the array is sorted, this is the right way). If on the other hand, the sum you got was too low, move the left index to the right to obtain a higher first addend. When the two indexes meet, if you still haven’t found the sum you were looking for, there isn’t any. At this point you have been n - 1 times through the loop, so the algorithm runs in O(n).

We ought to first check the precondition, that the array is really sorted. This too can be done in O(n), so doing it doesn’t break any requirements.

The algorithm may need refinement if you are required to find all possible pairs of numbers that yield the desired sum rather than just one pair.

Is this answer superfluous when the video link has already said it? For one thing, my explanation is shorter, so if it suffices, you’re fine. Most importantly, if the video is removed or just moved to another URL, my answer will still be here.

Original Thread

By anonymous    2018-01-29

Map myArr into an object. I will add an 'a' to myArr and 'f' to orderArr.

var myArr = ['a', 'a', 'b', 'c', 'd', 'e'];
var orderArr = ['e', 'c', 'f']
var myObj = createObjectFrom(myArr);
var reArr = [];

function createObjectFrom(array) {
   var obj = {};
   var arrValue;

   for (var i = 0; i < array.length; i++) {
     arrValue = array[i];

     if (obj[arrValue]) {
     } else {
       obj[arrValue] = 1;

   return obj;  // { 'a': 2, 'b': 1, 'c': 1, 'd': 1, 'e': 1 }

var orderValue;

for(var i=0;i<orderArr.length;i++){
  orderValue = orderArr[i];

  if (myObj.hasOwnProperty(orderValue)) {
     for (var j = 0; j < myObj[orderValue]; j++) {

console.log(reArr);  // [ "c", "e" ]

Instead of looping (6*3=) 18 times, you only need to loop (6+3=) 9 times.

I made the code a little bit more complex to take duplicates into account, hence the second for loop (j).

As an added bonus, here is a video I think can be interesting for you to watch:

Original Thread

Submit Your Video

If you have some great dev videos to share, please fill out this form.