However, the question we should be asking is: do we need a question more complex than FizzBuzz to determine whether or not someone is an STE? If so, why?
And if not, then why do most developer interviews consist of a series of coding questions that are more complex than that? Because as much as we like to say "so we can see how you think", really, virtually all interview coding questions are FizzBuzzes.
I had one job that, days before the interview, sent me the spec for an archival format they used, and asked me to implement an extremely basic archive generator and email them my code. At the interview, they asked me to explain what my code did. I went into detail about specific implementation decisions, things that worked for this restricted domain but would not work for a more general version, and ideas for future development.
Best job I ever had.
I think the answer to your question is that it's impossible to determine whether someone is an STE with 15 minutes in front of a whiteboard, because nobody codes like that. You will get false positives from people who can slap together a simple algorithm but don't understand why slapdash hacks aren't good enough for production, and false negatives from people who are brilliant coders but need a little while to get into the headspace, or have their flow disrupted by having to use a damn marker instead of a keyboard and their favorite text editor. You cannot identify an STE in a one-hour interview. If you want to see if someone can code, have them actually code.
Oh, here's another big problem I don't think anyone has mentioned yet: people who think that the stuff they, personally, have memorized represents the core knowledge of computer science that everyone should know, and everything else isn't really important. This is the guy who is unimpressed by absolute mastery of regular expressions, but sneers in disgust when you don't know all the arguments for pushd off the top of your head.
I was once asked "Can you do a quick fizzbuzz implementation on the white board for me" by an interviewer. I stood up, looked at the whiteboard and said "So it's, what.. multiples of three are fizz, five are buzz and both are fizzbuzz right?" and he said "Yep, nevermind, let's move on."
There was a lot more technical, and a lot more practical stuff to that interview as well, but as someone with both dev and dev management positions on their resume, I appreciated that the interviewer just wanted to know if I'd prepared or at least been paying attention for the last few years with the easy opener. Would you even consider someone in this career field who didn't know what fizzbuzz was?
I'd say after 7 years as a professional software engineer. I had never had to do anything harder in an interview than show up. The companies I applied too had prior coworkers and managers who wanted me on their teams. Then I ended up in a company where the management was so dysfunctional that it had the overtones of an abusive relationship. They then laid me off. At that point, I was a Sr. Software Engineer, during the depression, with a 2 week old newborn, out of work, stressed, not sleeping, and I had never white boarded a class, no idea what fizzbuzz was, and the last design pattern conversation I had had been 2 years previous.
I failed the interviews with some pretty decent companies. I got better.
My learning experience with that, is that the majority of interviews I took were not to determine if I was actually good at my job. They were to determine if I was good at interviews.
"Would you even consider someone in this career field who didn't know what fizzbuzz was?"
Yes, of course. Why would not knowing what fizzbuzz is disqualify someone? Simply because they have not heard of it or not read the article on it means absolutely nothing. Not being able to do it, on the other hand, would obviously disqualify someone.
However, the question we should be asking is: do we need a question more complex than FizzBuzz to determine whether or not someone is an STE? If so, why?
And if not, then why do most developer interviews consist of a series of coding questions that are more complex than that? Because as much as we like to say "so we can see how you think", really, virtually all interview coding questions are FizzBuzzes.