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.

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.

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.

Wait, wait, you mean not everyone loves their job at Google? Shocking! A logical person might point out that what one person loves another person hates and thus, it is physically impossible to have a large company where everyone loves their job.

That being said, allow me to make a few points:
1) Former Googlers are not representative of Googlers.
Imagine if you set up a group for ex-New Yorkers, and then asked why they left New York. You’ll probably get an usual number of negative complaints. That doesn’t mean that most people hate New York.

Likewise, TechCrunch didn’t ask Googlers whether or not they liked their jobs – they took a thread from a list of former googlers. That is, people who didn’t love Google enough to stay, for whatever reason. So, you’re already starting with a list of people whose feelings towards the company skew usually negative.

2) The Email Thread is not representative of Former Googlers
People love complaining, particularly those who feel that they have been wronged in some way. If you start an email thread with the question “Why’d you leave Google,” you’re opening the floodgates for those who hated Google. People like me, who genuinely enjoyed their experience at Google, will stay silent. People like complaining more than praising.

3) TechCrunch was unethical in releasing the (first) names of the posters.
Though TechCrunch hid the last names of the posters, they released the first names. If your name is Bob or Mike, your secret might be safe. But, what if your name is “Gayle”, or one of the many ethnic or unusual names? Then they might as well have released your full name. Releasing people’s names added nothing to the article, but embarrassed – or potentially hurt the careers of – the posters.

4) Almost everyone at Google does like their job.
When I left Google, people were surprised. Everyone (or virtually everyone) likes it there. No one came to me and said “yeah, I want to leave too. I hate it here!” I did have several people admit to me that they were thinking about leaving as well. But, in every one of those cases, they said that they liked it, but wanted to go to a smaller company or to a different role.

5) Why I liked Google (and why I left)
I had a great team. I liked our project. I liked my manager. I was working on cool, interesting stuff.

Google is, in my opinion, the best place to be an engineer. Engineers are given more authority than I’ve seen at any other company. If you want to work on something new, there’s lots of other projects that you can easily switch to. You can work on your own personal pet project 20% of time. How many other companies let you do that?

For my 20% project, I got to teach two courses at University of Washington. It was an enormous time investment, but I loved teaching. I’ve kept in touch with many of my former students, and it’s amazing to see them to become fantastic engineers at Google, Microsoft and Amazon. I really appreciate both Google and UW giving me that opportunity.

Despite Google being a great place to be engineer, I realized that I didn’t want to be an engineer anymore. Ironically, the fact that I was so happy with everything about my job at Google made it the decision easier. After all, if everything was right about the job (team, manager, project) and you’re still not excited, the issue is probably the job itself.

Though I liked coding and considered myself fairly good at it, I wanted learn a little more about business: sales, marketing, product design, finance, accounting, etc. Google is a great place, but it’s not the place to learn those skills. I felt I could only get that education at a start-up, so I left.

“We will be taking memcache offline tomorrow morning from 9-10am PST (GMT-8) for routine maintenance. Calls to the memcache API will *not* throw exceptions but will instead return false for set() calls and None for get() calls (just like any other cache miss.) Your app should continue serving normally during this period, and
we’ll keep you updated on our progress.”

Google writes this as though it’s “no biggie – we’re just disabling caching for an hour – your app will operate as normal”.

If you’ve used App Engine, you know how ridiculous that is. You can’t operate an App Engine site without lots and lots of caching.

App Engine takes your generous daily quota and divides it up into tiny little minute or second long quotas. Their logic is something like this:

1. You can eat 2000 calories in one day.
   Hurray! That’s a lot of food!
2. It’s good to pace yourself and not eat it all at once.
   Absolutely. You wouldn’t want to pig out on breakfast and not be able to eat anything else all day.
3. Therefore, we will only let you eat 1.4 calories per minute.
   Well, f*ck. Pass me two thirds of a tic tac?
   

CareerCup gets about 10,000 page views per day – not the smallest site, but hardly the biggest. CareerCup cannot operate without heavy caching. By taking down caching, they took down my site for an hour. Not cool.

Now, Google could have mitigated this by removing the absurdly small quotas temporarily. CareerCup would have run slowly, but at least it would have run. Instead, though, users get punished for expensive-ish queries, with no chance to avoid it. Not cool.

This brings me to my next point:
Google, if you’re going to take down people’s sites, can you pick a better time than 9am – 10am? Try, perhaps, 2am – 3am? I know you don’t want to come into work at 2am. I know it’s not really Google culture to tell a team that they have to be at work and away from their families 2am. But you have to. You have real users operating real businesses, many of which are a whole lot bigger than CareerCup. We depend on you to keep our websites up.

Google: Don’t act like taking down memcache doesn’t disable our sites. And don’t disable our sites at 9am when you could’ve done this 2am.

The most frustrating part is that people don’t even see the racism and sexism. A Google coworker who had a “Hillary Nutcracker” displayed in his office window – he probably didn’t think about how that’s dripping with sexism. Nor did the Republican friend who asked online for one good thing that “Barack HUSSEIN Obama” has ever done. Nor does the other friend who asserts that Colin Powell only endorsed Barack Obama because he’s black.

We don’t see these things because we see them all too often. We’ve become immune to it. It’s time that we wake up and call these things out for the racist, sexist acts that they are.

John McCain: 158,000 hits in 2001
Joe Biden: 3,240 hits in 2001
Barack Obama: 671 hits in 2001
Sarah Palin: 0 hits in 2001.

Despite being mayor of a small town, the internet had not even heard of her in 2001. I’m not sure if that says more about Palin or Google…