I don't disagree with this, but (to the best of my memory - this was in 2011), when this initial phone screen was presented to me, it was presented with some amount of "We want to figure out what you're good at so we're having the right people interview you for the right roles." Which is to say, I suspect that him failing out halfway through this screen was because of combativeness / personality, not phone screen performance per se.
> You can't ensure that there will be no hurt feelings ever, but ideally the candidates you fail don't go around talking about how poor your interview process is.
I think I disagree with this though - there are certain people who are going to be predisposed to complaining about things that don't go their way, and you want to make sure you fail them as early as possible. At a company small enough that its strength is the CEO's coding abilities, a curmudgeon with significant raw technical talent can do very well. At a Google-sized company they just can't.
Also, this quiz is given by non-technical recruiters just to get a guage on how tech-savvy the candidate is. If I remember correctly, the passmark is 6/10.
The questions (when not misremembered) are very precise in their wording, and recruiters are given a pretty comprehensive list of correct answers.
I'm sure a few great candidates fail this stage, but that's the nature of hiring. Google gets a lot of job applications per day, and a first stage screening like this needs to be able to be executed by non-technical staff in a few minutes. Other companies use online tests, which tend to take the candidate more time and are easier to cheat at.
Having real talent and having to basically navigate terrain of those with less skill than you and yet, oddly enough, more power, is very frustrating. These people can knock orders of magnitude off development cycles, and make subtle decisions that affect your product years in to the future.
If anyone feels even remotely insecure because of your prowess you are shot down. I was pushed out of Microsoft just for accomplishing a task that was supposed to be impossible "because a senior engineer said so." In other words, I did my job (I wasn't aware it was supposedly impossible) and then a management chain became incredibly uncomfortable and dumped me.
You might say I'm the problem...I point to the stack of clowns that said it couldn't be done and go...yeah sure.
These people can also introduce orders of magnitude into development cycles, and make subtle decisions that affect the product in negative ways years into the future. I seem to have made a career out of cleaning up after these people, and I have no sympathy for them. An amazing research project or tech demo isn't an amazing sustainable project.
> I was pushed out of Microsoft just for accomplishing a task that was supposed to be impossible "because a senior engineer said so." In other words, I did my job (I wasn't aware it was supposedly impossible) and then a management chain became incredibly uncomfortable and dumped me.
When I've seen this, it's usually because the task can be done 90% in a straightforward way but 100% is impossible, and the person doing the task thinks that doing it 90% counts, possibly because they're unaware of how important the the remaining 10% is, and no amount of explanation will convince them they're seeing the problem wrong. Then they should be let go, not because they did the task, but because they're unable to understand requirements and wasting both the time of others and their own time.
... all that said, there's a very good place for this type of person: small businesses. That seems to be where the author of this article is, right now. He's got some weird ideas about how computers work, that are probably not right, but maybe they are right and he's a genius and we're all years behind him. He's built a product around those ideas. If he can sell the product, more power to him. If he can't, and the product is meeting 90% but not 100% of his customers' requirements, they just don't buy and go to a competitor. No awkward conversations about firing, no wasted time trying to get their existing hire to perform instead of hiring people who can do the job, etc. And the burden of getting him to learn how to understand requirements is entirely on him and not on anyone else.
This kinds of defeat the purpose of the screening interview though doesn't it? The point is to not disturb an engineer when 99% of the people that are being screened are unqualified.
I would not ask the questions listed in this interview. But, I'm not a recruiter. I think it's safe to say that the average recruiter has a better understanding of their objectives and constraints than I do, and is better able to judge what types of questions to ask during an initial screen than I am. Those questions may not be optimize for the same thing any given candidate is optimizing for.
> You can't ensure that there will be no hurt feelings ever, but ideally the candidates you fail don't go around talking about how poor your interview process is.
People in the original thread in 2016 said much the same, arguing that people would no longer want to work for Google. It's 2018 and Google is still not having any trouble attracting engineering talent. Seems like offering high salaries and interesting work matters a lot more to the average candidate than whether the prescreen has a view suboptimal questions.
That's an odd assumption to make, that the average recruiter is competent, for a community that assumes the vast majority of their fellow engineers can't code.
If you're talking about FizzBuzz, that's about candidates, not stably employed folks. Candidates are by definition a pool that favors people that haven't been hired already, except for people new to the industry. https://www.joelonsoftware.com/2005/01/27/news-58/
(Also, there's no rigorous evidence supporting the hypothesis that most people in the industry or even most applicants can't write FizzBuzz, as far as I know. But that's not quite relevant to your question about perception; I do admit there is a perception that the hypothesis is true.)
Good technical recruiters are rare, and seldom work for big companies like Google, Facebook, Amazon, Cisco, (Yahoo), IBM, etc. Most of them read questions from a script, and then believe that the map is the territory.
Is this really true, though? Are they losing out on more top end candidates?
There are other places with interesting work and big paychecks. Some of them aren't building reputations for annoying interview processes.
If Google is losing out on good candidates, it's going to be either because of false negatives in the interview process, or ongoing engineering culture concerns (which is roughly why I declined the Google offer I got last year), not because of people self-selecting against annoying interviewing processes. Even this blog post itself is written in the form of "Here's what you need to know to get past the process" - i.e., even this guy assumes people still want to work at Google and work around their process.
(How cool, I get multiple downvotes which means that the average non-important people (I could use stronger words, but you do know where you fit) don't agree, which makes me flattered. Thank you.)
(The other guys upvoting me, thank you, you are somehow restoring my faith, that not everyone is a zealot)
To me, it feels like the Facebooks and Googles of the industry (by which I encompass other ad tech firms) are the 'banks' of 10 years ago. A few years ago, and I bet still today, there were/are a lot of new grads and experienced techies saying openly that they'd not want to work for a bank. Hopefully a similar spurning happens here.
Have a source for that?
Of course, Google is one of the top names in tech and has already employed some luminaries many developers would love to work with, so I'm sure that they get some leaway to treat their interviewees poorly, but for people with other good options, there's not a lot of appeal to being sucked into one end of a very long, very painful funnel.
Having said that, Lazlo Bock has some interesting things to say about hiring in an organisation like Google.
Also, I linked money since the parent comment talked about finding interesting ans similar paying role as Google's.
(For complicated reasons I actually spent about May through July of last summer with an offer open, and talked to 5 or 6 different teams through that process... and at the end of the process when I called to decline, I was told that headcount had shifted for Q3, the team I'd most recently spoken to had lost their open headcount, but there were other teams that had now had open headcount and might be interested in talking.)
Except for all of the other big tech companies?
Many of which have the same type of interview processes?
Hell, Facebook sometimes asks two coding questions per interview round, which is 45 minutes long as I recall. They seem to expect perfectly compiling code.
If you're not doing coding competitions or practicing on Leetcode or other sites of its ilk, where you learn to regurgitate a Knapsack problem solution or Russian nesting doll problem in ~15 minutes, you're going to have a hard time getting into many of the big tech companies unless you went to a university that teaches using this style.
I've seen the sort of problem that required dynamic programing combined with a binary search for the algorithmically optimal solution in a phone screen!
I lucked into an easier interview loop, crushed it, and got hired and performed well at one of these types of big companies.
But I dread jumping ships because of this daunting interview hoop we jump through.
I've already tried to leave and got smacked around in the two interviews I went through because of nerves. I knew the problems, I knew how to solve them, but for some reason I just didn't perform well and couldn't really cross the finish line.
These people are un-prepared for the interview, this question is easy and not insulting. Anyone doing tech interviews of any sort should be able to answer it, yet most don't.
I suggest two things, 1) start doing competitive coding exercises, there are lots of problem sets available, search for "online judge" [0] and 2) practice interviewing under real conditions, use pramp [1].
Being able to ace a top-k company interview is an ego boost that reduces stress levels day to day.
Leetcode, SPOJ, and others are how I landed my current job. What was most helpful for me was actually going back and reimplementing all of the fundamental datastructures and algorithms. E.g. binary search tree, skip lists, BFS, DFS, different sorting algorithms, etc. From then, it was also helpful to remember where these were being used in the real systems I interact with.
Solving the interview problems is typically not my problem. In every round of my Google and Facebook interviews, I knew the optimal solution--confirmed by looking up the solutions after the interview. However, I happened to choke under the interview pressure and turned into a fool. Test anxiety--interview anxiety in this case--is a real thing.
What I am going to do in the next round of interviews is apply for dozens of companies I just don't care about, fail a bunch of interviews to get used to the pressure again, and then re-apply to the companies I actually care about.
I’ve worked at Google, and engaged with Google recruiters over the years (who didn’t even know I was an ex-Googler). Talking to their recruiters does feel like talking to chatbots and can feel quite dehumanizing, in big and small ways. I’ve also worked at small start-ups that did world-class recruiting, or at least several classes better than Google — perhaps there are even higher classes, who knows. Both activities are called “recruiting” but they barely seem like the same thing.
OK, but incorrect/inflexible quizzing about tech questions is inappropriate full stop. If this was an interview for SWE summer intern it'd be a badly-run interview.
> exactly what this process is supposed to do
You can't ensure that there will be no hurt feelings ever, but ideally the candidates you fail don't go around talking about how poor your interview process is.
> make the assumption that the interviewee is misremembering the questions
In your post you imagine slight differences that might make the questions more reasonable. I think the main problem here is the responses to the answers. For a non-engineer quizzing someone, the response to an answer should be "OK" and then you note down the answer and show your notes to an engineer at the end. This solves both the "that's not what's written on my sheet" problem and also allows the interviewee to form a more nuanced impression of your recruiting process.