This is purely anecdotal however I've been doing Rails dev (and prior to that Javascript, PHP and even Matlab) for 14 years and I have only a vague grasp how most of that list works.

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.

Maybe you've been lucky? Being forced down the stack seems to happen either when you need more performance, or when stuff blows up.

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.

That's not the stuff that typically goes wrong.

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.

It's funny how the things you know well always happen to be the bare minimum of what you expect from others. Then you learn something else and hopefully realize that yourself of yesteryear still managed to write good, maintainable software, but that your current self would consider the old self a charlatan.

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.

Yeah, but low level systems stuff isn't anything that's going to change anytime soon. My operating systems professor had been teaching that class for years!

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

Sure, but why TCP and not UDP? Why threads and not processes? Why a web server and not a mail server? Why ports instead of sockets? The list you made is a decent baseline for somebody doing web development, but a smart person programming in another domain could easily pick up any of these things.

TCP is more complex than UDP. UDP is really just I pick my local ip and port, and send to your remote ip and port, and hope you get it. TCP has handshaking, acks, flags, resets, etc; a lot more to go wrong. Anyway, understanding DNS means understanding UDP too.

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?

Just about the only two things I ever encountered from your list are threads and web server. I work on web applications, but details of TCP, ports and ethernet are simply too low to be of any practical use.

Do you work with Internet/Web technologies? That list seems slanted towards that kind of gig.

I do :)

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!