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.
But as a one-off, and if asked in a forgiving way to explore how they think, then I'd consider this question valid.
Maybe "Have you ever thought about how GPS works?" if "yes", then let them explain, if "no", then make it easy for them to start reasoning about the system and then see how they might design it.
Seems to me as fair as asking "have you ever thought about how a double-linked list works?" or "a basic way to ensure database consistency when the DB is replicated at two different physical machines"?
It's not like GPS is something esoteric that they are unlikely to have interacted with, odds are they used it to get to the interview location.
The "Have you ever thought about how GPS works?" question gets a scripted "No, but <blah blah blah>" answer. It's fully automatic, because there are now two possibilities:
- I have thought about GPS before. I will now fake my creative process. No hard feelings, but you are just another obstacle for me to get the job, that's it.
- I have never thought about GPS before. We will now try to design "together" a super-complicated system having so many boundaries and hidden constraints, while I will be also panicking on the inside the whole time. No wait, that would be dumb. I know, I will just refuse to discuss it further. Next question.
(Also, TIL that "flack" in addition to its primary meaning is apparently an acceptable spelling of "flak" too.)
There should be no expectation of them coming up with the “correct” answer. But they should be able come with an answer and explain it clearly, warts, holes and all.
Using something real like GPS also ensures that the candidate understands why the problem is a useful problem to solve, and what the objective of the solution is I.e. a system that lets you locate yourself on earth.
But directly talking about those topics is probably handy.
Once you understand the signals are timecoded, this boils basically down on your ability to picture the intersection of multiple sphere in 3D space and it will become obvious (amongst other, very technical reasons that should not be an interview question).
You have to picture those spheres given that the satellites are roughly at same orbital height relative to earth center and you always receive signals within your "field of view" on the nightsky - and of course assume the earth is round.
Unfortunately, I don't understand. For example, check out this screenshot from the OP: https://i.imgur.com/9kh5tBi.png
If the satellites are above (the horizon/field of view), and you're intersecting spheres, it seems to me that you would have the best precision in the height direction and worse precision along the sphere. Am I missing something?
* 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.
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?".
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.
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.
I also like the question because even if you have no idea how GPS actually works, you could quickly come up with the rough idea yourself given that you have a bunch of satellites that can emit arbitrary signals. Lots of room to show creative and analytical thinking here.
What kind of engineers are you interviewing?
> I also like the question because even if you have no idea how GPS actually works, you could quickly come up with the rough idea yourself given that you have a bunch of satellites that can emit arbitrary signals.
I find this really doubtful. Someone who doesn’t already understand how GPS works is unlikely to derive it from first principals in a brief interview.
Just consider that there are people - perfectly intelligent, capable of learning - who don’t actually know what ‘GPS’ stands for. They maybe don’t know that the GPS system is separate from their phone’s cell connection. They may not even know that satellites are involved. They may have not taken enough of an interest in space technology to have internalized how satellite orbits work, to have intuitions for how orbital speeds and altitudes are correlated. Or they may have picked up a common misconception at some point in the past about how cellphones work, thinking cellphones are always talking to satellites. So they might have made some reasonable intuitions about how GPS works that - because they haven’t been exposed to the true answer - cause them to make some erroneous assumptions that seem like dumb mistakes a poor engineer would make.
Not having had the opportunity to come across those things is not the same thing as not being able to incorporate that knowledge into your worldview when you encounter it.
or was that the pothole cover? Sorry, I might have gotten confused.
If you ask an interviewee how GPS works and he says something about the cell phone sending signals to a satellite, you would want to pursue that further, at least to make sure that he's asserting that with a sufficiently low confidence.
Are you nitpicking the difference between a different engineer and a programmer or are you interviewing a different sort of engineer?
I think that it is a good question for any engineer. One explanation for why HeyLaughingBoy might have disagreed was that HeyLaughingBoy was making a distinction between a programmer and an engineer.
I thought that highlighting the distinction between what HeyLaughingBoy wrote (programmer) and the parent (engineer) was a parsimonious way of expressing this.
Amazing that even engineers don't understand that GPS receivers don't talk to the satellites.