Interviews on Skype: Test candidates using a real-time code editor over Skype.

I agree with your thoughts on interviewing, but the "real-time coding" session in my mind isn't part of the interview, it's part of the pre-interview screening process that you gloss over here.

Asking programmers to code tough problems on the phone or whiteboard is a good test of certain personality traits, but not a good test of programming skills. On the other hand, there are problems so simple that a decent programmer should consider them to be typing rather than coding, and I think they make perfectly decent initial screening tasks. FizzBuzz is the obvious example here, but I think it's too popular to be useful. I periodically hear from devs who say they get so nervous in interview situations that they can't program at all, but no type of screening is going to be perfect.

And I much prefer this kind of objective screening process to more subjective ones, which tend tend to devolve into "let's choose people with backgrounds similar to mine".

How do you validate that this is true?

That's a great point. I've been in such emergency situations multiple times earlier in my career, when I was a system engineer (mainly Unix field support work) at a large hardware vendor. I used to do the same as what you say (double-check many things, sometimes even triple-check, particularly the more important changes I was making via some script or command), and I know it helped prevent me many times, from making mistakes that could have been serious, in a high-pressure and high-stakes situation (where said situation was often because of data loss with no backups or something equally bad). And in many cases, I was successful in solving the problem / restoring the data / etc. Also saw, and in some cases, prevented colleagues from making, such mistakes. Was too late to prevent them in other cases (sometimes by a few seconds, like once when I was a bit too late while trying to grab a colleague's wrist off the keyboard when they were typing a command (as root, natch) that could cause irrecoverable damage (and sometimes did). And this in live production environments on multi-user Unix systems, e.g. in a factory environment.

A real-life example of what I said in the last few lines above:

A colleague and me were in the computer room of an auto parts factory that had such a multi-user Unix system deployed in production. As part of some maintenance / problem-solving procedure, he types (as the Unix superuser):

# init 0

(which shuts down the Unix system automatically, with no delay or warning) on the main console, without thinking of informing all the live users in production to stop and save their work - on the shop floor, stores, accounts dept., etc. You can guess what happened next - dozens of calls on the intercom from highly irate workers from all those depts., in colorful language ...

The problem given in a coding interview should be a simple one and the candidate should be allowed to choose the solution language.