They are mostly entirely unfair to the candidate on top of the pressure of having a gun under them while coding, only in the most extreme cases is coding under the gun and that's just competitions where the code is far from real world engineering related...so why test for general coding ability with such tests?? Stupid.
I posit, it is significantly more effective to see examples of a candidates finished working code in the form of a project or projects they've created. How long it took some one to get some uber algorithm working only matters should their estimates for co
mpletion bump against the business time line for getting it done...those time lines in code are almost always on the order of days or weeks NOT minutes. Also, such exercises tell you *nothing* about their ability to work around distributed problems, design algorithms or solutions that scale efficiently say across computers and that is the true talent one needs to have as a versatile problem solving coder...the minutia of solution for atomic algorithms all can be found on stack overflow in a 30 second search...real engineers are going to find and use those rather than beating their head over the syntactic niggles of trying to live code a solution that's already been done *out there*.
Ultimately there is this wide view that engineering is not a creative act which is ridiculous. As some one who is as driven by design and art as creative expression as he is by writing software or building hardware the two pillars have many strong similarities. Creativity doesn't come on a clock and forcing an engineer to do so on a clock can put many brilliant engineers in a schism that masks their ability with anxiety. Some of the greatest works ever created came in moments of utter and serene *mental peace*. This environment is the one an interviewer should be making for their candidates...one that is shaped to *their* creative process.
I interview for the laziest possible programmer, where in programming terms the lazy guy is good at building things once that scale and are efficient consistently even if they are not built in 5 minutes because that programmer is thinking *like an engineer* while building the solution. Forest- Trees thinking I like to call it. I'd rather a coder take a bit longer to get something rock solid *at scale* than that they build something that has a very limited efficiency scope and is not scalable and none of that talent is identifiable by silly live coding exercises.