Unless you're hiring them to work in that domain, I don't understand why you'd ask that question.
* Ability to reflect on and critique their own ideas, using technical common-sense. If someone has never had a reason to research or think too hard about how GPS works, then it might be reasonable to initially assume that it sends a signal to a satellite. But hopefully, when prompted to think about it a bit more, they would realize: "Hey, if that's true, then somehow these satellites that were launched in the 80's and 90's were able to scale up their capacity and handle orders of magnitude more demand, now that everyone has a smartphone in their pocket. Maybe that's not how it works?"
* General curiosity and interest in areas outside their field of specialty. This might not be strictly necessary to get a job done, but it probably has some correlation with other measures of technical aptitude that are hard to probe directly.
I think this is a bit misguided, since the scope of things outside of a candidate's field of specialty is tremendously large. Picking a random piece of tech within that space and drilling the candidate about it seems rather unfair.
A better way to handle this would be to actually ask the candidate about what else interests them outside of their specialty. But hey, maybe that doesn't stroke the interviewer's ego enough (:
IDK. GPS is probably one of the most prevalent technologies used today besides the Internet itself.
In fact, someone who is able to sort of work through the problem on the spot may even be preferable to someone who just knows the answer because they happened to read Wikipedia the week before.
However GPS can be solved with some high school maths, and applying solutions found on the software engineering domain E.g. computing distance from latency, communicating with a remote resource over a comms link, broadcast vs unicast etc
It’s not like the interviewer is going to ask them to design the satellites and rockets themselves.
Asking how GPS works (in general terms) is more like asking how the Internet works. Anyone who has "engineer" attached to their job title should at have a general understanding of this, or at least be able to work through it using common sense on the spot. I know we covered it early on in college (maybe in Physics, I forget).
Again, I'm not talking about low level details here. Something like "your phone measures the time it takes the signals to arrive and calculates a distance" indicates some understanding. From there, most people can figure out how that information could be used to calculate a 3d position.
The fact that the interviewer finds so many candidates who don't answer the GPS question to their satisfaction, while companies complain about difficulty finding software engineers, should tell you all that you need to know about the question's relevancy as well as the bizarre assumptions that some interviews hold.
The super-simple answer is correct, but I think if you asked in an interview people would try to give a complicated and wrong answer out of nerves.
A decent candidate will give me 5-10 minutes of delving into various parts of "unix processes", maybe "dynamic linking", most probably a bit of "file system" by judicious use of "could you explain that in more detail" or "how does X work".
A truly excellent candidate will have me taking notes for 25-30 minutes, while they pre-answer all my followup questions, go through process creation, dynamic linking, file system API, filesystem internals, maybe some disk layout, process termination and signal handling.
Out of maybe 120 candidates I've asked that question, one (maybe two) have answered it so fully on their own that I did not have to ask any followup questions. And pretty much exhausted my question graph, so once done we could pivot to "do you have any questions for me?".
It's valuable to know how someone will handle a question they don't know the answer to -- whether they recognize their own ignorance and whether they are willing to admit to it.
Which is actually useful to know, even if this method would be a dickish way to do it.