This is going to come across as harsh, but if that is your favorite interviewing question, and you are not hiring GPS engineers, then it is a ridiculous question to ask and serves no purpose but to "haze" candidates.
I think it's more relevant than asking an embedded engineer which sorting algorithm is the fastest.
If the intent was to find out if people __knew__ how GPS worked when they didn't need it for the position, sure.
However I see two other possibilities:
- How does a candidate react when they don't know something? Do they try to bullshit their way through? Do they admit it and ask what you'd like them to do?
- Can a candidate, __with guidance__, come to a basic understanding of how GPS works and come up with a reasonable (note: not necessarily correct) suggestion for how to implement it?
>Amazing that even engineers don't understand that GPS receivers don't talk to the satellites.
They're amazed at the lack of knowledge, not that a candidate wasn't able to talk it out, or that they bs-ed through it. That tells me the question is asked in bad faith.
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 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).
Getting stressed too much about a job interview may be a sign of overcommitment. And I believe you're not looking for a guy ready to go over corpses.
I'm often looking for someone I can give a problem to and they return with a potential solution. That involves thinking through problems, how they work, how they can't work, etc.
Asking someone how they think GPS works, or asking them a question about how they'd try to track down a defect based on what a customer is reporting to me are very important skill sets to have.
This is why these questions are important. The skill set is logic and deduction not regurgitation of ideal solutions.