What did I learn from almost 100 Tech Interviews at Google?

UPDATE: the service is discontinued, but if you want to book time with me check the Services page

Hi Ripsters,

I recently launched a Mock Software Interview service, meant for people who are ready to apply for a Software Engineer position in large tech companies.

I’ve added a FAQ section in the service page but I realized that two of them might be worthy a post on their own, since I kept being asked those questions frequently.

I’ve extracted in this post the answer to the Most Frequently Asked Question (MFAQ?), so that I can point to it directly when asked via email.

If you don’t care about applying for a FAANG, or how to pass a Google interview you can skip. Sorry for the spam. I will probably extract another large piece of that FAQ into its own post later this week.

Enjoy!

---

What’s the hiring process for a Software Engineer in large Tech Companies?

You will have to catch the recruiter attention first.

This can happen in the following ways, ranked by increasing chances of success:

• You contact them directly. This is the good old way. Sending your CV/resume to them and waiting. This is least efficient way. The odds are 1:1000. Either you have a stellar CV, or chances are your CV is not even looked at.
• You contact them indirectly. You know someone who works there, this person believes you’d be a great fit for the company, and your friend files a referral for you. Referrals are a great way to slash the odds of being even just considered by 10x at least. This is how I started my process.
• They contact you directly. This is common if you’re already working for a renown company, and/or you have public visibility like being a huge contributor of a popular open source project, or having a popular GitHub page, or a Tech Podcast, Blog, YouTube channel and so on.

I have explored options to increase the chances of catching recruiters attention in a follow up post, check it out.

What happens after I get contacted by a recruiter?

They will introduce you to the hiring process, which is company specific. I have experience with some of them, mostly with Google.

I’m going to show you the interview process at Google here. At least, this is what used to be the interview process until early 2020.

Usually there’s a “call” phase, and an “on site” phase. Of course during mandatory “work from home” times the on site phase might just be identical to the call phase.

Each phase consists of 1-5 tech interviews, for a total of 4-6 tech interviews.

Each Tech interview will be a 45 minutes 1:1 meeting with a Software Engineer at Google. You won’t talk to “managers” or non-tech people until you’ve passed the tech interviews.

So you’re going to spend 3-5 hours being interviewed by potential future colleagues.

Each interviewer will leave an interview feedback with as many details as possible, and a hiring recommendation to the hiring committee at the end of your interview. You won’t get access to that feedback or the hiring recommendation.

The hiring committee (still a technical committee, usually composed by higher leveled employees) collects the feedback and the hiring recommendations from every interviewer and makes a hire or no hire decision.

The negative impact of hiring a bad employee is much larger than the negative impact of not hiring a good employee. Large Tech companies have an infinite pool of talented people to hire from, so they prefer false negatives (missing on a good candidate) to false positives (hiring a bad candidate).

This translates in hyper-selectivity: you need to rock each one of your 4-6 tech interviews. It’s hard to get hired if you bomb even just one of them.

This means that luck has a role. You might be the best software engineer in the world, but if you get what Steve Yegge called “Interview Anti-Loop” you won’t get hired:

I totally subscribe what Steve said (13 years ago!)

The bottom line is, if you go to an interview at any software company, you should plan for the contingency that you might get genuinely unlucky, and wind up with one or more people from your Interview Anti-Loop on your interview loop. If this happens, you will struggle, then be told that you were not a fit at this time, and then you will feel bad. Just as long as you don’t feel meta-bad, everything is OK. You should feel good that you feel bad after this happens, because hey, it means you’re human.

And then you should wait 6-12 months and re-apply. That’s pretty much the best solution we (or anyone else I know of) could come up with for the false-negative problem. We wipe the slate clean and start over again. There are lots of people here who got in on their second or third attempt, and they’re kicking butt.

You can too.

So, if you fail the interview it might just be that you got unlucky. You will know. You will feel it.

If the hiring committee members decide you “barely made it” (i.e. that you might be a false negative), they will allow you to try again in 6 months or more.

If you completely bombed it, maybe you’ll need to wait much more before applying again, or might never apply again for the same company. Try to avoid that. Only apply when you’re confident you have good chances.

Now, let’s move to the individual tech interview.

How to pass a Google Interview?

I’ve conducted ~100 interviews (as interviewer) during my 7.5 years at Google, I know pretty well what you’ll be measured against, and I’m here to help.

Mind that preparing others is (or at least was) encouraged by Google. I’m not here to tell you how to “cheat”, I’m here to tell you how to increase your odds of passing each interview by pushing you to become a better software engineer. Win-win!

To receive a positive hiring recommendation you need to impress your interviewer.

The interviewer usually doesn’t care if:

• The candidate knows about framework X.
• The candidate is fluent in coding language Y.
• The candidate solved the interview questions.

What the interviewer really cares about is:

• What is the candidate General Cognitive Ability level?
• Are they a good fit for the company?
• Would I want to work with this person on my next project?

The most important question the interviewer wants to find an answer to is the last one. Let me repeat it again: would I want to work with this person on my next project?

I want to work with you if I think you’re smart, and not an asshole. Bonus points if I had fun or I was intellectually stimulated during the interview.

Few tips follow.

Get fluent in English language. Prerequisite to be able to work together is that there are no language barriers. If your English level (writing, reading, listening, and speaking) is not professional, that would be a blocker.

