As someone who has interviewed with 3 of those 6 companies and gotten offers from all 3, I think the best way to approach these interviews is to not walk in with the mentality that it's a one sided "test" where you are put on a spot to defend yourself.
In reality it's more often than not a role-playing exercise where you are pretending to be coworkers trying to solve problems together. Sure you'd be the one leading the problem solving, but being capable to explain your thought process effectively, having the ability to exchange ideas with the interviewer, and just being able to come across as a good teammate is probably more important than getting that last 5% of optimization.
This is especially more true for senior level position interviews where there are more design/architecture problems with relatively open answers. Out of these companies Google felt most impersonal and "test like", which I guess is not a surprise considering they mostly don't hire for any specific teams/positions (and we can debate the pros/cons of that all we want), and they try to eliminate human factors by the way of having hiring committees (which leads to other pros/cons).
In the end even though most still comes down to the technical skills, walking in with the right mentality and attitude actually really helps one to emphasize one's strengths.
Oh one last thing, showing confidence is also super important. But too many people mistake arrogance for confidence. In my personal experience there is no better way to demonstrate confidence than being comfortable (not to be confused with complacency) with what you don't know, and showing intellectual curiosity/eagerness to learn.
> Out of these companies Google felt most impersonal and "test like"
I had this same experience too. I went through the 4 technical interviews onsite which were all whiteboard problems. Not once did we actually talk about my past experience or rather anything software engineering related.
Unfortunately(?) I didn't receive an offer despite making it to the hiring committee. Two weeks later they called me back and wanted me to fly back out for another full round of interviews for their internal applications team! I was so burned out from studying and had a wedding coming up so I passed.
I felt a little insulted I was being asked to go through the gauntlet again when I _just_ interviewed.
>Not once did we actually talk about my past experience or rather anything software engineering related.
I had 5 rounds instead of 4 because I skipped phone screen, but I was pretty sure at least 3 of my interviewers didn't even look at my resume before the interviews haha.
I also did a lot of interviews for Google when I was there, and I can totally see why that's the way it is, but at least I tried to see each interviewee as a person with their own unique experience and I made sure to at least read the highlights of their resume beforehand.
I interview at Google and I never look at resumes - to avoid bias. I don't want to be biased by whether you went to Yale or UT Austin. My question is always a standard algo/DS question anyway.
I say the following having worked at multiple "big-5" including G.
Do you not feel any of the twist in your stomach that I feel when reading your post? That we're discarding any vestige of track record and accomplishment (that I pragmatically see as having correlated better than any other variable with effective coworkers in the past) for a readily gamable trivia question that I take some perverse pride in not having wasted time studying over the last decade? (Personally, I've spent my time doing far more actionable and applicable things such as running large distributed systems and learning how to do so more effectively while developing better patterns in that scope)
To be clear, this is not some defense of bias. This is a statement that your stated approach seems to throw the baby out with the bathwater. If I think to myself of what this interview process incentivises, it's not behavior that would lead me to be the engineer I am today, nor the behavior that I would chose in a coworker.
I'm just curious as to if there's any amount of dissonance inside G any more as to whether this is an effective way to get the people they want. Maybe it is, per their constant trumpeting of data driven hiring, and that's probably a great signal of why I didn't really feel at home there.
> That we're discarding any vestige of track record and accomplishment...
It's not your job as one of the five interviewers at Google to evaluate anything except the candidate's performance in your interview. The Hiring Committee (HC) then takes the feedback received from all the interviewers and combines it with the interviewee's résumé, any recommendations they've received, etc.
Realize though, the unfortunate result of the way this is implemented results in an interview process that ends up being perceived as quite coarse and unfeeling, and seems to filter on often capricious tests of algorithmic knowledge; Some highlights in my personal experience, writing an RB tree, and "write a regex to capture the comments in code;" simply put I never felt that my experience was even slightly under consideration. I realize the typical response from a Googler (including my friends there now) is that these things specific instances are disallowed/not recommended, and I trust they're not lying with those statements, but for whatever reason _those did happen some years back_, and I continue to hear similar attestations both here and at work.
Feel free to write off all of my frustration as a selfish fear that I won't be able to pass these gates in N years with the heavy focus on algorithms-under-pressure; it's certainly hit and miss now, and I'm open that I've been both accepted and rejected at all the places I've worked to call out how much of a crapshoot this process seems to be.
I fully acknowledge that an org of G's size has needed to make certain tradeoffs/processes, but that has tradeoffs for candidates, which can be hair-pulling when we do/have done isomorphic work at a high level.
(I should probably disclaimer that MSFTie, I have nothing particularly against G in this and all opinions are my own, but highly algorithmic interviews are a topic I've always been selfishly unsettled about)
I can't speak for GP but I'm guessing they don't feel that taking the big picture view is their role in the interview process. In some companies the interviewer is just there to be another data point for the people who make the decision, and if their role is to just ask whiteboarding question it seems like looking at the resume could be the wrong thing to do.
That is a good way to eliminate bias, but in the end, is that a good way to make sure each position is staffed by the best candidate possible?
I always pondered about that when I was at Google. We had mostly smart people, but I argue not all of them were the perfect fit for the position/skills needed.
Sure some bias are best eliminated such as what school they went to, but if work experience in general should not be discarded completely in my opinion and you can only get so much out of standard algo/DS questions, especially considering these days everyone is studying for those like standardized tests.
I literally know some CS students who just did hundreds and hundreds of practice problems and they'd ace most big company algo interviews but that doesn't really tell me if they'd be good engineers in practice at all.
That reminds me of a conversation I had with a friend who works at Amazon in Seattle.
He says they have to fire guys in his team frequently because they ace the interview process by practicing it ad nauseum but are terrible software engineers.
Sadly that’s the trade off when you want a common benchmark to measure students, but then students optimize for that benchmark instead of something else — basically Goodhart’s law.
As a current student studying CS, I find all of this “leetcoding” disheartening since it unnecessarily takes away time and deprives some people of passion.
I've found that I get a lot more signal out of asking people to actually solve a problem by writing a program than by asking them about past experience. Hence I spend most of the interview time on the former. It's surprisingly common for people to be able to talk about something in a way that sounds impressive, but then after seeing their actual coding skills you realize they were likely not a star performer on the team and were just summarizing the work that others mostly did (which they understood well enough to talk about but likely not to have done). Like, it's easy enough to learn one really kick-ass rock song on guitar, but it's another thing entirely to have written said song.
I have the opposite experience. I get more out of talking to them about past experience, mostly by asking them what they would do differently if they were approaching the problem today. This way, I know they are familiar with the problem space (they've worked on it), and I get to see how they thought about it and what lessons they learned from it. This also gives an opportunity to talk about how they think about software (discussions of failure or at least what could have been better are much more informative that successfully demonstrating some algorithm).
I don’t have that impression at all. If someone is talking about something impressive, a few deeper questions generally poke holes in whatever inflation they are doing.
Of course there should be some coding question, but I definitely look at their resume and it’s discussion just as much.
> In reality it's more often than not a role-playing exercise where you are pretending to be coworkers trying to solve problems together. Sure you'd be the one leading the problem solving, but being capable to explain your thought process effectively, having the ability to exchange ideas with the interviewer, and just being able to come across as a good teammate is probably more important than getting that last 5% of optimization.
Agreed. A lot of times the interviewer will give you hints in the right direction without holding it against you. They usually want you to succeed.
How is it "well known"? Do you have a source with concrete data? Have you asked both people who were hired and not hired if they completed/not completed their question, over a big enough sample?
Obviously, people who can't finish a problem correlate with people who aren't good candidates in general. But that's not necessary. You can have someone who shows very good problem solving and reasoning, but just doesn't make it to the end.
Thank god. I interviewed with FB, moved through the first question in 15 minutes, and assumed that it was 3 questions with 15 minutes allotted each. When he didn't give me a third one after another 15, I assumed I had spent too much time struggling with the second and he had just given up. I got the job though, just wish I had known then. I start in a few months.
In reality it's more often than not a role-playing exercise where you are pretending to be coworkers trying to solve problems together. Sure you'd be the one leading the problem solving, but being capable to explain your thought process effectively, having the ability to exchange ideas with the interviewer, and just being able to come across as a good teammate is probably more important than getting that last 5% of optimization.
This is especially more true for senior level position interviews where there are more design/architecture problems with relatively open answers. Out of these companies Google felt most impersonal and "test like", which I guess is not a surprise considering they mostly don't hire for any specific teams/positions (and we can debate the pros/cons of that all we want), and they try to eliminate human factors by the way of having hiring committees (which leads to other pros/cons).
In the end even though most still comes down to the technical skills, walking in with the right mentality and attitude actually really helps one to emphasize one's strengths.
Oh one last thing, showing confidence is also super important. But too many people mistake arrogance for confidence. In my personal experience there is no better way to demonstrate confidence than being comfortable (not to be confused with complacency) with what you don't know, and showing intellectual curiosity/eagerness to learn.