The Google Resume (14 page)

How to Approach

SAR (Situation, Action, Result) is an effective way to structure responses to behavioral and other questions in a way that clearly explains what the problem was, what you did, and what the result was.

Question:
“Tell me about a challenging interaction with a teammate.”

• The
  Situation
  should include a brief description of the problem. Provide enough details so that the reader can understand what the problem was, but don’t offer much more.
  

  On my last project, I was asked to oversee the work of a man who was much older than me. He was working too independently from the rest of my team and not keeping us informed, and this ended up introducing a lot of conflicting work. When I went to discuss the issues with him, he blew up at me—screaming that he had been working since before I was even born.
  

• The
  Action
  describes what you did. It’s generally the most important part of the story.
  

  I left the room to let him calm down, and talked to another teammate. She told me that he was actually just very insecure. When I came back the next day, I approached it from the perspective of his helping me. I asked him to help me with understanding his approach, saying that I needed it for some work I was doing. I then checked in on him regularly, explaining that I was confused about how to design some of my work and asked to see what he was doing. This enabled me to refocus some of his work, by asking some questions about how he would deal with specific problems.
  

• The
  Result
  explains what happened, and sometimes what you learned from it.
  

  Because I never told him he was doing things wrong, he never felt attacked. I merely asked questions and told him when I was confused. With this approach, I was able to stay informed about what he was doing, and gently guide him in the right direction. He was no longer a drain on our team’s productivity.
  

Note how I skipped over a lot of details; I never explained what the project was or what the conflicting work was. It’s not relevant to this story.

Five Example Questions

See Appendix B for potential answers to these five questions.

Estimation Questions

How many ping-pong balls would fit in a 747 aircraft? How many pizzas are consumed every year in the United States? I don’t know either, but if I did, it wouldn’t help me at all on these questions.

These seemingly bizarre questions are not about knowing the right answer, but rather about the process one takes to get there. The relevance of this to real life is debatable, but supporters of these questions argue that being able to ballpark and deduce numbers is valuable.

What They’re Looking For

Estimation questions are designed to test your skills in a few areas:

• Mathematics.
  Can you do math in your head? If numbers are too big too easily estimate (3,124 × 8,923) can you make a reasonable approximation (3,000 × 9,000 = 27,000,000)?
  
• Assumptions.
  Can you make reasonable assumptions, such as the width of an aircraft? And if you do, (such as the width of an aircraft seat), do you verbally call them out so that people can check them?
  
• Deduction/Intelligence.
  Can you logically reason through an answer using the facts that you do know?
  
• Carefulness.
  Do you understand when
  not
  to generalize? For example, if computing the average amount of money spent on clothing the United States, do you treat adults and children differently?
  
• Intuition
  . Do you have a good gut feel for when something doesn’t sound right? For example, suppose logic leads you to conclude that one million pizzas are delivered each year in the United States—do you understand that that sounds low (one pizza per 300 people per year)?
  

How to Approach Them

These questions require logically deducing an answer from what you know, and there are often multiple paths to arrive at an answer.

Imagine you are trying to compute how many interviews are conducted each year for programming jobs, for students alone. You can deduce this by calculating how many students graduate from college each year, what percentage are computer science majors, and how many interviews they each do. Explain this thought process to your interviewer before beginning:

• Number of college graduates.
  There are 300 million people in the United States, and the average life span is 75 years. If you assume people are roughly evenly distributed across each year, then 4 million people would be 22 years old. Assume that 25 percent of the United States population graduates college, so that makes one million college graduates each year.
  
• Number of computer science majors.
  Now, what percent of college graduates have engineering degrees? Based on my own high school and those of my friends, let’s assume that 75 percent go to universities (instead of liberal arts colleges). This might be an inaccurate assumption, but we’ll go with it. Of those, 20 percent of each university is in the engineering school, and 20 percent of those students are in computer science: 1 million × 75 percent × 20 percent × 20 percent = 30,000 computer science degrees awarded each year.
  
• Number of interviews.
  Of those, let’s say 50 percent go on to take programming jobs, and they interview for an average of five companies, with four interviews per company: 30,000 × 50 percent × 5 × 4 = 300,000. So, we estimate that computer science students do a total of 300,000 interviews per year.
  

The exact answer might be wrong, but it’s not the answer that counts—it’s the approach.

Five Example Questions

Design Questions

Design questions range from the normal (“How would you design a To Do list manager?”) to the abnormal (“How would you design an alarm clock for the deaf?”), and are common for many positions, especially program/product managers. They often focus on specific markets: children, deaf people, blind people, and so on.

What They’re Looking For

