People that have been around know such things. At one point, Richard Stevens (RIP) was god. Every programmer had a copy of TCP/IP illustrated, Advanced Unix Programming and Unix Network Programming. If you wanted to do anything network, you had to write your own servers, you had to understand the details. The breath of knowledge was wide and the depth was just as deep. Ask around on HN, and you will probably be shocked how many that know such things. :-)
And then, the world developed robust, well-maintained, open source libraries that do all of that for you. Now, in 99% of commercial software engineering, you don't actually need to know any of those details, in the same sense that you no longer need to know exactly how many transistors and diodes are used to build the adder on the CPU. It simply no longer matters in almost all cases. Your time is much better spent moving on to higher level problems.
If you're interviewing for the rare 1% case where the job will actually require you to tinker with a TCP stack, then by all means ask about those details. For 99% of programming jobs today, it's irrelevant trivia used as nothing more than an ego measuring device.
I feel like I've seen 2-3 articles alone in the last month that has rediscovered head-of-line blocking and UDP. I'd say 1/10 engineers I talk to even know what cache aware datastructures are.
The thing that separates someone who can just string together whatever they find on npm to people who build real systems is this deep understanding. You're not going to need this for your standard LoB apps. However if you're in the business of building software you're definitely going to want people like this.
There's a vast middle ground between stringing together npm and rewriting the TCP stack. Most jobs that exist today fall firmly in that middle ground.
Trying to find the TCP stack engineer to build your app is like hiring a petrochemical engineer to do oil changes. If your pockets are as deep as Google's, yes, you can do that, but it's by no means necessary.
Whatever this thing... this... stringing together a 100 random github projects to get a webpage that kinda of works about 80% of the time is called -- please let's agree not to call it "software engineering".
You are jumping into conclusions too fast. There are plenty of good software engineers who work with high level languages and technologies on a daily basis. You just have to know your tools, no matter what you do.
"And then, the world developed robust, well-maintained, open source libraries that do all of that for you. Now, in 99% of commercial software engineering, you don't actually need to know any of those details.."
And that, ladies and gentlemen, is how we ended up with npm.
Yep, I was doing network programming back in the late 90's and you pretty much had to have a good grasp of winsock and linux network calls and responses because the level of abstraction was much lower.
That said I can't recall any of that stuff mattering in the stuff I do for work for quite some time and most of it is a google search away.
That interview was just weird, it was like asking the boiler pressure for a steam train to someone who was a master engineer working on electric trains.
Is TCP/IP Illustrated still the gold standard of books on the subject? I read it fifteen or twenty years ago and would like to finally own a copy (I borrowed it from the library), but not if there is something better.
The amazing part here is that so many people still remembers all those little details. I still know how it works, but honestly I forgot all the details long time ago.
A lot of it depends on what you do day to day. A year ago, I knew what a MAC address was, but in an abstract way. Today I automatically know it's 6 bytes long because I look at them every day.
