My Interview with Google

While not an original post by far, I’d like to share my experience interviewing with Google. Since Google is constantly changing their interview process, this was conducted in Spring 2019. This is a bit of a ramble so I’ll highlight key points as I go.

The Summoning

Ever since I interviewed for Google back in my college days for an internship, I get calls from them once or twice a year asking if I’m interested in applying. Sometimes I tell them yes, sometimes no, and sometimes “never call me again”. They still call. Unfortunately, this means I can’t help you get a call from their recruiters because I’ve been stuck on their radar for years, whether I want to be or not.

Key Point: If you don’t think you can get a job at Google yet, apply anyway and they will stay in touch with you as your experience starts to match what they need. It’s not creepy: it’s Google.

Anyway, one day I was checking my Gmail inbox and was inspired to go through my spam to see if the filters were too aggressive. Ironically, there was a recruiter email from Google asking to schedule a call. In their defense, it was being forwarded from my college email address (as per history above) so I guess they weren’t flagging themselves so much as my university.

I almost always agree to do a call, mostly because I one day hope to hear they’ve embraced fully remote work. I don’t think this will ever happen. Still, who knows how long I’ll be stuck on their recruiting radar?

During the call I get the usual spiel about what teams are in my area and which offices I can apply for, immigration questions, and when I’d like to interview. Normally, I’ll ask about working from home or flexible hours but this time I had another motive to interview: I was coaching people in technical interviews and figured putting myself in their place would be a good way to help them. See how altruistic I am by making the great sacrifice of interviewing for one of the top tech companies? My motives aside, I figured I’d get them to send me their list of study materials, I’d go over them with my mentees, do a phone screen, and share my notes.

Surprise! You get to skip the phone screen because your friends at Google recommended you. Ugh. I didn’t really want to do the full 6 hours of walking over algorithmic coals but fine Retrospectively, I think I need to find better hobbies than interviewing at tech companies.

Key Point: If you have former classmates or colleagues at Google, their recommendation will not only get you an interview but can also decide whether you get the job. 

“The Usual Spiel”

As mentioned above, recruiters tend to follow a script and Google is no exception. Below are the points covered:

  • Locations of new and existing offices in your area as well as questions about where you would like to work. Key Point: An interview anywhere for Google is good for any location at Google, including any country or continent.
  • A list of teams hiring in your area along with their current projects.
  • New company initiatives around benefits, diversity, etc.
  • What the interview process looks like:
    • (Usually) a phone screen
    • An on-site interview for 6 hours with 5 hours of technical interviews and 1 hour of lunch with a Googler
    • Judgement – tentative offer or rejection
    • Requests for references, preferably internal to Google but also external
    • Selection of a start date
    • Team rotations/team shopping: you spend 1 – 2 weeks on a team to decide whether you want to work with them or not
    • Team selection and assimilation into the Borg
  • Promises to send follow up emails and interview materials

Key Point: I was told after Spring 2019 there would be 4 technical interviews and 1 ‘soft skills’ interview. 

When and What

First Email: Study Materials

The first email sent after the call was to thank me for my interest and provide an impossible amount of material to review. Oh, but don’t worry, this is probably stuff that you already deal with day to day. Right. When was the last time I not only used but implemented a priority queue backed by a min/max heap? Never. This is the same deal with Facebook, Microsoft, and Amazon interviews so I didn’t worry about it too much. It’s just a matter of prioritizing topics against time.

For System Design, this is a great example of prioritization based on time: https://github.com/donnemartin/system-design-primer

How To Prioritize?

If I don’t have much time, I’ll jump right into practice problems and do 50/50 problems and reviewing concepts. If I have some time, I’ll review all data structures and algorithms first then do as many practice problems as possible. With extra time, I will review all operating systems and system design concepts. I almost always skip discrete math and the whole NP-complete business. This time around I had extra time so when I wasn’t doing problems I was reading through system design books.

Key Point: If you feel you cannot achieve “excellence” or “proficiency” in at least the data structures and algorithms concepts, I recommend requesting a follow up in 3 – 6 months to allow for more study time. There’s no harm in failing but if you definitely want the job this time around then set yourself up to be as successful as possible.

The Materials: Copy Pasted From The Email

PREPARING FOR YOUR ON-SITE INTERVIEW

This is a non-exhaustive list of topics that may or may not be covered during your interviews. Its intent is to guide your study and preparation.

INTERVIEW PREP BLOGS & VIDEOS

