We had a conversation about this a short while back in a local Slack channel, and my personal opinion is that I have never been fond of coding as an exercise for a technical interview, especially if it is a whiteboarding exercise in front of others or a timed event. Due to their simplicity, they offer little beyond basic syntax or entry level abilities if you're looking at a short timespan, and anything more complex is probably prohibitive if you're interviewing multiple candidates, because the code has to be reviewed.
Take home coding exercises are a bit better, but someone still has to review it, and who has that kind of time if they are interviewing a lot of potential candidates?
Instead, if a coding exercise is necessary, I would lean toward having the candidate perform a code review on a known bad piece of code, looking to see how they spot inefficiencies, and then have a separate technical conversation, akin to refining a project that someone would work on. It would be more real-world, and I think you could gauge their thinking process better, and still get an idea of the complex thought processes involved with senior development.
Reading through the comments here, I seem to be the outlier on the usage of these idioms. In fact, of the five in this article, I've only ever heard one in actual usage (Rubber Duck Debugging), though, I could say that "Bus factor" has been used, just not that specific term (more "if you were hit by a bus" as a term). The other three, however, I've never heard in my 20+ years in the tech industry (though I do remember the actual Ren & Stimpy episode...).
Take home coding exercises are a bit better, but someone still has to review it, and who has that kind of time if they are interviewing a lot of potential candidates?
Instead, if a coding exercise is necessary, I would lean toward having the candidate perform a code review on a known bad piece of code, looking to see how they spot inefficiencies, and then have a separate technical conversation, akin to refining a project that someone would work on. It would be more real-world, and I think you could gauge their thinking process better, and still get an idea of the complex thought processes involved with senior development.