Editor’s Note: NextView recently kicked off a Boston-based workshop series on technical interviewing with Google. (Portfolio companies can contact us to learn more.) This interview covers a wide range of topics also covered in our workshops.

sauryaSaurya Velagapudi is a senior software engineer at Google, based in their Cambridge, Mass., office, right in the heart of MIT. For the company, he’s led multiple tech teams focused on products like voice and image search, Google Search for iOS, Google Glass, and Android Wear. I recently chatted with Saurya about how he approaches hiring engineers at Google and what founders can learn. We also talked about how he’d want to be interviewed if approached by a non-technical startup founder. (I’ve also tried to highlight some of the main lessons we can learn from Saurya throughout the article.)

NextView: So how does Google run its process?

Saurya Velagapudi: We have a slate of five interviews, one of which is a lunch interview. Google tries to cover a variety of topics, from the bare minimum, “Can you code?” to the more complex, “Can you design Google?” (We’re testing for whether you can design a really large system.)

The wide variety of topics covered is because of the wide variety of topics at Google. We hire generalists because the company wants to be able to dissolve one division one day if it’s not working, and then move those same people into something else that’s new or already working. Google’s strategy is to build around hiring these generalists, but that might not be the case if you’re at a startup — maybe you want someone who has a bit of experience with front-end development, so you’re fine specializing. But anything done at Google is done with that large business strategy in mind, so that’s my caveat to all this.

In terms of process: After the interview, each interviewer writes down feedback on one or two of the questions they asked, then they give a final take about whether they’d hire that person or not. That’s then passed onto a hiring committee, and they compare the feedback from all interviewers and the various scores, and they ultimately make the final decision. Interviewers are different than actual decision-makers in this way, which is done to prevent bias and give a more reasoned consideration to the actual process. That’s something that potentially startups could take into account: Use investors and technically-minded friends as second-opinion-interviewers, either by reviewing your notes or by actually meeting with candidates. These second opinions are something I feel are really, really valuable.

The thing I’ve learned doing this over and over again at Google is that we’ve gotten great at sniffing out jerks. There have been times where four out of five thought someone was great, but the fifth thought someone was a jerk. Because those five interviewers weren’t the final decision-makers, that observation matters, and that bad data point leads to a rejection.

NV: What are some basics you’d recommend to anyone hiring an engineer?

SV: There are all the typical steps like reviewing the resume and online presence, perhaps with a pass on GitHub. But whenever you do background searches, you should also be developing an idea of their story to identify who the person is. Culture is obviously important at Google and really at every startup and company today. But you’re also looking for your own biases that emerge based on that story you form of a candidate. For instance, when someone comes from an Ivy League school and says something intelligent in the room with you, you tend to think, “Ah, yes, that’s Ivy League smart.” To avoid these biases and better understand their actual candidacy, prepare a rubric of the things you want to come away with from the interview — not just a feeling but five or six things you want to know for sure about this person. What have they accomplished? How could they fit into your team? How do they view the world? Across any of these things, you want a concrete answer in the room.

It’s amazing how often people don’t get to that in the conversation. It’s very easy for someone to show up, have a great time chatting with you since some people are charismatic, and convince you that they have more skills than they actually possess. So you end up being misled by your feelings in certain cases.

Takeaway 1: Heed your feelings, but prevent your biases from guiding the decision. Balance them by preparing a rubric ahead of time in order to systematically tease out several concrete things needed to make an informed hire.

NV: When you talk about “concrete” things, what do you mean? What areas need to be addressed in the interview?

SV: The candidate’s learning style and subsequent compatibility with your team come first. Interest in the product is also crucial, as is the ability to execute and do so in a modern company. There are also a few things a founder, especially a non-technical one, should be doing in the room to better convince an engineer that their startup is a great place to work.

Takeaway 2: The areas you should prepare to cover to obtain concrete answers include (1) their learning style and resulting compatibility with your team, (2) their interest in your product, (3) their ability to get work done versus high-level architecture design only.

(Next, Saurya spent time expanding on each of these areas of emphasis.)

In terms of learning style and compatibility, I ask myself, Do they have the kind of code review style and learning style that fits well with the atmosphere of my team? There’s not one ultimate way of operating, but you should know you team and ask them direct questions about how they learn and how they handle these types of things. People learn differently — there are writers, readers, doers, copiers, and so on.

For instance, maybe everyone on your team writes documentation about what they’ve done and then everyone else reads it — great! Your team culture is established, and if you interview a tinkerer who just likes to do stuff and keep to themselves, you can recognize that they could completely upend the workflow of your team. It can be hard to gauge this second hand, but it’s something you can get a good idea about during a one-on-one, offline interaction.

Takeaway 3: Identify your team’s current learning style (especially among any existing tech talent or leaders, but also more generally across your early-stage team). Seek to match new hires to that.