INTERVIEW APPROACH

  • The interviews focus on coding, data structures, algorithms, computer science theory, and systems design (systems design questions normally reserved for applicants with 5+ years of industry experience)

  • Likely additional topics include: hash tables, heaps, binary trees, linked lists, depth-first search, recursion (think CS 101 – concepts that everyone knows but doesn’t always quickly come-to-mind).More information on Algorithms

  • Many questions are open-ended and are deliberately underspecified to see how you engage the problem. Verbalize your thought process as you work to understand, approach, and solve the problem. Interviewers want to see which areas you find most important to the problem’s solution. Think about ways to improve the solution you’ll present. In many cases, the first answer that springs to mind will need refining. Verbalize your initial thoughts to the question. Ask clarifying questions if you don’t understand the problem or need more information. As a rule: efficient solution > brute force solution

  • For in-depth study – 3 highly recommended reads from Sr. Engineers: (1) “Programming Interviews Exposed: Secrets to Landing Your Next Job” (2) “Programming Pearls” and (3) “Cormen/Leiserson/Rivest/Stein: Introduction to Algorithms”

SAMPLE TOPICS

  • Coding: construct / traverse data structures, implement system routines, distill large data sets to single values, transform one data set to another

  • Algorithm Design / Analysis: big-O analysis, sorting and hashing, handling obscenely large amounts of data. Also see topics listed under ‘Coding’

  • System Design: features sets, interfaces, class hierarchies, designing a system under certain constraints, simplicity and robustness, trade-offs

  • Open-Ended Discussion: biggest challenges faced, best/worst designs seen, performance analysis and optimization, testing, ideas for improving existing product

HOW TO SUCCEED

  • We believe in collaboration and sharing ideas. Most importantly, you’ll need more information from the interviewer to analyze & answer the question to its full extent

  • If you don’t understand something or are stuck, please question your interviewer and ask for clarification and/or a hint

  • When asked to provide a solution, first define and frame the problem as you see it

  • If you need to assume something, verbally check it’s a correct assumption

  • Describe how you want to tackle solving each part of the question

  • Always let your interviewer know what you are thinking as they are just as interested in your thought process as the final solution

  • Finally, listen – don’t miss a hint if your interviewer is trying to assist you

TECHNICAL DOMAINS (understanding these concepts is necessary to succeed in a Google Interview)

  • Algorithm Complexity: Understand big-O complexity analysis and Big-O notations (aka – “the run time characteristic of an algorithm.”) Working through practice problems is key

  • Sorting: Know how to sort. Don’t do bubble-sort. Know the details of at least one n*log(n) sorting algorithm, preferably two (say, quicksort and merge sort). Merge sort can be highly useful in situations where quicksort is impractical

  • Hashtables: The single most important data structure. Be able to implement one using only arrays in your favorite language with time limitations

  • Trees: Know about trees; basic tree construction, traversal and manipulation algorithms. Familiarize yourself with binary trees, n-ary trees, and trie-trees. Know at least one type of balanced binary tree, whether it’s a red/black tree, a splay tree or an AVL tree, and know how it’s implemented. Understand tree traversal algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder

  • Graphs: There are 3 basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list); know each representation and its pros & cons. Know the basic graph traversal algorithms: breadth-first search & depth-first search. Know their computational complexity, their tradeoffs, and how to implement them in real code. Time permitting, study fancier algorithms such as Dijkstra and A*.

  • Other Data Structures: Know as many other data structures and algorithms as possible. Start with the famous classes of NP-complete problems, such as traveling salesman and the knapsack problem. Must recognize them when an interviewer asks you them in disguise. Find out what NP-complete means

  • Mathematics: Some interviewers ask basic discrete math questions. At Google we are surrounded by counting problems, probability problems, and other Discrete Math 101 situations. Know the essentials of combinatorics and probability. Be familiar with n-choose-k problems and their ilk – the more the better

  • Operating Systems: Concepts to know: (1) processes, threads and concurrency issues. (2) locks, mutexes, semaphores, and monitors (3) deadlock & livelock and how to avoid them (4) resources processes needs, and thread needs, and how context switching works, and how it’s initiated by the OS and underlying hardware (5) scheduling (6) multi-core: the fundamentals of “modern” concurrency constructs

Second Email: Time and Place

For scheduling, you are going to have to take a day off work (if you are currently working). You are asked to provide 3+ days in the next 4 weeks when you can interview. You will get an email confirming the time as one of those days you selected. I usually see 9 am or 10 am start times with 3 pm or 4 pm end times. The email includes instructions on parking, time to arrive, where to arrive, who to ask for, etc. This will vary based on which office you’ve selected for your interview location but read the whole email. The location I went to had a very strange parking situation so I needed to show up 30 min early. Finally, upon confirmation of the date, you need to file a formal application with Google using one of their tools.

