"My brain doesn't work as well when writing by hand as when I'm typing. This doesn't have to be perfect. If you get stuck, ask for help, we'll talk through it. Think of this as a starting point for a technical conversation."

As a candidate, I would worry about my future coworkers if I were not asked to write code during the interview.

Perhaps I'm envisaging an ideal world but I'd much rather see some production code they have produced and ask questions about that. It's very easy to gauge someone's knowledge of a particular technology by just talking to them about it.

But, if they're just trying to get an idea of your abilities and critical thinking skills and coding style, it's really not that big of a deal.

Then you find out they don't know what 'const' means, have never heard of size_t, and spend 20 lines on something that should be about three.

I wouldn't find that out otherwise. Instead, I'd find out after hiring someone, and spend six months to a year getting them run out. That sucks.

So: Everyone writes code.

The problem with this - ignoring the open source part for a second - is that it is very hard to accurately judge someone's contributions to a project at their previous job from their verbal description alone.

Also, you run the risk of discarding candidates who had the misfortunate of working on boring projects at boring companies.

Do whiteboard test really work better than giving someone an editor?

I never enjoy writing anything on a whiteboard, be it code or some kind of drawing for a meeting. I'm also plagued by lousy handwriting, and I don't draw particularly well.

One interview scenario that I did not mind, and was editor-free, was one where I was shown Powerpoint slides of code. I was asked to fix what I saw, or determine if anything was really wrong at all.