tag 41554 + notabug close 41554 thanks Will Rosecrans wrote: > Based on an inane interview question that was discussed here on Twitter: > https://twitter.com/QuinnyPig/status/1265286980859908102
It's an interview question. The purpose of this type of question is never a practical existing problem but is instead to create a unique, unusual, and unlikely to have been previously experienced problem for discussion with the candidate. To see how the candidate thinks about problems like this. To see if they give up immediately or if they persevere on. To see if they try to use available resources such as discussing the problem with the interviewer. It's a method to see the candidate's problem solving skills in action. If the candidate says, here is the canonical correct solution, then the interviewer knows that the candidate has seen this question before, the interviewer will have learned nothing about the candidates problem solving skills, and will simply move on to another question continuing to try to assess this. I am not particularly fond of interviewers that fish for a particular answer. Better when the interviewer knows they are looking for an open ended discussion. The goal is assessing the candidate's problem solving ability not rote memorization of test prep questions and answers. It is easy to say, oh, we will simply have the program avoid changing itself, since it that would almost never desirable. But that says that it is sometimes desirable. And though easy to say it is actually very hard to program it to avoid creating new bugs. I might say impossible. If this particular case were to be modified in the program the only results would be that the interviewer would need to look for a different inane, unique, unusual, and unlikely to have been experienced situation to put the candidate in. But along the way the program would have acquired a bit of cruft. It would be an unnatural growth on the program source. It would forever need testing. It adds complexity. It would likely be the source of an actual real world bug. As opposed to this thought-experiment situation. > "chmod a-x $(which chmod)" not a particularly likely thing for a user to > try to do directly, but it is conceivable for some sort of script to > attempt it by accident because of a bug, and it would make the system > inconvenient to recover. Since it's almost never a desirable operation, > chmodding chmod itself could simply fail unless something like --force is > supplied. The underlying safety logic is similar to that behind the > existing "--(no-)preserve-root" There are an infinite number of ways for someone to program a mistake. Trying to enumerate them all in a program to prevent them is one of them. Bob