“We want to know if you are customer focused,” Joon, a program manager at Microsoft, says. “So 50 percent of this question is being able to put yourself in the shoes of a customer—being able to understand who the target user is. Twenty-five percent is about creativity. Can you come up with a new fresh perspective about how it might work? The remaining 25 percent is communication.”

Most candidates focus too much on the creativity aspects—coming up with crazy new features and widgets. While that can be great, is that really what you would do in the real world? Remember that interviewing is supposed to mirror your real-world performance, and in the real world, you’d figure out what the customers want and design for that.

As you answer these questions, remember that interviewers are trying to answer these three questions about you:

• Are you creative?
  Can you think of out of the box to find a novel solution to a problem, or do you pump out small tweaks on the same old stuff?
  
• Are you customer focused?
  Do you think about what the customer’s needs are, or their limitations? A 16-year-old girl has a lot in common with her parents, but she also has her own unique needs.
  
• How do you deal with ambiguity?
  Do you recognize elements as being ambiguous, and clarify them? If you can’t resolve ambiguity, how do you make a decision?
  
• Can you communicate your ideas?
  On these questions, it’s easy to wind up rambling about an endless set of features. An effective communicator will instead approach this in a structured way, wrapping up at the end with her conclusions.
  

How to Approach Them

Just for fun, let’s take the actual problem I was asked during my Microsoft interview: “Design a key fob for a 16-year-old girl.” (
Note:
A key fob is a key/remote for a car.)

Step 1: Resolve Ambiguity

Who is buying the car—the girl or the parents? Is this for a new car or an additional key fob for an existing car? Is it a regular car or an SUV?

The first question is important because it determines who the customer is: just the girl, or the girl and the parents. The second question is important because it determines what the “first-time user” setup is: will it just work, or will it take programming? The third question determines whether or not the key fab needs a button to pop the trunk.

Step 2: What Are the Basic Product Needs?

A key fob must, at the minimum, be able to unlock the car, lock the car, activate the alarm, and pop the trunk.

Step 3: What Does the Customer Need? (And Who Is the Customer?)

A discussion to have with your interviewer is: who drives the purchasing decision for this key fob? Let’s assume that the parents are driving the decision, but the girl often offers input.

What do the parents need or care about? Price and safety are probably two of the biggest.

What does the girl care about? Appearance—she wants it to look good. Durability—she’s probably throwing it in her purse or backpack.

What else might the girl or the parents care about?

Step 4: What Features Will Meet These Needs?

Appearance: Offer the item in multiple colors with a glossy exterior, and have the key fold out from the key fob.

Durability: We want a durable material, like a hard plastic, that doesn’t scratch easily.

Safety: Can we implement a “911” button on the key fab? What about a global positioning system (GPS) tracker—or is this too scary?

One other area to dig deeper into is the purchase process. Can someone “upgrade” to this type of key fab? To what extent should we optimize for this scenario?

Five Example Questions

Brainteasers: Why Are Manhole Covers Round?

Once standard at Microsoft and many other companies, brainteasers have dropped in popularity substantially. Interviewers are instead encouraged to ask behavioral or skill-specific interview questions. Unfortunately, they still pop up from time to time, either because no one can decide exactly what a brainteaser is, or because some interviewers still feel that these questions are an effective way of measuring intelligence.

Luckily, software engineers need not fear these questions: the vast majority of candidates will not face a single brainteaser. Those engineers who do will likely find that the question has a quantitative or computer science basis.

What They’re Looking For

Interviewers who ask brainteasers feel (mistakenly, in my opinion) that these questions are an effective measure of intelligence. They want to know if you can tackle a hard problem and logically work toward the answer.

Fortunately, this means that the brainteasers are unlikely to be of the “word trick” variety and more likely to be one that can be approached through logic and deduction.

How to Approach Them

Brainteasers have a wide range, so it’s difficult to offer a nice and simple path to tackling them. However, there are a few approaches that I have found work well. One or more of these might be useful in a brainteaser question:

Solve a subproblem

If you find that there is a variation or a subproblem you can solve, you might very well be on the right track. Work with this for a bit and see where you can go.

• Example:
  You have two ropes that burn for exactly one hour each. The ropes are of uneven densities, so half the rope lengthwise might take more than 30 minutes. Use the ropes to time something that is exactly 15 minutes.
  
• Subproblem: You may realize that you can time 30 minutes by lighting a rope at both ends.
  
• Solution: Light rope 1 at both ends, and rope 2 at one end. When rope 1 burns up, 30 minutes will have passed and there will be 30 minutes remaining on rope 2. Light rope 2 on the other end and start your timer. Stop your time when rope 2 burns up.