writing code during an interview is great, but almost a 180 degree experience to writing code in real life. there are a couple of factors:

* psych pressure

* unrealistic timeline

* googling is usually not allowed, whereas EVERYBODY uses it writing code in real life

* editor/environment is usually not "yours"

* etc..

hence the _way_ you choose to conduct a code test will, in most cases, matter a lot less than the actual _problem_ you choose that needs to be solved. the more applicable this problem is to what your business does every day the better. e.g. sometimes a "red-black tree" is crucial, other times things like a simple mobile CRUD app with a REST web service OR a thin, high throughput TCP/IP based protocol could be a lot more relevant.

of course you can't realistically expect a 100% bug free or even complete code from candidates, especially if you ask for things like an "app" or a new "protocol" => what really matters is _how_ people "get to it".

github or not, I hired several exceptional people not that long ago using a piece of paper and a white board. If it is not a face to face interview, skype and/or google docs are also effective.