A former Google hiring member on how to stand out in interviews

  • Carter De Leo was a software engineer at Google for eight years and a member of its search committee for four years.
  • It says knowing your fundamentals and practicing talking about your process while describing a problem on a whiteboard.
  • This is the story of Carter De Leo, told to journalist Dorothy Cucci.

As a software engineer at Google for eight years, I volunteered to be part of its search committee as soon as I was eligible. You had to be at least a Level 5 (which is a senior level employee) and have conducted around 30-50 interviews.

For those who do not know, the hiring committee is the penultimate step before a vice president signs and gives his final approval to the hiring. It was quite rare for a vice president to overrule a hiring committee’s decision (although it does sometimes happen), so the committee was the last decision point for most applicants.

Not many people wanted to do it because it takes a lot of time and effort on top of your usual daily work. My hiring work counted as my “20% of the time” as well as my contribution to the community, and it burned an entire day each week. But I felt it was a direct way to enforce quality standards in the company, and I took my job very seriously.

In my four years with Google, I shortlisted hundreds of applicants. Many were very easy decisions, and I’ve noticed a lot of the same trends over the years, good and bad.

Here is what will impress the hiring committee and also what will make them refuse you.

1. Don’t prepare for “puzzle questions”

When I read about the online interview process over the years, I got the impression people thought we were trying to ask trick questions. It is never our intention.

In the early years of the business before my time, we were well known for asking puzzle-type questions like, “How many ping-pong balls fill a 747?” It didn’t matter if the candidate got the right answer; we were just trying to get them to reason about something out loud.

But we decided that these kinds of questions were bad enough for testing candidates, so we actually banned them. We have so little time with each candidate that it was silly to watch them fumble around trying to figure out the question when they could show off their skills. It’s about maximizing the information we can get.

In addition, these questions do not offer a good distribution among candidates of different abilities. Instead, we would see a pretty binary result of “They didn’t know what to do” and “Yeah, they got somewhere,” without a lot of additional information.

Trick questions are not useful for the candidate, and they are not useful for the business.

2. Show your process

When the committee was split over a candidate, it usually boiled down to a question of technical depth – whether the person was giving superficial or deep answers.

A good interview question should have at least three to four different levels of possible answers, so that you can clearly detect variation between candidates and how well they answer the question.

Something like “Pretend to make a URL shortener.” What kind of components would you need in the system? Is a broad question because the candidate has a good opportunity to showcase all his knowledge. We want to see both the breadth and depth of an issue like this.

For scope, does the candidate understand what parts are needed and how they should interact at a high level? I would like to see the full chain of components that we would need to manufacture. Does the candidate consider that we need a database for storage? What do they want it to look like? We need servers sitting in front of it. Do they understand that in a large-scale service, you can’t have just one? How do they want them to share the work without stepping on each other’s toes? Go through it step by step, until we come to the web page that the user sees.

For more depth, I would like the candidate to develop one of these elements that they are most comfortable discussing. No one is an expert in every room. Maybe their background is in front-end work and they want to describe how they would approach it. Maybe they’re a database person and want to dig into the schematic. It doesn’t matter which – we just want to see them zoom in somewhere.

It is not necessary for the person to give the best solution – in fact, the vast majority of successful applicants do not. We expect them to justify why they took the approach they took and that they have been able to show that they have in-depth knowledge.

3. Don’t be afraid to be creative

A lot of people also think that we want you to be able to regurgitate a class discussion, and that is not true. As I said before, there are always multiple answers. Some will be better than others, but you are not rated for getting the perfect answer – this is your thinking process.

Sometimes a candidate would produce a solution that they had never seen before, which was always exciting, although not necessarily optimal. Even though it wasn’t the best, it was still very new. These people almost always passed.

This is in part because someone who offers a new answer in one interview also tends to do well in others – it would be unusual for someone to have a flash in a bottle in one place and then d ‘be mediocre elsewhere.

Also, at Google, we often posed new problems. In many small business software engineer roles, you primarily select and apply the best pre-existing tools for the job. There are still some at Google of course, but we ended up needing to build our own tools quite often for issues that no one had encountered before. New thinking is useful here.

4. Focus on the basics

If you want to stand out from the crowd, you need to know your fundamentals inside out; if they are asked in an interview, it shouldn’t take you long to think about it. When I prepared for my own software engineering interview, I used a very simple book on structures and algorithms, and I think that’s all you need to do to prepare.

One thing I imagine the candidates did (because they probably thought we would like it) was talk about the specific technologies they would use. We would ask them how to solve a problem and they would say, “Oh, I have used this very particular database product and I know it very well”. We hardly ever wanted to hear about specific tech, although candidates probably thought it was a good thing to show off.

It’s not that showing technical knowledge is necessarily a bad thing, but we were really looking for candidates with a good general background. The same thing happened for people who were very picky about the perfect master language. It’s kind of a waste of time in an interview, and it shows that you’re focused on the wrong thing.

5. Be comfortable thinking out loud

Another great way to prepare is to do mock interviews. Obviously, not all applicants have access to a current Google engineer, which is ideal. But it is also very useful to practice speaking aloud to someone when you are in front of a whiteboard to solve a problem.

Sometimes, while candidates were pondering a question, they wouldn’t say a word for minutes. This is valuable time wasted, especially when the interviewer does not receive any signals from you.

Learning to speak and speak throughout your process is extremely important for this reason.

6. Expect behavioral questions

Other reasons we turned down applicants were social or behavioral reasons. For most of my hire, we didn’t ask explicit behavioral questions, only technical questions. But in my last year, we decided to add questions like, “Tell us about a conflict with a colleague or manager, and how was it resolved?” And “Tell us about a time you failed. What did you learn from it? “

It was always a big talking point because sometimes we would see red flags. Maybe someone seemed argumentative or failed to catch the clues.

So I can’t say that personality isn’t important – it was not uncommon for a candidate to have a personality conflict with one of their interviewers. The ability to take clues and read the play is something we often use as an indicator of how well you collaborate with your coworkers. You should be able to have and build a positive relationship with anyone.

7. Don’t overthink

There is no secret to being hired at a company like Google. The hiring committee is not trying to cheat you; he wants to give you the opportunity to showcase your skills to the best of your ability.

If you can show that you understand why you are making the decisions you are making, instead of just throwing the things you learned in class on the wall, this is the biggest difference between whether or not you will be considered a successful candidate. or not.

If you’re hiring or recruiting for big tech and want to share your tips, email Dorothy Cucci at dcucci@insider.com.


Source link

Comments are closed.