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...).
Based on my reading of things, it looks like they are looking to protect their brand by not allowing another brand to use their name. For instance, you would be surprised to see "Kleenex Captain" or "Facebook Freedom" being the name of another business entity, and think it was okay.
What they are okay with is utilizing their name in the titles of articles/posts/blogs/etc. And with that, I'm perfectly okay.
Legitimate organizations are not always a safe bet either. For instance, today I received a phone call supposedly from the Breast Cancer Research Foundation soliciting donations. The organization itself is legit, and the number they appear to be calling from could also be legit, but the number they're calling from could be spoofed.
Personally, I prefer to follow the OP's advice, and only provide information if I initiate the call. Or, more specifically, I'm willing to provide only the information you could find in a phone book, such as name, phone number, and address, and if they truly want my donation, they can mail me something for the request. Still, it could result in mail fraud, but the likelihood is pretty low at that point.
I would say that there's a high probability of it becoming law. Politicians in Ag heavy states, like Nebraska, Iowa, Wisconsin, etc. are much more likely to listen to AFB, and if there's enough of a push, it could absolutely lead to new laws.
I've been paying attention to this for several years. I have an affinity for John Deere, having grown up on a farm that had almost nothing but JD tractors, but their heavy-handed approach to repair work in recent years is unacceptable.
Farmers don't have the funds available to constantly be taking equipment (that sometimes costs upwards of $200,000) to a dealership when it breaks down (and it will break down).
I really wish the Logitech Y-RAU7 wireless keyboard was still around.
1. In my opinion, its ergonomic/split keyboard design is much more comfortable than the standard 108-keyboard layout (which I find causes wrist cramping).
2. The mechanical keys offer key feedback that is often not found in a wireless keyboard
3. The four programmable buttons, the seven media buttons, and the sleep button offer convenience without being obstructive.
4. Even being a wireless keyboard, it is responsive enough for playing most video games.
5. The overall construction of they keyboard is quite solid, without being overly bulky (though it is slightly larger than an average keyboard). I've had mine for more than a decade.
In my opinion, this is one of the best keyboard designs I have ever come across. I like the design so much that I have one for work, one for at home, as well as a backup for at home in case it ever breaks.
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.