In terms of interest in your product: If this person is an early hire, they need some product vision to go along with a desire to build. Do they understand what the product is for and who the market is? For instance, in Google, if I didn’t love the product I worked on, I’d have a very transactional relationship with my work. I wouldn’t think about how the code base or product or user base grows and how that affects the technical roadmap. But I have to think about that, because that’s so important, and you need someone with that kind of thinking who can understand where the product is going and translate that into technical terms to push that forward.

Takeaway 4: Early technical team members should have opinions (and want to have opinions) about where the product goes and how it will be used.

You also need to figure out if they can get stuff done or if they’re just good at telling their own story: Sometimes, you can tell that someone is very good at an interview, but sometimes it sounds very rehearsed. That’s a sign they probably don’t have the actual underlying experience. On paper, they have 10 years’ experience in the field, and they know how to speak to that. But maybe out of that 10-year period, for the past two years, they’ve been doing something completely different, so their skills aren’t up to date. One example I’ve seen is when someone executes an exercise in code and they forget a basic function of a list in Java, for instance, which is something you should remember as essential. I learned they were good at high-level architecture design but had clearly been doing only that for a really long time.

NV: What are some questions someone non-technical can ask in these cases?

SV: How many lines of code have you written in the past year? What percent of your time do you spend head-down coding versus managing or scoping product or talking to customers? How many hours in a day do you spend coding?

NV: I imagine a lot of interviewing tech talent as a non-technical leader is just getting aligned in terms of your potential working relationship. In any production-oriented job (writing, design, development, etc.), you have bad executives who poke and prod and don’t respect the process … then you have good executives who understand how to work well with this type of teammate. How do you position yourself as the latter if you’re a seed-stage startup founder?

Saurya: I think that’s right, and I think getting to that point in the interview is definitely important. First of all, it’s important for the founder to be able to say, if you join our team, you’ll be in charge of X — a user base of X people, or at least a planned user base of that many based on projected growth, or something similar. If the interviewer is a product leader, the developer might want to hear that the plan is to grow to a certain threshold, whereas the product leader might want to hear from a developer candidate that they’ve launched X projects affecting Y thousands of users. That’s a great way to know if someone has written production-ready code, by the way — if they can point to something and say, I’ve written this, and it’s seeing traffic right now.

google engineering hiring

In addition, as a senior engineer, I want to hear about the product marketing plans too. I want to know that the people in charge of other parts of the organization are as competent at their parts of the job as I want to be at mine. At Google, a lot of the teams are support teams. If I want to reach out to the marketing manager for Android Wear, for instance, the guy is there to help me do my job better. That makes developers feel like equals — a developer is there to support the rest of the company by developing the product, and their teammates are there to support that developer by doing great design, marketing, and sales. I really like hearing that kind of language: “I’d love to have you on board. You sound like you have some great ideas, and whenever you have anything you need, we’re here for you as a resource.”

Also, a lot of developers might feel they’re getting taken advantage of by more business-savvy entrepreneurs, so a way around that is to say you’re in it together. You’re here to help your developers execute on a great mission, and it’s the same mission he or she is there to help you with.

Takeaway 5: Once aligned around a mission, position yourself as a support function for technical talent in the same way they’ll be supporting you. It’s about establishing an equal relationship, not finding a short-order cook to make a thing you envision into reality. (This applies to any production-oriented role at your startup).

 

NV: If you were leading a startup, how would you try to beat Google for talent if you were interviewing the same people?

SV: The appeal of Google is about more than just money and amenities and all that stuff. What Google really offers its developers is an endless network of mentors and people to learn from. Now, that network is much different than what I’ve seen in the startup world, and founders can use that to their advantage.

Among startups, there’s this awesome referral network you get that doesn’t happen at Google. Word gets around if you do good work at one startup which helps you around the entire ecosystem after that. The people at Google can help you get better at being at Google, but the truth about the entrepreneurial community is that it helps you get better at being in the world. So the average entrepreneur’s biggest sell is to get a developer plugged into a different “internet of people” than Google can.

It does take a certain type of engineer to know that you need mentorship, and there are certainly people so egotistical that they think they can do everything on their own (though I think that’s a small percentage of the population). So for instance, people who want to solve a very specific problem — they want to do machine learning on really big data sets in genomics — have reduced the scope of what they’d consider, meaning that network effect sell won’t work as well. But founders should try to flesh out what problems an engineer wants to solve in the world, because those who say, “I want to solve problems, and engineering is my way of solving them,” might be a better fit.

You the founder can plug them into a much better network of people who already did what that engineer is trying to do, come hell or high water. Those people are better for that engineer to learn from than literally anyone else on the planet.

nextview blog subscribe