You want me to code fast, I'll code fast. My code will be shit, but it'll work. It won't scale, it'll roll over and die in 3 months when we make the slightest change.
As an interviewer its idiotic. What are you testing? If I've memorized the question you're asking me? Or seeing how fast I can think on my feet. If its the former, what? If its the later, there are other ways to test this, that make sense.
If you want to see how a developer thinks on his feet, give both of you a problem you haven't seen before, prototype a data structure to solve this problem. Work together interviewer and developer, you'll learn each other's thought process, and a bit about the company dynamic. It'll take longer, but more information is gained via osmosis.
I thought it was the least effective way to probe my skills as a developer. It would have been better to talk about how I would solve those problems instead of a timed test.
Interviewer: There is no correlation between people's ability to take timed code quizzes and good developers. It causes undue pressure on some candidates for no reason and we should never have it be part of the process.
In the vast majority of jobs (IMHO), the speed at which they can write a given function/whatever has almost no bearing on their overall productivity. Most coders only program a few hours a day anyway (see: https://news.ycombinator.com/item?id=8131116) ...it's what they're doing the rest of the time that matters most.
If you have a need to do a timed test, at least do it in pseudocode. That way you're just testing the applicant's logic, instead of how much [php/js/ruby/whatever] they happened to memorize over the years.
I avoid the things these days. It's not about being fast it's about getting the job done. Quizzes don't demonstrate such things.
They might be okay for graduates, or low end candidates, but for experienced folk it's irrelevant.
Interviewer (many hats here): A _brief_ quiz is a useful highpass filter for junior-level positions ("Ugg set clock on microwave! Ugg programmer now!"), and a possible conversation starter ("what, why & how").
Interviewer: I wish we did more of this in our hiring process. A written code sample is a great jumping off point for discussing how and why the applicant makes decisions while coding.
If it is then it is acceptable. If it isn't then it seems asinine.
For me myself, if I had a literal clock there ticking down then it will take me twice as long and I'll do a much worse job. There's a lot of people who cannot program under high stress situations like that (and a job interview is naturally quite stressful already). So expect to dismiss a lot of otherwise great candidates.
Maybe the interview process should be based around the job you're employing them for rather than for trivial games that only test someone's abilities at completing those exact type of task. Crazy I know, but maybe just maybe it makes sense.
