- How virtual memory works
- How threads work
- How TCP works
- How ports work
- How ethernet works
- How DNS works
- How a web server works.
And so on. A lot of these things are more important than theory (but I think theory is important, too!).
That's not because I'm lazy or scared or even disinterested. I've exhaustively learned everything about anything that what I do involves and how most of what it touches works as well. However the simple truth for me has been that I've never worked on things that needed to know about the things you're talking about.
I constantly do need to know more about the fundamentals of the systems I actually work with - Rails, Angular, HTML, caching, Node etc. I'm sure there will come a point when I need to know more about some of those things too.
However there is a tonne that I don't know even about the things that I need to know about and I will always invest my time in learning those things. That's why I would always focus interviews on the languages and frameworks that someone actually uses. Those may be the ones you describe but for plenty of developers may well not.
I only drill into a framework or language when someone writes that they're an expert on it. Otherwise, learning a new framework or language might be bumpy but if they have skill then it shouldn't be a problem.
TCP? DNS?
More like persistent cache misses in SQL or some weird edge case caused by an errant vertical tab or a filename getting too long or some limit in array length causing your compiler to do weird stuff.
Knowing how any of that list works is more for sysadmins than programmers.
Lists like these reflect your own experience. I care more if an engineer can quickly grasp the "big ideas": Maybe they don't know about threads, but do they express disbelief that they solve a real problem, or an unwillingness to explore them? A willingness and aptitude for learning is so much more important because the state of the art is a moving target.
If you write code, you should know what your code is running on. You should understand some of the layers of abstraction or at least be curious about them! Even if it's not related to your job, you shouldn't take the magic underneath for granted.
I see a big correlation between programmers who take a lot of this stuff for granted with cargo cult programmers - people who tend to think of things as "if I do x, y comes out" instead of "if I do x, this will trigger y, which causes z".
I've seen a lot of things in HTTP land that I wouldn't have been able to figure out without tcpdump. The most exciting thing is that livehttpheaders doesn't always tell the whole truth. :( But also subtle things like (TCP) load balancers mungling option fields, forged reset packets (and determining from whence they may have come), weird packet corruption.
Yes, absolutely I don't expect people coming from an offline world to know the internet stuff... but who's really offline these days?
But honestly I like to see any knowledge in low level systems - especially operating systems. I think it's important for people to know what their code is running on!