What does Google ask Software Engineers?

The questions usually fall into a few categories:

• Data Structures and Algorithms: These questions can be very challenging, but typically do not rely on “advanced algorithms.” It’s very rare for an interviewer to ask you about Red/Black Tree. They could, of course, but tend not to because (1) it tests knowledge and memorization, which is not something they especially care about and (2) your interviewers, typically being at least a few years out of school, probably do not remember this knowledge.
• Coding: This may involve coding an algorithm that you just designed, or it may be to code a pretty straight-forward method. Remember that even simple problems can be tricky to code.
• Scalability: It’s very likely that at least one of your interviewers will ask you a question like “design a system to search a billion documents.” These questions do not require advanced knowledge in distributed systems; just good instincts. How would do this if there were just one computer involved? Now how do you scale that to many computers?
• Behavioral / Experience Questions: Almost all of your interviewers will probably ask you about some elements of your prior experience. You should be prepared to speak about anything from your resume.

Most people think through if they want to live in the city, but what people forget to think about is the long term impact of living in a particular city.

Suppose you’re graduating college and you get an offer from Google’s Irvine CA office. That’s fantastic. You must be really excited. Great company + great weather. What’s not to love?

But what are you going to do in, say, five years? Odds are good that you’ll want to leave the company, or at least consider leaving. Where do you go?

And there’s the problem – you’re sort of stuck. I’m sure there are other tech companies in the area, but how many? And do you want to join those companies? If you do, will you get an offer?

You may be stuck choosing between three less than great choices:

• Sticking it out at your current company for some indefinite length of time.
• Going to a less desirable company than you otherwise would have wanted.
• Leaving your friends and possible uprooting your family.

This is true for almost every field, but especially so in technology.

Even in Seattle, arguably the #2 tech hub in the US, has limited choices. If you’re a software engineer at Microsoft in Seattle, you have basically three other choices for major tech companies: Amazon, Google, and Facebook. Maybe you’ll get an offer from those companies, maybe you won’t.

The situation gets much worse if you’re not in the bay area, Seattle, or New York. It may still be worth it for personal and other reasons, of course, but that’s a tradeoff only you can make.

Somehow, many candidates have gotten the impression that the interview process is some elaborate system, and if their process is different from their friend’s, it must be a reason for it.

The truth is so much more straightforward than that, and once you get, everything will make sense. Or that’s my hope, anyway.

Here’s how the process works at Google for software engineers. We’ll look at this from the interviewer’s side and from the recruiter’s side. Although this is technically just about Google and Software Engineering, the advice / structure is largely universal across tech companies.

What Your Interviewer is Doing

This is more or less how an interviewer becomes an interviewer:

1. Training: Your interviewer takes an interview training course to teach them how to interview. Actually, they’re really just told things like, “Don’t ask the candidate if they’re married,” and “Don’t ask where their accent is from.” In other words, don’t do anything that’s going to get the company sued.
2. Shadowing: Next, they “shadow” two interviews… you know, in case they didn’t get enough of Google interviews when they were a candidate (yep, your parents were once children themselves, and your interviewers were once candidates). This lets them see the process again, freshly, and chat with the “primary” interviewer about what they thought.
3. Instruction: Then… they’re thrown into a room and asked to interview a candidate. Where do their interview questions come from? Well, where would you come up with interview questions if you were in their shoes? You’d probably bring them from you own interview experience or find them online on sites like CareerCup.
4. Evaluation: Interviewers evaluate how well you did relative to other candidates. (This point is so important that I’m obnoxiously bolding and highlighting it. If there were a <BLINK> tag still, I’d use that.) There are two interesting parts of this statement. (1) It’s “how well,” not “% correct.” It’s a multifaceted, qualitative evaluation that takes into account how you solved the problem, how long it took you, how many mistakes you made, how much help you needed, and how optimal your solution was (note the “hows”, not the “ifs”). I’ve never once made a simple statement like, “the candidate got this question correct,” because that statement doesn’t make sense for anything other than simple factual questions. (2) Performance on a question is judged in comparison to other candidates on the same question. Taking 10 minutes to solve a question optimally may be great performance on one problem, but horrible performance on another. How do you know if you did well or not? You don’t.

