"I've always passed Fizzbuzz tests"

You just negated your entire point there.

Yeah, you can have a bad day. I get it. We all fail interviews; I certainly have. Some I feel we really weren't a match (they were looking for a kind of developer that I wasn't, and don't want, to be), others I felt were unfair (for instance, interviewing with Microsoft years back, I had a C/C++ interviewer asking me questions that I had been told I was allowed to write in Java, and then disbelieving me when I told him (String).length is constant time so it didn't affect the Big O complexity that I had 'for (int i=0;i<(String).length;i++)', and clearly mentally checking out at that point). Obviously I don't feel any were because I wasn't, legitimately, good enough, but I also recognize I am very biased. But the thing is I also am in a place where I don't need an interview to justify my confidence at this point. I know I can deliver value. But I also know I will never convince the Googles of the world that I can, because I am neither a researcher of note, nor am I going to jump through the hoops of prepping for weeks on end for an interview; I have a wife, hobbies, and other, better ways to spend my time (even typing comments on HN! :P)

We first give people a take home. It's at their own convenience, we tell them it will be an hour and a half, coding, simple questions, to do it at a time they're comfortable. We don't stay on the phone, we tell them to use whatever resources they want (except, obviously, please don't try and google for the answers directly, or get help from others; it's simple enough that those who have tried to cheat have ended up with it being hilariously obvious, like leaving source comments that said it was by someone else, or variables for 'cat' when we never asked for anything related to cats, or being caught out during the whiteboard).

The interview is mostly a conversation. It starts with conversation. We talk about the position, the company. We ask about what the candidate is looking for, their resume, that sort of thing. Only after thirty minutes or so do we get to anything technical. We ask a few questions, and they're intended to be placeholders for conversation; plenty of right answers, we mostly want to see that the person is knowledgeable enough to discuss things. Even when we get to questions that have a right answer, it's mostly to gauge knowledge, and for the more complicated, even if a person gets it wrong, we'll tell them what the right answer is, and then ask them for a rational as to why. If they can figure out the rational, that's just as good as having known in the first place. Then we have a whiteboard question. It, too, is not hard. We tell the candidate "If you think there's a library function that will help, but you just don't remember it, you'd need to Google it, that sort of thing, talk it out with us, we'll give it to you". We try to help suggest things to get candidates unstuck. Etc.

Really, it's -not- a particularly antagonistic process. We really, really do want people to succeed (because, frankly, we want the position filled so we can stop interviewing and go back to work). So, yeah, if the interviewer doesn't manage the trivial coding tasks...we're going to pass. We -aren't- saying "this person is a bad developer", we -are- saying "this person could not demonstrate that they passed the bar of our interview process".

But there have also been some who have flat out said, even on the take home "I can't do this". Or those who have admitted when faced with the whiteboard question that they don't know how; that the take home had been done by someone else. Etc. Given those situations, yeah, our candidates are being given a take home, and a whiteboard.