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.
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?".
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.