Have been greeted enthusiastically 10 years ago by the team I was joining because I was a shining example of the kind of candidate they wanted in a see of wannabees (we spoke briefly about design patterns in the interview and I solved a take home problem that included connecting to a database and querying it using JDBC.)
While not FizzBuzz the whole thing could be solved in less than an hour and I had a couple of days and could use any resource I wanted.
I guess that says something about the problems one can face.
That said: More often I've experienced doing good or even perfect interviews etc only to hear nothing back etc so this definitely goes both ways.
Nowadays I tend to use such problems as pre-screeners in a short telephone interview[1] before inviting candidates to attend a full face to face interview because it saves wasting everybody's time, including the candidate's.
Sad but true.
[1] We use codeshare.io or, if it's oversubscribed, Google Docs. Massively prefer the former because it includes syntax highlighting and support for many different languages, so it feels much more like a decent code editor. With Google Docs you're using a word processor which is far from ideal for many reasons, including that you feel like you're fighting autocorrect the whole time.
1) in an editor, iteratively, until it works. This is the correct way. Every developer should manage to solve FizzBuzz in this setting.
2) By writing it on paper or a whiteboard without feedback. Even the greatest developer in the world would randomly fail this. It provides zero information about the capability of a developer and no one should ever subject anyone to that type of test.
(I would argue that 'now, find a bug' is a good follow up question in most any coding interview, regardless of how perfect the first draft was...)