It varies among the FAANGs, but in my experience Google was the worst with the algorithms above all approach. I actually had one interviewer cut me off after about a minute when I was describing an interesting problem I worked on, saying “yeah ok that’s great let’s get on to the algorithm question.”
I’m sure it varies between interviewers but the lineup I had at google clearly didn’t want to dedicate more than a minute or two to non-algorithm questioning.
It's because background/experience questions are useless.
Whenever hiring comes on up on reddit or HN I see a lot of posts that can only come from people who haven't been an interviewer much.
First rule of hiring: most of the people you talk to want your money. The candidate is selling themselves to you. They know firing people is hard and there are almost never consequences for misleading interviewers.
What happens when people are asked to talk about their prior projects, experience or really anything that isn't a highly controlled and repeatable coding question?
1. They pass off things they saw or read as their own experience.
2. They claim a team's accomplishments as their own.
3. They massively exaggerate or try to BS you in other ways.
4. They give uselessly vague answers, not necessarily deliberately.
Maybe you don't do these things, but back when I bothered asking these sorts of questions I did encounter such answers pretty frequently.
Companies have converged on live coding because that's something concrete, real and largely un-bullshittable. Yeah, toy programs in interviews aren't "real" programming but it's a lot closer to real than listening to someone ramble in a disorganised way about "their" previous project, and at the end realise you still don't know what that person actually did and what was done by others.
Your recruiter was rating you on your performance on the algorithm question, them cutting you off was actually them trying to help you spend enough time on the question.
Good point. Maybe I'm unusually generous, but when I'm in the interviewer seat, I generally try to steer candidates into territory where they can succeed. I want to give that "hire" recommendation! But I need pull enough signal from the noise to be able to support that recommendation, and ultimately I need to measure that signal using the measuring stick defined by my employer. If I didn't need to conform to that measuring stick, I'd just do interviews that were casual conversations about projects. But I need to ask certain types of questions to measure certain dimensions.
The "tell me a little about an interesting problem" question is usually there to gauge your ability to summarize a cool problem and solution down to to an appropriately sized story. Sometimes when I ask this question, candidates just launch into stream-of-consciousness expositions, talking just-in-time as the details come to their brains. At the 2 minute mark, I start thinking come on, don't do this to yourself. At 5 minutes, I will gently try to hint to the candidate to try to summarize and wrap it up. Some people just try to fill every silence with words and I have to finally firmly yank them back and cut it off. I hate to have to do it, but if the candidate can't time-manage the answer, I have to time-manage the questions.
it was for your own benefit. intro is just to get you relaxed. most of them don't even consider that part in the evaluation. so the less time spent there the more time you can spend on the algo q.
I’m sure it varies between interviewers but the lineup I had at google clearly didn’t want to dedicate more than a minute or two to non-algorithm questioning.