I think I usually noticed when someone felt uneasy, so I left the room for a few minutes.
Test anxiety might be really bad for some people, I know. But if it's that bad that they can't explain to me how to check if "n mod m == 0" then I think there are usually deeper underlying problems in their programming ability.
And if it was really just anxiety, I'm sorry I'd rather have a false negative than hiring them.
I tried homework, it didn't really work that well for me, people would google and copy paste stuff and invest way too much time, in the end they couldn't explain what they did and it was just a waste of time for both parties.
The other problem is that I usually let people work with whatever language/frameworks their familiar with. I ended up beeing not familiar with some C# stuff they used and couldn't really judge their code.
Fizzbuzz is simple enough that you can see if it looks right in pretty much any language
And it's done in 5 minutes even if that means accepting a few false positives.
Oh and, we had I few people where I noticed that they were really nervous and I thought maybe that's why they failed Fizzbuzz, so I invited them in for half a day and gave them a toy project to implement. Usually something really simple like, fetch this RSS Feed, parse it, save it somewhere, make sure that if you fetch it multiple times it doesn't save duplicate entries, and spit out the titles and URL's to stdout or a webpage or anything. A relatively real world exercise I think, nobody was constantly watching them, it was just a "get it done" job, they had internet, their own IDE, their language of choice and everything (a few people complained that they can't implement FizzBuzz without an IDE).
And all of them failed. Hard.
So I ended up not doing that anymore and treat a failed FizzBuzz as a K.O. criteria.
I tried homework, it didn't really work that well for me, people would google and copy paste stuff and invest way too much time, in the end they couldn't explain what they did and it was just a waste of time for both parties. The other problem is that I usually let people work with whatever language/frameworks their familiar with. I ended up beeing not familiar with some C# stuff they used and couldn't really judge their code. Fizzbuzz is simple enough that you can see if it looks right in pretty much any language And it's done in 5 minutes even if that means accepting a few false positives.
Oh and, we had I few people where I noticed that they were really nervous and I thought maybe that's why they failed Fizzbuzz, so I invited them in for half a day and gave them a toy project to implement. Usually something really simple like, fetch this RSS Feed, parse it, save it somewhere, make sure that if you fetch it multiple times it doesn't save duplicate entries, and spit out the titles and URL's to stdout or a webpage or anything. A relatively real world exercise I think, nobody was constantly watching them, it was just a "get it done" job, they had internet, their own IDE, their language of choice and everything (a few people complained that they can't implement FizzBuzz without an IDE). And all of them failed. Hard. So I ended up not doing that anymore and treat a failed FizzBuzz as a K.O. criteria.