Note that no one here has told them what to ask, or given them a list of potential questions, or asked them to focus on a particular topic.

In other words, they have about as much interviewing training / instruction when they’re getting started as any candidate does.

Think about this. There is no system. “Recent Google onsite interview questions” are no different from “old Google onsite questions,” or, for that matter, from old Amazon phone interview questions. When interviewers ask more or less whatever they want, there’s little consistency* across a company, interview type (phone vs. onsite), or timeline.

[* There are some differences, but most of these are minor. Phone interviews will generally focus slightly less on coding, though there is still coding.  Non-web based companies aren't likely to ask about scalability, unless it's relevant for their team. And some companies have a slight preference towards certain topics, such as Amazon's focus on object-oriented design. The differences between Microsoft, Amazon, Google, Yahoo, Facebook, and Apple are covered more in Cracking the Coding Interview, 5th Edition.]

What Your Recruiter is Doing

You might not know this, but your recruiter is a person too.

Ideally, your recruiter wants to usher you through the process efficiently. If you are going to get you an offer, they want to tell you as quickly as possible. If you’re not going to get an offer, they still want to tell you as quickly as possible.

But, that doesn’t always happen because stuff comes up - reorgs, vacations, general life / work busyness.

Next time you ask why your recruiter took a while to respond, ask yourself why you sometimes take a while to respond. More often than not, it’s just that stuff came up that has nothing to do with the other person.

—-

So with all of that as preamble, let’s see if we can answer some quick questions.

I made a mistake in coding. Am I going to get rejected?

See above. Do most other candidates make that mistake (or similar mistakes)? [FYI: on a medium difficulty or higher problem, very few people solve the problem “perfectly.”

I’m preparing for a Microsoft phone interview. What should I focus on?

See above. The fact that it’s a Microsoft interview, or that it’s a phone interview, is mostly irrelevant. Look at software engineering interview questions. If there are particularly points of knowledge you’re struggling with (e.g., you forgot how to traverse a binary tree), you should study those. You shouldn’t worry too much about who is giving the interview.

How long do I have to solve an interview question?

This is sort of like asking how long you have to solve a math problem. Arithmetic problems are solvable in seconds, basic calculus problems in minutes, and complex theory in hours, weeks, or even years.

For a specific interview problem, taking “too long” might indicate poor performance, but that amount of time varies significantly across problems.

When my buddy interviewed with Apple, he was asked to solve 3 questions in 30 minutes. I didn’t even finish one problem in that amount of time. Do I have any chance?

My imaginary 10 year old niece solved 5 math problems in only 10 minutes, while my math professor has been working on this other math problem for a year now. My imaginary niece, therefore, is smarter than my math teacher.

The above question makes about as much sense as this statement.

Unless you and your friend were asked the same interview questions, you really can’t conclude anything from your experiences.

My friend heard back from Google the day after his interview, but it’s been five days and I haven’t heard a word. Is this just Google’s way of rejecting me?

Nope. Doesn’t mean a thing.

I am an experienced candidate. Will I held to the same standards and asked the same kinds of questions?

More or less, yes. Depending on who you talk to, experience either helps you on standard coding / algorithm questions (since you’ve been coding for longer) or hurts you (since you’re further away from these academicy topics).

The slightly unfortunate reality is that interviewers tend to repeat their favorite questions across candidates, so, all else being equal, someone with 30 years or experience will probably be asked the same things as a recent graduate.

However, there will probably be somewhat higher expectations when it comes to behavioral / resume questions.

How long does Facebook take to respond after an interview?

See earlier section about recruiters. Asking how long they take to respond is like asking how long you take to respond to an email. The company may target responding within a week (which is a fairly standard amount of time), but delays can happen for all sorts of reasons.

—

I hope this little window into the interview process helps you next time you wonder why something happened the way it did. Mostly, it’s just people running around doing whatever they want. Yep – that’s it. There is no system.

Shameless plug (but, hey, lots of candidates swear by it): Just because there’s no grand, overall system doesn’t mean you can’t prep for your interviews. You can and you should. Check out Cracking the Coding Interview, 5th Edition: 150 Programming Questions and Solutions. Lots of advice, and none of the fluffy “be the best you can be!” stuff. Straight, to the point, and lots and lots of cool coding problems.

UPDATE 2: Raffle has completed! Thanks for playing

If you’ve ever wondered how to navigate the Amazon forest,

Or pondered how at a Google or Microsoft interview to do your best;

If you think that being at Apple means biting more than you can chew.

Then sit back, relax, and say, “Yahoo!”

For the fifth Edition of Cracking the Coding Interview,

Is on well on its way to being out, so, “Phew!”

Countless hours have been poured into the book,

The new version is much-improved, so pray, take a look.

One five zero problems and tons of useful advice,

On how to, in the technical hot seat, be like ice.

Folks, from the author of The Google Resume,

Comes another gem this Fall your way!

So if arrays have you feeling out of bounds,

And you’re pointedly null on how “linked list” sounds

If  your worst character is brought out by strings

And recursion, tears to your eyes, repeatedly brings.

If trees and graphs along with stacks and queues

Push you to the edge, make you pop, or perturb your views

And bit manipulations along with the byte-sized brain-teaser,

Have your brain locked up – like it’s in the freezer,

Then ladies and gents do pickup this hot paperback,

For it’s sure to thaw you and put you on the right study track!

Yep, that’s right. The long awaited Cracking the Coding Interview v5 is almost out. And we’re going to be giving out a limited number of free, signed copies to lucky readers.

Want to snag your copy? Enter here for your chance to win a copy.

What’s Changed?

To be succinct, a lot! This is not your “I want people to buy a new copy, so I’ll make a few quick changes and call it a new edition” sort of thing. This is a totally re-written, much expanded, new edition.

• Grown to 506 pages in v5, up from 308 pages in v4. (And no, I didn’t pull the ol’ college make-the-margins-bigger trick.) The images on the right are not to scale.
• Much expanded sections on resume design, interview prep, behavioral prep, mastering technical questions.
• More complete sections introducing each chapter.
• 24 new questions.
• Plus, many many additional / alternative / rewritten solutions.

The focus of the book is still Software Engineering interview prep. If you’re looking for a more general start-to-end guide to getting a job at a tech company, check out my second book: The Google Resume: How to Prepare for a Career and Land a Job at Apple, Microsoft, Google, or any Top Tech Company.

Enter here for a free, signed copy of Cracking the Coding Interview.

So how do you stand out in a stack of hundreds of resumes? Ideally, you don’t. Instead, you find more creative avenues in.

I wrote an article for CNBC offering suggestions on how candidates can land an interview with their dream company. Read it here.

I wanted to tell him to do “the right thing” and turn down the dream offer, but I couldn’t. Why? Because, about seven years ago, I was in a nearly identical situation. And I did the so-called “wrong” thing.

In 2004, I was interviewing for an internship. I didn’t want to go back to Microsoft – three internships there was plenty. Google and Apple had both rejected me, though Apple told me that I was their “#2” candidate for this position. So, though I was pretty lukewarm on the position and would never join there fulltime, I accepted the IBM position. I had stopped all other interviews and had every intention of completing the internship.

Then, six weeks before the internship was supposed to start, I got an email from the Apple team. Their #1 candidate just reneged. Was I still available? This was my dream job. I loved the company. I loved the product. I loved the team. So I said yes.

The After Math

Here’s where I’m supposed to say that it caused some horrific impact on my career. Recruiters no longer trusted me. I got blacklisted. And ever since then I’ve regretted my decision, or something like that.

But the truth is that none of that happened.

IBM was annoyed, but they replaced me. Word didn’t get out about that awful thing I did. Even the other IBM recruiters had no idea what had happened. And why would they? It’s a huge company and one candidate reneging is just not that big of a deal.

But it was a big, big deal to me.

Should you renege?

I can’t – and won’t – advise anyone to renege. It can certainly hurt your reputation. You may be seen by others as unreliable. People who know about the situation may hesitate to recommend you to a company in the future. And, of course, there is definitely an unethical component to it. You’re breaking a promise, and a promise you made in a professional context. That’s never good.

At the same time, I do feel that much like an awesome sales person will recommend a competitor’s product if it’s clearly a better fit for you, an awesome recruiter should understand the position you’re in. This is your dream job – you don’t just walk away from it. (And, in fact, the Apple recruiter was supportive when their original candidate reneged – and would have eagerly interviewed him in the future.)

Additionally, unless the original offer was from a very small company or for a very high level position, the impact on the company probably pales in comparison to the impact on you. Is it really so wrong to renege?

Rather than the knee-jerk “ZOMG-it’s-wrong” response, think seriously here. What is so special about committing to a job offer?

So, what’s so special about this promise?

You shouldn’t promise to see a movie with friends, but then shop around for better plans. You shouldn’t get engaged if you’re not sure you want to get married. And you shouldn’t offer a friend a ride to the airport if you don’t have a car. But, sometimes your parents unexpectedly come to town, sometimes relationships fail, and sometimes cars break down. Life happens.

So let’s all move away from this absolutist “it’s always wrong” mindset and be honest: we break promises all the time and we’re okay with that. Life happens, and things come up. And sometimes that thing is your dream job. Why do we accept broken promises in other cases, but think that it’s always wrong for a job offer?

After each candidate completed their interview, I’d ask them how they did. Then, I’d look up their actual performance. And guess what? There was no correlation. None. Zip. Zero. Zilch.

Why is it so hard to know how you did? The answer comes in how candidates try to judge themselves, which is typically one of two ways:

Method #1: “I know I did well / poorly because my interviewer was friendly / unfriendly.”

One guy I knew, Alex*, told me he was sure he bombed his interview because the interviewer seemed so unhappy with him. Later, he discovered that he would not only receive an offer, but he was the best candidate that the interviewer had ever seen.

What Alex didn’t know is that this interviewer was not what we’d call a “smiley happy” person. And that’s the problem with interpreting performance from a stranger’s attitude. You’re comparing them to what you’re used to, not to how the interviewer usually acts.

Additionally, a good interviewer should be friendly to anyone, even a poor performer.

Method #2: “I know I did well / poorly because of how slowly / quickly / correctly / incorrectly I solved a problem.”

Imagine a professor passes back a test and you see in big red ink the score “45.” Did you do well or poorly? You have no idea, of course, without knowing how the rest of the class did. The same goes for an interview. You can’t assess your performance on a question without knowing what’s “normal.”

Interviews are not evaluated on an absolute basis with respect to either speed or correctness. Struggling your way through one problem but eventually getting the right answer might indicate that you did extremely well, or poorly. It all depends on how other candidates did (which, of course, you don’t know).

Note: this only applies to “skill based” questions, like programming and algorithms. We’ll discuss behavioral questions later.

So how can you evaluate your performance?

As we’ve discussed, you can’t interpret much from the interviewer’s reactions. However, if you could gauge how difficult a question is, you might be able to guess at how you did. One way to do this is to ask a number of friends the same questions. If they solve it in half the time that you do, then you might be able to conclude that you did poorly.

What about behavioral questions?

Behavioral questions are a bit easier to evaluate performance for two reasons:

• Interviewer Attitude: The interviewer’s attitude is a bit more meaningful here, but you should look for changes in their attitude. If your interviewer gets more engaged during your responses, or less engaged, then that might be an indicator of performance.
• Response Quality: Unlike programming questions, behavioral questions don’t vary drastically in difficulty. Struggling to respond to several of them is an indicator of poor performance. You may recognize when you really bombed a question. But, even there, I would be cautious about making assumptions.

Remember this when you’re walking out of your next interview, or when a friend tells you they did horribly. Be cautiously optimistic, because you won’t know until you know.

Bloggers – always desperate for links and traffic – have capitalized on this, with scary articles about their “nightmare interview” and “crazy questions“.  Let’s just stop this right now, shall we?

Google’s interview process is really no different from its competitors. An engineer does a phone interview or two, where they’re asked standard coding and algorithms questions.  Sometimes they’re asked to code via Google Docs, because evaluating phone coding isn’t easy.  Then, if all goes well (it usually doesn’t – that’s just how it is at any company), the candidate is brought in for a full day of interviews.  Candidates are asked a mix of standard coding and algorithms, and are asked to code on the whiteboard.  Coding on the spot might seem surprising to those outside of the software industry, but it’s standard practice.  After the interview, Google’s process is a bit different from Microsoft and Amazon’s: a candidate’s feedback is submitted to a hiring committee of engineers who makes a hire / no hire recommendation.

(FYI: I served on Google’s hiring committee for 3 years, and interviewed 120+ candidates.)

IQ Tests? I’ve never seen these. Ever.

Brain teasers? Banned.  (Of course, everyone has a different definition of a brain teasers.)  If an interviewer were to ask a candidate a brain teaser, despite the policy, the hiring committee would likely disregard this interviewer’s feedback and send a note back telling the interviewer not to ask such silly questions.

That whole “Google cares about GPA even for people years out of college” thing?  I supposed I can’t speak for every hiring committee, but I never remember my hiring committee discussing the GPA of a professional candidate.  For that matter, we were never even given a candidate’s GPA unless he/she elected to put it on their resume.

Now, let’s look at the very widely circulated “15 Google Interview Questions that will make you feel stupid” list.  You want to believe these are real questions, given that Business Insider feels like such a reputable source.  Except that they didn’t get this list from a direct source.  They borrowed their questions from some blogger (I won’t link back here) who was posting fake questions.  Now, I don’t know that said blogger was intentionally lying – he probably borrowed them from someone else.  Whatever the original source is, these questions are fake. Fake fake fake.

How can you tell that they’re fake?  Because one of them is “Why are manhole covers round?”  This is an infamous Microsoft interview question that has since been so very, very banned at both companies .  I find it very hard to believe that a Google interviewer asked such a question.

As for some of the others – “Explain the significance of ‘dead beef’”, “A man pushed his car to a hotel and lost his fortune. What happened?”, etc – I’m also highly skeptical.  If one’s a lie, why on earth would we believe the rest?  Especially if they are clearly in the banned category.

So while I know that “oh my god – Google asks candidates to reverse a linked list?” doesn’t make for quite as good SEO-link baiting material, let’s stop scaring the candidates with silly stories. And that includes you too, Business Insider. Any Google interviewer could tell you that at least some, if not all, of these questions are fake.

Want to see real Google interview questions, Microsoft interview questions, and more?  Check CareerCup.

Kumo is Microsoft’s new search engine that was released internally this month. No one seems to be talking about it much externally, and it doesn’t show up in Google Analytics under “Search Engines”. Kumo is, however, listed as a referring site for my site, CareerCup, which helps prepare for technical interviews. Almost all the Kumo users are, of course, from Redmond with a couple in Bellevue and Toyko.

Well, hey – while it’s not so nice to look for a new job while at work, at least you’re using Microsoft’s search engine to get there. Your boss must be thrilled.

But, if you’re still looking for a new job, I’ve got one for you.