Key Point: Read the whole interview confirmation email.

Interview Day

Key Point: Bring what makes you comfortable. As below, I like having physical pen and paper to take notes during the interviews.

As they say in the email, wear what you are comfortable with. Bring whatever you think you might need. I recommend bringing a notebook and a pen. I like to write down the names of my interviewers, which team they worked on, how long they’ve worked at Google, and notes on the questions they asked. I also bring chocolate and Tylenol because interviews are stressful.

Why write down that information? One or more of your interviewers might be a future teammate. Also, if you are not extended an offer, you can keep the questions to understand where your gaps are. Finally, if all your interviewers have been at the company 2 years or less, maybe that’s something you want to ask your recruiter about – what happens to employees after 2 years?

Things you might not expect:

  • Interview rooms can be really hot, like “I hope they don’t notice how much I’m sweating” hot or cold enough to feel like you’re directly in the path of the industrial air conditioner
  • You’re not going to be in the same room all day so make sure you don’t bring so much stuff that you’ll be uncomfortable carrying it around from room to room
  • You’ll be waiting for up to 30 mins from the scheduled “start time” of your interview – bring something to read or do
  • You will be given the opportunity to code on a computer or whiteboard. You can choose what you’re most comfortable with at each interview.

Impressions and Amenities

DISCLAIMER: I have pre-existing negative feelings about large tech companies. Have your salt at the ready.

The good things about Google corporate offices are fairly well known: free food, gyms, nap nooks, laundry, commuting cars/buses, etc. I found all my interviewers easy to talk to. In past Google interview, there were a few “hard to deal with” interviewers and I was happy not repeating that experience. The amenities were clearly well kept and organized.

The negatives are similar to other large tech companies (Amazon, Facebook, and sometimes Microsoft). All these things are what I heard from my interviewers:

  • There are too many people in the offices so you need to come in earlier and earlier to find parking
  • You have to avoid the cafeterias during lunch time because of how crowded they are
  • Organizations are constantly being moved under new leaders and moved to new buildings, sometimes in other cities
  • The offices are being shifted around to support the high populations so often that you always get lost

A few additional things stood out. First, there was a nap nook. Nap nooks are meant as small rooms or enclosures where you could take a nap during work. I’m used to seeing them as very small rooms about the size of a walk-in closet with a light, maybe a recliner or a cot, and enough room for prayer mats. This is similar to what I encountered:

via-we-heart-it_rect540 alcove bed
Credit to http://concordgreen.blogspot.com/2010/12/in-praise-of-bed-alcoves.html

Kudos for making the decor look, ah, “homey” but this makes me just a little bit uncomfortable. Can you imagine sitting next to your manager on that couch for a quick chat? Ew.

The second thing that stood out was how one interviewer described the difference between this location and Mountain View.

People here are a lot more interested in work-life balance and family rather than getting work done quickly.

I see. I guess it’s good that I’m not applying to work in Mountain View. Or maybe I want to burn out like a supernova: a high energy, crazy-bright star, with a short life on its way to complete destruction. But a rich supernova.

Coding Questions

As a friendly reminder, our interview questions are confidential, so please keep things under wraps.

~Google

I won’t tell you the questions but I will share the areas you would need to study to answer them.

Question 1: Card Game

  • Object-oriented design
  • Multi-dimensional arrays
  • Randomness
  • Multi-threaded access to shared objects (I used the word “semaphore” at some point)

Question 2: Merge K Lists

  • Greedy algorithms
  • The merge k lists problem – this wasn’t the question but I really kicked myself for skipping it during my practice after this interview

Question 3: Empire Building Board Game

  • Binary trees
  • Graph search
  • Linked Lists vs. Arrays

Question 4: I Heard You Like Trees

Question 5: Design a Cache

  • This was actually the question

The Result

As of writing this post, I do not have the result of the interview and I suspect I won’t for another few weeks. Google is infamous for long deliberation on candidates. I’ll update this post with the result when it makes it to me.

Defensive Interviewing

If you’ve interviewed anywhere in tech, you’ll hear the advice or instructions to have questions ready for your interviewers. Which questions do you ask though?

Hopes and Fears

Everything boils down to what you want to happen and what you don’t want to happen.

Hopes

  • Belonging
  • Achievement
  • Trust
  • Growth
  • Variety
  • Money – this one is salary negotiation so I’ll skip it

Fears

  • Exploitation
  • Rejection and isolation
  • Boredom
  • Stress

Now that we’ve got the heavy stuff out of the way, how does that translate into interview questions?

