testing whether someone is willing to prepare for a thing is a relevant work skill test too.
Is it, though? I could understand if algo questions had some relation to the work you're doing, but your comment on why they're good is independent of the actual material. If we replaced the algorithm question interview with an interview testing obscure presidential facts, would it really be a useful test to have devs take? I guess it is a relevant work skill test in that you get people willing to put the work in/game the system, but it doesn't seem to be much of (if at all) an improvement from ad hoc conversations.
Handled correctly, a problem like this answers several questions:
1) Can you correctly break down a problem like this into its components parts? 2) Can you recognize the overall class of problems that this falls into? 3) Can you transform this specific problem into the more general class so that you can solve it in a known fashion? 4) Can you think about and implement the movement? 5) Can you communicate while you're doing the above?
No one cares about solving that particular problem. But the answers to the above really are relevant. Being able to map novel problems onto known solutions is absolutely a skill that any competent software engineer needs to have. "Oh, you want me to do X? That looks a lot like Y, this thing we've already solved; maybe I can just implement it in the same fashion (or re-use our existing system!)"
I'm not saying that this particular problem is a wonderful example, or that I'd use it in my own interviews. But this overall class of problems really does have a place in interviewing when it's handled well by the interviewers, and arguments against it on the basis of the specific problem being irrelevant are really rather missing the point.
I don't do many interviews anymore, but I used to, and I had no short supply of problems that I actually had to solve in the course of my work that I could ask about. I don't think whiteboard interviewing is great in general, but if you're going to do it you can at least try to keep it relevant.
As a matter of fact, I did have to do memoization of graph traversals at least once for work (most programmers never have to do this), and I find that problem a lot more interesting (trait matching for Rust). I could easily give a talk about that problem. As for that interview question, though? I don't always do well with time pressure, and so I can't guarantee I'd be able to answer it to your satisfaction.
I find that hard to believe.
Moreover, memoized graph traversals don't get you full credit on this question. There's a dynamic programming solution, and in fact the ideal solution is one using matrix math, which is ludicrously divorced from anything most programmers would ever see.
But it will also filter out everyone that is opinionated enough to not do that stupid preparation work, and you will end up with sheep coders that will always follow the rules. Looking at Google, Facebook etc, this might already be the case. I will even go so far to say that they prefer those type of obedient coders than the ones that ask too many questions and get too creative.
Reviewing algorithms for interview prep at least has some relevance to programming. While a candidate may not use that exact algorithm in their day to day job, they are creating ad hoc algorithms all day long. With that said, I don't think time pressure, white boarding algorithms is a very good job performance predictor.
(The counter to that is that if people can relatively-easily (single-digit days) cram for your interview, you're still not going to be effectively screening for at-hand pre-existing familiarity/knowledge.)
If I require all prospective engineering hires to prove explicitly that they have an IQ of at least 135, I will get sued. Do you think this is false?
