The OP's statement makes the context clear though: It's not about knowing everything. It's about knowing a couple of abstraction layers under you (and, as I argued elsewhere, above you too).
It's useful to understand a few classic networking problems that a backend engineer might face — e.g. weird latency issues caused by Nagle's algorithm, or TCP CLOSE_WAIT leading to ephemeral port exhaustion between a proxy and an application node. It's useful to understand why we mostly moved to event loop-based servers instead of thread-per-connection servers as a way to handle c10k.
A backend engineer doesn't necessarily have to be an expert on any of these things, but they should be able to follow along if an expert explains that sort of problem.
OP was responding to a comment specifically about debugging C. Someone questioned the value of this to employability and then the comment I responded to laid into him/her, suggesting no one on HN should ask that. I am defending that question.
It's useful to understand a few classic networking problems that a backend engineer might face — e.g. weird latency issues caused by Nagle's algorithm, or TCP CLOSE_WAIT leading to ephemeral port exhaustion between a proxy and an application node. It's useful to understand why we mostly moved to event loop-based servers instead of thread-per-connection servers as a way to handle c10k.
A backend engineer doesn't necessarily have to be an expert on any of these things, but they should be able to follow along if an expert explains that sort of problem.