[teraflop]

Off the top of my head, I can think of a couple of things it tests for:

* 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.

[alesua93]

> 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 (:

[Unklejoe]

> random piece of tech

IDK. GPS is probably one of the most prevalent technologies used today besides the Internet itself.

[alesua93]

Fair enough. I understand where you're coming from, at the end of the day I guess it depends on the context and the way the question is presented (left-field questions such as this one can be somewhat fun to try to answer and hypothesize about, if the interviewer creates a friendly environment to do so)

[Unklejoe]

I hear ya. I would definitely not disqualify someone for not knowing the answer.

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.

[daenz]

Chip manufacturing is even more prevalent. Why not ask a candidate about how silicon wafers are made?

[avianlyric]

Because that’s not a problem you can solve with software and algorithms. That a chemical and lithographic problem that requires a knowledge that rarely overlaps with software.

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.

[Unklejoe]

Because that's a lot more obscure. A better example might be asking something like "what's the difference between cache and RAM" or "what is a CPU register", which I'm starting to think will still catch objections from some people on the grounds of it not being relevant to Javascript.

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.

[daenz]

>Anyone who has "engineer" attached to their job title should at have a general understanding of this

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.

[randomswede]

"Assume you are on a relatively typical unix system, you type `ls -l` and press return, walk me through what happens in as much detail as you're comfortable with."

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

[astrange]

What is the difference between cache and RAM according to you?

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.