Errr, the point of "write code on a board" is not to determine engineering suitability, but to weed out the majority of people who style themselves as programmers but who can't actually program. See e.g. http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

I'm deadly serious about this; the last time I played this "game", back in 1997-8, we were using one of the 2 best D.C. area head hunters, were already receiving well screened resumes which we further screened, and even then a solid 1/2 of the "programmers" we interviewed couldn't program.

They showed no signs of "do this in public" performance anxiety, e.g. we would have been flexible on all but one of the tests by e.g. not hovering over the interviewee and/or providing an EMACS or Visual C++ editing buffer (the exception was "find bugs in this block of code on the board", which I think is a different sort of thing, especially since public code checking is something people do). And our write some code tests were simple, reverse a doubly linked list (C or C++), and compute the factorial of a number, which we supplied the definition of for those who'd forgotten.

Side note: I was their first programmer employee, back when they couldn't afford head hunters, just a classified ad (they'd already tapped out their networks), and the #1 reason I was hired was I was the only one who passed the white board programming test. Which I viewed as so trivial that when that fact was mentioned I didn't really remember the details of it.

Apart from all the humble-bragging, and unsupported assertions ("They showed no signs of anxiety" !! Right... not one candidate you got was anxious on the day of the interview.) the content I'm getting out of that post is minimal. And yes, I completely believe you that writing a syntactically complete piece of code on the whiteboard and finding bugs in it in while a senior engineer watches you like a hawk (without any intention of helping you out) is an everyday occurrence for a software engineer.

Anyway I don't think I'll be able to argue you out of your long-held beliefs per se. All I (and other engineer employers reading this) need to know is, Google has been the foremost purveyor of this method since it began hiring engineers and they now say their data shows it doesn't work. That's enough for me to renounce it and find other ways to screen talent (and yes, we're currently looking for a senior hacker in the Bay Area).

PS. btw, you might want to see a specialist about that deadly seriousness... before it gets, you know, too deadly ;-)

Given that few if any of us are in a position to do the sorts of filtering Google can or afford to do outside of the interview (e.g. it's been said they're enamored of Ivy League and equivalent degrees), I'm not very interested in claims that proving a candidate can code is worthless. Whereas I know from being in companies that didn't do this before I learned it in 1997 that failing to do this results in bad hires, which can be fatal, if you'll excuse my vocabulary, for a start up.

I'm sorry I wasn't clear, specifically:

The find bugs test was code we supplied, sprinkled with bugs subtle and not so subtle, and simple syntax wasn't being tested, but things such as using an uninitialized variable. The candidate had to find "some" of them, but there was never a problem in deciding who passed and who failed the test.

We also weren't at all particular about syntax in the examples that had to be written from scratch; the interviewee did had to signal to us he did knew proper syntax, but, come on, getting it all right is the job of an editor (well, so I, an EMACS user since 1980 think) and of course the compiler.

Otherwise you might try rereading what I wrote, e.g. I said "performance anxiety" in the context of writing the from scratch code examples. I.e. if we'd cued into that, or the interviewee had asked, we would have left them alone to write them, or put them in front of an edit buffer to do so while we didn't hover over them.

Counterwise, wow, I must really be coming across as a hard case, for "while a senior engineer watches you like a hawk (without any intention of helping you out)" was very much not true, see the above not watching option and we most certainly helped the interviewee out if he asked the right sorts of questions or paused at certain points while writing it.

I.e. while it would be a negative to have forgotten the difference between * and ->, we would have told them and then seen if they grocked pointers, that and recursion were the higher level things we were looking for (they were requirements for what we were doing). But it was never even close, it was never difficult deciding if someone passed or failed these three tests.

Seriously, deadly or not, while it was possible we had some false negatives, it really didn't seem to be the case, and enough other people I respect endorse this that I'm not about to stop advocating it.

As far as I can tell the Fizz-Buzz test, which is intended to be easier than reversing a linked list, has no connection to Google. "Google has been the foremost purveyor of this method since it began hiring engineers" might be true today, but in my days Microsoft was best known for this, before Google was even officially founded.

This was of course back when Microsoft was famous for being fairly well run, and their "hidden" "secret" was being consistently able to write software that "worked", i.e. didn't core dump (much)), one of the reasons all their big DOS era competitors fell behind or died in the transition to Windows.

I find it hard to pick what to answer from such a long message but suffice it to say, any engineers interesting in working with packetzoom would never be confined to a small room and asked to write code on the board. And despite that, for coding roles, we'd find out one way or another whether you can code, and at what level (not all coding roles are created equal either).