Beats me - but the "skills" demonstrated in the interview process you're defending -- "suck up; just keep going online until you memorize enough canned answers to most of these dang questions; suck up, suck up, suck up" -- certainly aren't going to help.
If anything, they're basically orthogonal to the set of competencies needed to deal with that kind of a situation.
Right. People who don't think of Comp Sci knowledge as a set of substantive first principles, just as meaningless tokens they need to memorize and regurgitate to get the job -- those are precisely the people who should be weeded out. Each one of those questions is not merely a chance to "collect" an arbitrary thing. It's also an opportunity to practice applying basic knowledge and techniques.
If anything, they're basically orthogonal to the set of competencies needed to deal with that kind of a situation.
You may well need to spot a deadlock or a race condition in code. You may well need to spot code that is inefficient by construction, in precisely that kind of situation.
And yet - those are the people who are not weeded out, but selected for by the default interview process.
That said, the interview should be designed to specifically weed out the ones who hope to pass by regurgitation. The answer can't be just a pattern match for a particular algorithm. The emphasis shouldn't be on dazzling recall of something obscure. The purpose should be to look for actual experience implementing something.
The thing is - if your production system really ends up going haywire and losing $10 million every second or whatever, then then the root cause isn't some race condition. It's the whole human and organizational process (or lack thereof) that allowed that defect to slip in undetected (and in a position to cause so much damage without proper safeguards) in the first place.
How is that relevant to the practice of "memorizing enough canned answers to most of these dang questions"?
It's not. Instead, ask something not particular tricky, a bit open ended, and just a little bit involved (at least 3 things interacting) with the purpose of seeing if basic skills can be applied. Instead of looking for an answer that can be memorized, you're looking for evidence to see if people have actually designed, implemented, and debugged something at a level beyond gluing libraries together.
I've got a time-saving suggestion - instead of asking questions, measure how long interviewee holds up while being waterboarded. If they can handle that stress, they can handle losing $100 million in 10 seconds, easy.
That being said if you're just talking about mathematics and statistics problems the more mainstream hedge funds like to ask their quant candidates, read Crack's Heard on the Street, Joshi-Denson-Downes' Quant Job Interview Questions and Answers, and Zhou's A Practical Guide to Quantitative Finance Interviews.
My advice to anyone doing this would be to give up the last 10% of performance in order to focus some on contextual awareness. These puzzles are a form of pre-surgical anesthesia, before they ask the real questions. You need the spare cycles at the end of a long day to imagine what casual conversation might really be exploring, how other applicants might misread the subtext, what mistakes in previous hiring they're trying not to repeat. One could be a genius trained seal, by buying into the brainteaser game, and miss the broader question of how you will fit into their firm. One who sees broader contexts ends up running places; don't make it clear that's not you.