Between 2010 and 2019 I interviewed dozens of Software Engineer candidates at Google. Almost always I asked the same interview question. Moreover, this question happened to be on the banned list at Google, because it was publicly available on Glassdoor and other interview websites, but I continued to use it because I got good signal from the candidates.
I stuck to the same question for nearly a decade too, even if it was barely more difficult than fizzbuzz. The ability to compare against the past candidates was very useful, which would not be possible when changing questions too often.
The sad reality was that it was waaaay too effective as a fizzbuzz eliminator (> 80%) which I don't know what it tells me about the candidates in general or just about our recruiting :-)
> The sad reality was that it was waaaay too effective as a fizzbuzz eliminator (> 80%) which I don't know what it tells me about the candidates in general or just about our recruiting :-)
I suspect there are a lot more people who frequently choke on easy coding questions, under the very specific conditions of interview-stress (which is very different from, "the client is unhappy and is also onsite and you'll be in a meeting with them later" stress, and from "production broke" stress, so no, I don't think it's a good proxy for general "grace under fire", as it were, either) than there are actual full-on bullshitters who manage to land software jobs while being truly incapable of doing even the basics of the job.
For one thing, I think such top-tier, extremely-convincing bullshitters would have an easier and less-stressful time applying that skill directly to some other role, since there are some well-paid roles where that kind of thing is exactly what companies want, so it doesn't pass the smell test for me that so very many would be trying to land software jobs—not just ones who exaggerate skill or try to get into the industry while woefully unprepared, but who also are able to fool interviewers at a reasonably-high rate in conversational interviews, yet fail simple coding tests.
That is, I suspect a large majority of "ha! I caught a faker!" anecdotes or anec-data are actually a false-negative on the test from people choking under interview conditions, and that most real fakers would also have been caught in any half-competent conversational interview anyway.
The remainder should be probably be hired regardless, then re-homed to sales when you realize what's going on, since they're evidently top-percentile bullshitters and social chameleons. Joking, of course... kinda. Maybe.
There's certainly part of that, but there's also likely selection/sample bias. The better the programmer, the less time they probably spend in interviews. And the "reward" on passing a programming interview if you're marginal is quite high, depending on your alternative choices of employment.
(Top tier Ivy League university acceptance rate is 3-10%, so if you're looking for someone of at least that caliber among the general population (or even among developers), an 80% rejection rate might not be crazy. FAANG (or its ilk) are the "Ivy League" of Software Development jobs)
The tens of thousands being laid off from that ivy league and ones who jumped the, 6 step, multi-tiered interview hurdles to get a job offer, later rescinded, might disagree with that value proposition.
What percentage of candidates would you believe freeze up so badly that they can't program at all?
Over the years, I have seen significant numbers of applicants who couldn't write FizzBuzz, and even one who couldn't sum up the numbers in an array (ignoring overflow). Some of these people had reasonable resumes, and many of them could talk about software development in the abstract.
This was usually a sign of poor phone screening, but it always blew my mind.
Interviews make me realize I don't know how to code on the spot while 4 people (responsible for judging me and determining my worth) watch me. I second guess everything and freeze up. My mental capacity to solve a problem is being taken up by a fight/flight response (wanting to push through the question or quit). The environment I'm in is foreign, outside of my typical coding setup. My brain has no time to adjust. You could look at my github and see someone who's an excellent coder, but put me in an interview scenario like the one OP wrote and it's like 10 years of education just disappear.
Out of curiosity, how do you think you might do in a 1-on-1 coding interview doing something incredibly basic, like:
- Sum an array.
- Write FizzBuzz.
- Count the words in a string.
- Compute the length of a linked list.
Assume you get to use the language of your choice and a familiar text editor. You aren't being graded on semicolons or gotchas. And the interviewer isn't hovering too closely.
Because that's the situation that always mystified me. How many people freeze up under reasonably favorable interview conditions to the point that they can't write even basic code? (And would those people be able to pair on a tricky bug when production is down?)
I absolutely do read a candidate's online code, if they mention it in their resume. That only seems respectful. And I think it might be reasonable to waive in-person coding tests if someone is obviously competent.
(Of course, now that Copilot is getting smarter, it's going to be harder to evaluate people's GitHub repositories or to include trivial problems in pre-interview screens.)
> Out of curiosity, how do you think you might do in a 1-on-1 coding interview doing something incredibly basic, like:
In my 20ish-year career, I've had... oh, ballpark 30 interviews, and I am certain I convinced at least two of those that I had absolutely no idea what I was doing, one on something about as hard as what you list, another on something only barely harder. One was around the middle of that span, another, four or so years ago. The number would be higher, but most of my interviews have not featured coding questions. I have an incredibly high offer rate from interviews that haven't done those (70%? Maybe higher), and near-zero from ones that did.
I can, in fact, code. I've taken complex projects from zero to production, solo, with companies that couldn't have afforded to keep me on for years if I couldn't pull my weight. I've developed a reputation at multiple places as the one to go to with tricky or low-level problems, or the one to hand odd-ball problems with tech no-one's familiar with. I collaborate well, I do the solo thing well, I'm good in a meeting with stakeholders, I can take a support call like a champ. I figure things out, I deliver, I ship. I am not bad at this whole thing. But interview coding? LOL.
> (And would those people be able to pair on a tricky bug when production is down?)
I'm cool enough under pressure that it's been remarked upon throughout my career, over and over. Interviews still get me—specifically, the performing part of coding questions, the rest is no problem.
I think it's because they're kinda hostile (yes, yes, "we're both just deciding if we're right for one another" and "you're interviewing them too", but c'mon, see exactly all the chatter about interviewers trying to find liars and expecting there to be lots of them—you're under a microscope). Production-down is collaborative. Angry-client is collaborative (from your co-workers, anyway). Not just that you're working together, but supporting one another, everyone's got everyone else's back. Most stressful work situations are fundamentally safe in a way that interviews are entirely not. There's nothing to prove, only a problem to solve.
I'm also shit at public speaking—not talking to people, not meetings, but speaking before an audience, and I mean shit—and playing music in front of strangers is basically my nightmare (and yeah, I've done it). I suspect both those are true for most people. The stress of coding in front of someone while they judge me is identical to those situations, for me.