Be prepared to talk about your current job/projects. Show passion, responsibility, and competence. I want to work with you if you love what you do, if I can rely on you, and if I think you have the skills to do the job. If you don’t have a project (it doesn’t have to be work related) that lights you up while talking about it, I don’t want to work with you.

At one point the interview will switch into technical, and the interviewer will ask you to address technical problems. Ask clarifying questions. Most of the time the interview question is purposefully open ended or incomplete. Show me that you’re aware of the unknowns.

Manage your time. You have 45 minutes to impress your interviewer. You don’t need to jump into coding as soon as possible (it’s a bad sign), but you can’t also afford to waste 20 minutes thinking before writing your first line of code. Yes, you’re working under pressure. And that’s when I’m more likely to discover I don’t want to work with you.

Check your assumptions while designing the solution. Or at least make sure the interviewer knows when you’re making assumptions. Communication is king. I want to see that you care about “being on the same page” before committing with time and resources.

Approach the problem top-down. Start with a skeleton of the working solution. Delegate algorithmically easy routines to functions/classes with meaningful names. Don’t implement them right away, eventually fill the missing parts with TODOs.

Address the central problem first. Your interviewer cares about how you approach the problem at hand and eventually how you put your idea into code. Don’t waste time in minor details until you have found a good enough solution for a “golden input”. If it is manageable, it is even better if you start coding with a sample input and an expected output.

Put attention on corner cases and robustness. Once solved the problem for a friendly input, take care of corner cases. Your code should be able to handle weird inputs and weird sequences of external events like failing RPCs, weird random number sequences, malfunctioning APIs… You don’t have to write unit tests (though writing just one might be a good sign you know the topic), or long error handling messages, but you must at least show that you anticipated every possible way your code can fail. If you rocked the central problem you can also ask your interviewer “Do you want me to implement SortBooksByTitle?“. Most of the times your interviewer won’t care.

It is even better if you show (even just by thinking out loud) that you can see corner cases coming while addressing the central problem. Mind that sometimes “corner cases” will require you to rethink the entire solution… which means that you should always quickly triage each corner case that you find while designing/coding your solution. Just 5-10 seconds, in the back of your brain. Dismiss it (and add a TODO) if it can be easily handled later, but alert and spend more time on it (and let your interviewer know) if you think it invalidates the overall design. Most of the times your interviewer will step in to help. You’re not expected to do rocket science in 45 minutes. But I won’t negatively judge someone who realizes halfway during the interview that they’re heading into a dead-end, and who takes steps to improve the situation with the time left.

Don’t get stuck for too long. If you’re stuck on a problem, try a brute force approach first and optimize later. Or ask for help. I’d rather work with someone who asks for help than with someone who gets stuck and do nothing.

Listen to your interviewer. Your interviewer will interrupt you from time to time to ask clarifications (which can be a sign that you’re heading to a dead end), or to help you get unstuck if they perceive you’re getting stuck (and you’re not asking for help). Listen to what they have to say. If you find their help attempt useful, put the extra information into use and let the interviewer know. If you find it misleading (rare, but possible), challenge it and provide your reasons. If you don’t understand what they wanted to communicate let them know. Don’t pretend to have understood when you hadn’t. I don’t want to work with someone who doesn’t put “being on the same page” on top of their priorities.

Think out loud. Modern software engineering is 10% creativity and 90% communication. Your interviewer needs to know that you’re not a “geeky solo developer”, even if you might be a genius in your game. Think out loud while designing and coding your solution. With this technique your interviewer will be able to evaluate your thought process, the clarity of your thoughts, your cognitive abilities, your assumptions, and they can eventually help if you’re heading in the wrong direction.

Personally, the signals I value the most in my hiring decisions are “attention to details” and “communications“. They tell me that the candidate can lead a task end to end with minimal supervision. They show both leadership and autonomy.

Master your coding language of choice. You chose the language, you should be very fluent in it. It can be ok if you don’t remember the exact spelling or the number and types of parameters of a standard library function, but don’t make basic mistakes on language syntax. I expect you use the language on a daily basis, you can’t forget a semicolon in C++ or the syntax of list comprehension in Python.

Note that this is not in conflict with “the interviewer doesn’t care if the candidate is fluent in coding language Y“. I don’t care if you know Brainfuck or Whitespace, but if I ask you to pick a language, and you pick Whitespace, I now do care a lot that you master the language.

Hint: be careful picking C++ 🙂

Another Hint: don’t pick Brainfuck or Whitespace 😀

Code readability should be hinted but not overdone. Your code should be easily recalled few day after you wrote it. Use hinted meaningful names for functions and variables, don’t overkill it. Comments are usually not necessary in coding interview. You don’t have time for long variable names. You don’t have time for context-rich error handling.

Too poor:

if (a > b) {
  return false;
}

Too rich:

if (current_number_of_players > max_number_of_players) {
  std::cout << "ERROR. The number of players is: " << 
    current_number_of_players <<
    " while the maximum allowed number of players is: " <<
    max_number_of_players << 
    std::endl;
  return false;
}

Perfect:

if (num_players > max_players) {
  return false;
}

Show curiosity for your future job. At the end of your interview, ask questions to your interviewer about their job. Ask questions about their company. They’ll be more than happy to answer your questions. And more than happy to work with someone who’s genuinely curious about what they’re working on.

Good luck 😉

If you think you’re ready to apply, you may benefit from my Mock Software Interview Package.

Check it out 🙂