Again, that's not necessarily how that's intended. The observation on its own is just an observation, it doesn't indicate anything about how interview performance was evaluated.
For example when I interview, I have a question related to chess, which requires a basic understanding of how the pieces move. I was amazed that even engineers don't understand the basic movement rules of chess.
However as far as the interview went, it was a non-issue. It took about 30 seconds to explain, not a single candidate had a problem with it, and it never came up when I was giving my verdict.
As an interviewer, where there's a huge power imbalance, why even stray into the territory where candidate can easily perceive a disadvantage for not having totally unrelated knowledge? A candidate will feel like their lack of chess knowledge, or GPS knowledge, hurt them if they didn't perform well. Why not just ask questions that are relevant to the work they will be doing? Maybe you don't realize just how stressful interviews are to some people, and how much they have to prepare, only to be asked to reverse engineer how GPS works.
It's very clear in the interview that knowledge of chess isn't being tested. The chess-related exchange is literally about 30s and it's clearly part of the segment where the problem is explained, not the part where the candidate needs to demonstrate their abilities.
As for why, by relating the question to something in the real world (like chess or GPS) a few things are accomplished:
- It gives the candidate an ambiguous situation that they have to navigate away from (e.g. by asking clarifying questions).
- It requires the candidate to map a real-world situation to an algorithmic solution, rather than just being told "implement a graph traversal" or "use dynamic programming to solve this".
- It makes the problem more interesting.
I know exactly what it's like to be on the other side because I was there too not so long ago, solving interviews just like this. I found questions like this much nicer than more obscure questions like Gray code.
I think you're just fixated on this idea that the interview is there to test what you know and not knowing something is a fail but that's not really how it works. What a candidate knows is next to nothing to me, what's most important is how they go about solving the problem. Do they ask questions? Do they consider alternative solutions before digging in? Is their code somewhat readable?
Aside from the basics of CS, I really don't care what they know and that's made reasonably clear before the interview (as it was to me when I was interviewed).
For example when I interview, I have a question related to chess, which requires a basic understanding of how the pieces move. I was amazed that even engineers don't understand the basic movement rules of chess.
However as far as the interview went, it was a non-issue. It took about 30 seconds to explain, not a single candidate had a problem with it, and it never came up when I was giving my verdict.