Software Engineer Becoming A Google Interviewer
It was less than a year ago since I interviewed at Google, but already I'm prepping to become a Google interviewer. Google interviews a lot of software engineers, which puts quite a load on the engineers who have to interview them, especially given that each person is interviewed by 4-5 separate SWE's (SoftWare Engineers), or "sweez" as we're called. That means that after just 6 months I was already inducted into Google's recruiting machine, to help judge whether someone is fit to be a Google SWE. Scary thought, isn't it?
There's definitely a progression you go through after starting work at Google. At first I was self-conscious and insecure about whether I really had what it takes, but now that I'm hitting a groove I feel like I know what it takes to succeed here. The tricky part is being able to detect those things in a single 45 minute interview. I do take solace in the fact that my feedback on a person is only 1 of 5 separate interviews, so my influence in hiring someone is limited. I could think someone walks on water, but the others vote them down, or vice versa. Hiring is all about consensus at Google, not what a single person thinks.
I've already started planning my interview questions. I tend to model them after real-life scenarios I've encountered, or that I think a SWE is likely to encounter at Google, and see how the candidate reasons about it. In these cases there are no right or wrong answers, just different solutions, some of which are better than others. We'll have a technical discussion about the best way to solve it, given some constraints, and then you'll probably have to code part of it on a whiteboard in your favorite language. I won't be tricky, like some interviewers are, but I'll make sure you can comprehend and internalize a complex persoalan that you might really have to solve as a Google SWE, and see how far you can run with it in the 45 minutes we have together. So it's not going to be about picking the right solution out of a hat, it will be about observing your thought process and studying how you came to the solution you did.
During the interview, be vocal, state your opinions and assumptions, and then you don't have to worry if you head the wrong way because we'll help get you back on track if you'll listen to us. That's another important thing for working at Google, is how you respond to feedback from other engineers. People say things here without fear of being labelled a dunce, because that's the type of safe environment we cultivate. When someone has a misguided idea, we discuss it factually and come to a better idea together. This is just one aspect of Google culture that I'm helping to maintain. I haven't always been good at this myself, especially because the working environment I experienced in Michigan was typically so toxic in this area. I remember asking a simple question to a colleague one time when I worked in automotive, and then he proceeded to parade me around from engineer to engineer in order to show what a moron I was for even asking it. Now I always give people the benefit of the doubt, because I know first-hand how damaging it can be to innovation when people are afraid to speak their minds.
There's definitely a progression you go through after starting work at Google. At first I was self-conscious and insecure about whether I really had what it takes, but now that I'm hitting a groove I feel like I know what it takes to succeed here. The tricky part is being able to detect those things in a single 45 minute interview. I do take solace in the fact that my feedback on a person is only 1 of 5 separate interviews, so my influence in hiring someone is limited. I could think someone walks on water, but the others vote them down, or vice versa. Hiring is all about consensus at Google, not what a single person thinks.
I've already started planning my interview questions. I tend to model them after real-life scenarios I've encountered, or that I think a SWE is likely to encounter at Google, and see how the candidate reasons about it. In these cases there are no right or wrong answers, just different solutions, some of which are better than others. We'll have a technical discussion about the best way to solve it, given some constraints, and then you'll probably have to code part of it on a whiteboard in your favorite language. I won't be tricky, like some interviewers are, but I'll make sure you can comprehend and internalize a complex persoalan that you might really have to solve as a Google SWE, and see how far you can run with it in the 45 minutes we have together. So it's not going to be about picking the right solution out of a hat, it will be about observing your thought process and studying how you came to the solution you did.
Advice to SWE Candidates
My advice for those going to an on-site interview at Google, is to study the materials that the recruiter gives you like it's your college finals. Make sure it's all fresh. It's going to make the interviews so much easier if you don't spend extra brain power trying to retrieve memories of long forgotten Computer Science lessons. Also practice coding! There are lots of resources for coding puzzles online, which I would recommend even if you normally write code in your daily job. You'll want to be able to go from concept to solution fairly quickly, and having less friction while writing code is going to be very helpful.During the interview, be vocal, state your opinions and assumptions, and then you don't have to worry if you head the wrong way because we'll help get you back on track if you'll listen to us. That's another important thing for working at Google, is how you respond to feedback from other engineers. People say things here without fear of being labelled a dunce, because that's the type of safe environment we cultivate. When someone has a misguided idea, we discuss it factually and come to a better idea together. This is just one aspect of Google culture that I'm helping to maintain. I haven't always been good at this myself, especially because the working environment I experienced in Michigan was typically so toxic in this area. I remember asking a simple question to a colleague one time when I worked in automotive, and then he proceeded to parade me around from engineer to engineer in order to show what a moron I was for even asking it. Now I always give people the benefit of the doubt, because I know first-hand how damaging it can be to innovation when people are afraid to speak their minds.
