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.
for what its worth, at my last company once a candidate passed phone screening we would tell them that the in-person interview would include a one-hour coding assignment, and that they should tell us their preferred language and (free) editor/ide and we'd set it up. we also provided full access to google, and the tasks were reasonably easy (e.g. print out numbers in a square spiral, implement a duplicate file finder, that sort of thing). a depressingly vast majority still couldn't do it; contrariwise the good ones would have just as happily done it all on a whiteboard.
* 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.