I've been in situations together with clients deploying a product, them presenting it for their managers, orpreparing for a big demonstration, and something goes wrong due to some unforeseen environmental factor you couldn't have imagined or predicted, and breaks in a way you don't expect, despite the weeks of testing you've done.
You've got your main client staring over your shoulder, arms crossed saying fix it, and every two minutes asking "is it fixed yet?"
You damn well better be able to code under pressure... And like a freaking ninja
I can present to audiences pretty easily, I actually enjoy it. I also don't mind at all having a client watch what I'm doing. And yet, while I have no trouble doing interviews - having worked as a freelancer that would have been pretty bad - the situations are not comparable even for me. I loathe interviews. Fortunately a lot of clients, and I've had several major companies, had people hiring me without any of the usual stuff based on a gut feeling, I had to answer silly irrelevant technical questions only twice. And once I even failed "explain a right join" - something surely everybody would be expected to know, and of course I do, but at that moment I blanked. I go the job anyway but it goes to show that even to me interviews are a very different and greater kind of stress than anything normal work can throw at me. Even if it looks the same, it isn't, not at all! The brain knows context.
An interview situation is much more adversarial: They are looking out for reasons not to hire you, you are competing with others for the job and only one can get it! No such consideration on the job, unless the work environment is completely and ridiculously broken. When are you ever in a work situation where several people work on competing solutions and everybody else but the person who made the winning one is fired? At work you are working together, and to solve a problem, not to week you out of the pool.
Most tech jobs aren't like that. If the job you're hiring for is one of the few that involves high-pressure coding in front of strangers, then by all means test for that.
I have never in 12 professional years been given weeks to test anything. On only a couple of occasions have I been given 3-4 days to extensively test a project with multiple months of development time behind it.
Clearly you're talking about the project where the developer(s) told you very explicitly that it could not be done in less than 3 months. So you just assign the Jira ticket a 3 week deadline anyway. And then flip out when a half-assed project fails to ship. Welcome to the world of software development.
This is not a good way to hire people. I can do all those things, but I'm not normal. Some engineers do a lot better under stress with a system that they're very familiar with. Others do better under stress when they're working with people they know well. And still others are great engineers but aren't the person to be in front of the client under stress.
Congratulations that you can do all these things -- but unless 100% of the engineers in your company need to be like you, you might not want to use your list as hiring criteria.
Being able to code under pressure when the world is burning is also different to working under pressure of a deadline. Or rather, being on the last day of a 30 day deadline isn't the same kind of pressure as being told you have an hour to complete a complex task.
Not everyone needs to be able to work well when the world is burning. Its not part of many jobs. However, if it is part of your job (eg your the guy who has to fix stuff at 4am) then I see nothing wrong with asking candidates to do timed work in an interview. I just think most jobs don't or shouldn't require this.
In consulting you get in similar situations. In those cases it is not a "be able to code under pressure..." thing. Rather, a "know your code well" one. I have also been in a few demos where everything fails. As the manager sitting next to the client with your arms crossed, you have to know how to defuse the situation without having someone sweating their soul on a keyboard. Been on both sides.
if that's common then it's a reasonable criteria for the position, sure. That hardly ever comes up in my work environments, so I'd be happy with an engineer who is awesome 99.999% of the time when they aren't in this position.
You've got your main client staring over your shoulder, arms crossed saying fix it, and every two minutes asking "is it fixed yet?"
You damn well better be able to code under pressure... And like a freaking ninja