The chance you’ll survive a half life is exactly the same whether MWI is real or not. It doesn’t give you any useful information. You have no way of distinguishing between being just that lucky or MWI being true.

That’s not the case with other experiments. If you assume your hypothesis is correct, the chance of the experiment being successful is higher than the chance of it happening by random chance if your hypothesis is not. That’s a key difference.

The experiment, as defined, only leads to your survival by random chance. The experiment does not create any outcome except by random chance so it cannot be used to prove anything.

Collect data, and show how it’s unlilely unless your hypothesis is true.

The quantum immortality experiment doesn’t do that, though. The outcome, by definition, always occurs within the realm of random chance. Your environment needs to create an outcome that is extremely unlikely to occur by random chance. The experiment is not repeatable. It makes no predictions about what’s going to happen if you try again. It doesn’t do anything useful to bolster the many worlds theory.

We butchered humanlike / 10

I don’t think it proves many worlds any more than it proves you have a fairy godmother manipulating quantum states for you. All you’ve done is shown an unlikely occurrence happened, not what caused it.

Sure you can move some parts of the conversation to a review session, though I think the answers will be heavily influenced by hindsight at that point. For example, hearing about dead end paths they considered can be very informative in a way that I think candidates assume is negative. Nobody expects you to get it right the first time and telling the interviewer about your binary tree solution (that actually doesn’t work) can be a good thing.

But the biggest problem I think with not being in the room as an interviewer is that you lose the opportunity to hint and direct the candidate away from unproductive solutions or use of time. There are people who won’t ask questions about things that are ambiguous or they’ll misinterpret the program and that shouldn’t be a deal breaker.

Usually it only takes a very subtle nudge to get things back on track, otherwise you wind up getting a solution that’s not at all what you’re looking for (and more importantly, doesn’t demonstrate the knowledge you’re looking for). Or maybe you wind up with barely a solution because the candidate spent most of their time spinning their wheels. A good portion of the questions I ask during an interview serve this purpose of keeping the focus of the candidate on the right things.

I’m not sure that offline or alone coding tests are any better. A good coding interview should be about a lot more than just seeing if they produce well structured and optimal code. It’s about seeing what kinds of questions they’ll ask, what kind of alternatives and trade offs they’ll consider, probing some of the decisions they make. All the stuff that goes into being a good SWE, which you can demonstrate even if you’re having trouble coming up with the optimal solution to this particular problem.

My way of thinking differs by saying if from my individuals perspective I experience the perfect coin (quantum particle) to flip tales a million times in a row there must be a highly likelihood that many worlds indeed exist since I died in the ones it said heads.

It doesn’t make that highly likely, though. It’s about equally likely that there’s a fairy controlling your coin flips. The experiment hasn’t proven anything about the cause of the unlikely outcome. You’ve just measured that it happened and then declared that your preferred explanation is the reason.