[sokoloff]

I have, personally, interviewed a senior software engineer candidate, claiming 8+ year of experience coding, who could not write a simple 5-minute exercise, in any language of his choosing. It wasn't FizzBuzz exactly, but if I'd thought to ask FizzBuzz, he'd have busted that as well.

"Write a function that takes a set of numbers [array, list, or equivalent] and returns the average."

Couldn't even get started.

I was the third interviewer. He'd BSed his way past the phone screen and two others and I caught a whiff of "Johnny can't code" and decided to check by asking him one of our new college grad questions.

There have been many more who bombed terribly in a manner that leaves me doubting whether they could solve FizzBuzz given an hour.

I don't doubt your beliefs, but I am surprised that you've not found any candidates who cannot possibly code at all. That probably speaks well to whatever upstream filtering process your firm is using (it would be ironic if it was "coding FizzBuzz using this online coding platform").

[theptip]

My priors for “is nervous in interviews and gets flustered” are significantly higher than for “can’t code fizbuzz and somehow kept their previous jobs”.

This meme has been going around for ages (at least since Spolsky wrote about it) but I really doubt it is as common as people think.

I think it’s still rational to pass on someone who got stage fright, since in that case you have no signal on which to make an assessment. But I think the “can’t code” rationalization does candidates a disservice.

Interviewing is really stressful for many candidates! I encourage interviewers to remember this and treat candidates with compassion; maybe they can tell you think they can’t code, and that makes them more flustered. Vs. a joke about how interviews are stressful that might put them more at ease.

[thu2111]

It's quite common but how common depends a lot on where you get your candidate stream from. In my experience it's never to do with stage fright. The candidates don't seem flustered. They just cannot program. Even if it was stage fright, so what? Instant no hire. Your work will be evaluated by people post-hiring too: you have to be able to perform the job you are hired for when asked to do so. Panicking the moment you're asked to do your job is an excellent indicator you should not be in the team.

At my current firm, I hired most of the engineering team. In the early days we relied heavily on website applications and external agencies. A non-trivial number of candidates would struggle with a task like "read a text file into memory and print out the lines". Not FizzBuzz, if anything that's even easier: FizzBuzz trips up some inexperienced candidates because they don't know about the modulo operator, which is relatively rarely used. But almost any kind of program will use files.

At some point we started pulling sourcing and recruiting in-house. We also dropped some bad agencies and got a bit more savvy about which ones were cheating. The candidate stream got better at that point and total failure became less common. Unacceptably poor performance was still a frequent issue though.

Disappointingly, to me, a lot of candidates and even people we hired would try to claim that asking candidates to load a text file from disk was somehow unfair because "real programmers" don't work with files anymore, they just use web frameworks to do everything. Needless to say, that was not the kind of software engineer we were trying to hire.

[decafninja]

Usually the candidate pipeline is:

1. External recruiter shotguns out candidates to my team manager. Having been on the other side of this process myself, any vetting the external recruiter does is pretty minimal and purely behavioral.

2. Our manager passes around resumes to the team, and we collectively review them and give a thumbs up or down based on how subjectively we are impressed by it.

3. Manager assigns the more senior members of the team to conduct phone screens. Typically we throw some of the easiest of the easiest leetcode questions, or very simple "implement this in JS" questions. I personally have failed people at this stage mostly for communication or behavioral issues.

4. On-site. Combination of easy leetcode questions and "implement this in JS" questions. I can honestly, proudly, say that my team does not look for hyperoptimal perfect leetcode solutions - we genuinely focus on the communication process more. Part of the reason for this is, as I mentioned before, most of the candidates we get would struggle at all but the easiest leetcode questions and we cannot afford to be picky. We're not a hot tech company. We're a boring investment bank.

Very, very rarely we get a candidate that has worked at a hot tech company - even a FAANG occasionally. Their candidacy gets treated like a celebrity. But so far all such candidates have been turned down by my manager's manager because "they don't have enough business (finance/trading) knowledge". Never mind that most of our current team has extremely little to no such business knowledge too. In any case I doubt we could match the level of compensation they might be wanting.

[kyawzazaw]

Is your workplace hiring? Sounds like a relaxed process.:)

[sokoloff]

Are you saying 100% of your applicants could write FizzBuzz at step 3 or at step 4?