Belonging / Rejection and Isolation

A sense of belonging contributes to happiness. A sense of happiness contributes to productivity. Thus, you will be more successful if you feel like you belong. Even when your job is really bad, if you feel like “you’re all in it together”, it’s easier to pull through.

Questions:

  • What is the diversity of your team?
  • Are there people like me on the team?
  • Who will be my mentor when I join?
  • What are some social activities we will do as a team?
  • What communities for technical and non-technical topics exist at the company?
  • Do you feel like you could be friends with some of the people you work with if they weren’t your coworkers?
  • How often will I have 1 on 1s with my manager?

Scenario one: a diverse group of people who welcome new members with an automatic support network of a mentor and bond through shared interests. Scenario two: a monochromatic team of humorless people you can’t identify with that leave you to struggle alone and generally don’t talk to each other. Take your pick.

Achievement, Growth, and Variety / Boredom

Boredom is bad. Boredom is similar to stress. You disassociate and (eventually) become depressed or destructive. Work that slightly exceeds your skill set is ideal for maximum engagement and learning (according to Emotional Intelligence by Daniel Goleman). You can keep things interesting through promotions, new skills, or role changes. Additionally, if you want to climb the ladder, make sure there are at least a few rungs.

Questions:

  • What does promotion look like here?
  • How long does someone like me stay in this role before being considered for promotion?
  • Do you support 20% time or time to grow professionally via hackathons, conferences, or tech talks?
  • Does this company encourage moving between teams if there are other opportunities available?
  • Does this company support role changes and what does a successful role change look like?

Trust / Exploitation

People typically know when something they are going to say will put people off. The managers and recruiters of the world know this and choose to omit or mislead when it comes to that information. Instead of trying to catch them in a lie, probe to fill out the truthiness of their answers. This was taught to me as “peeling the onion”. In this metaphor, the more you peel the onion, you might get more onion or, I don’t know, a radish.

Questions:

  • What tasks are you working on right now? Ask for specifics.
  • What would you say is the key success criteria for your job? Why?
  • What is an example of the first project (not task) I will be working on? How is this important to our customer?
  • How involved will I be in designing new features and choosing team priorities? How often will I get a chance to influence project direction?
  • How many people with my role are on the team? (the more there are, the more reliable their answers)
  • If I am interested in working on something in particular, how would I go about getting assigned to the project? Give me an example of when you did this.
  • When something goes wrong, what is the recovery? Maybe a bug is pushed or a customer says the feature was done wrongly or a service goes down. Is there a retrospective? Does it get fixed right away?
  • Who is responsible for operations, customer contact, and project planning?

This is probably the hardest one to detect. Often, teams want to hire someone to do the housekeeping, like bug fixes, legacy maintenance, mindless migration, and minor management activities. You need to ask questions to confirm there is enough “meaty” work for you and housekeeping is spread evenly or kept to a minimum.

General Red Flags

  • Your manager has been in the company or sub-org for less than 6 months. This usually means they haven’t been through a performance cycle and there is a risk that they aren’t sure what it looks like for you to do a good job. If you don’t know how to do a good job, you might not be rewarded for the work you do. However, after about a year to a year and a half, most managers figure it out.
  • You are being hired for a “generic” position. This is basically job roulette. It’s worked out well for me in the past but it’s also opportunity for you to be placed where no one else wants to be.
  • There are a lot of buzzwords. If something sounds good but doesn’t tell you anything specific, they might be trying to hide something. “We do machine learning” is the equivalent of saying “we develop software”. It generates excitement but doesn’t tell you that you’ll actually be a code monkey for the scientists who do the “real” machine learning.
  • “We have no operations.” This is very job dependent. I’m talking about services, cloud, and larger software applications. If you have no ops, you have no usage or no customers. On the other side, you might have a lot of ops but someone else deals with it. This is an organizational anti-pattern and guarantees someone will strongly dislike you on that ops team. Not fun.
  • “We are a rapidly growing team.” This can genuinely be exciting if you are joining a team of smart and capable people coming together to create a new great thing. Or this could mean the managers are throwing bodies at a problem in such a way that creates stress, confusion, and general unhappiness.

It’s Too Late

If you’ve found yourself in a job where it didn’t live up to your expectation, first, figure out which questions to ask next time you interview. Second, tell someone it wasn’t what you expected and firmly ask to be placed somewhere that meets those expectations. Third, as soon as you can, decide whether you want to stay or go. Be intentional about what job you are choosing to do. By taking responsibility, you give yourself control over your situation and who doesn’t like control?

Good luck interviewing!