I certainly threw in things there which I would not consider a requirement for hiring. I DO expect basic knowledge of the TCP state diagram and ability to parse and explain netstat output in actual hiring interviews. I would not expect someone to have read Schimmel's book and know how kernel locking works in great detail.
My advice is to really learn how to write some toy C programs at minimum an learn the sockets API and really have a copy of APUE and use it occasionally. I highly recommend a project where you do some kind of trivial 'hello world' patch to the actual kernel sources and things of that nature.
I have actually, on my job, seen issues that require this kind of knowledge -- like one incident with massive amounts of TCP RSTs and I've cracked open the kernel sources and tracked down where the TCP stack can issue RSTs, and found a problem with TCP Timestamps and the PAWS algorithm and the way that our layer 4 hardware loadbalancers at the time were doing packet rewriting and preserving all the random TCP timestamps from the clients which was hitting very high velocity servers and when TIME_WAIT state sockets were hit with a 'backwards in time' TCP timestamp from a different client it would issue a RST and tear down the connection because of PAWS. You might be able to find that kind of problem by studying the TCP RFCs and books like TCP/IP Illustrated instead of opening the kernel sources, but its the kind of problem that you aren't going to be able to Google. And I don't really have the ability to write a [modern, multithreaded] TCP/IP stack (although I could certainly acquire it), but I have demonstrated the ability to read the sources and get real-life work done by doing so.
For all the candidates that I interview I want to see some indication that they can work without the Google safety net and show some ability to track down problems on their own.
My advice is to really learn how to write some toy C programs at minimum an learn the sockets API and really have a copy of APUE and use it occasionally. I highly recommend a project where you do some kind of trivial 'hello world' patch to the actual kernel sources and things of that nature.
I have actually, on my job, seen issues that require this kind of knowledge -- like one incident with massive amounts of TCP RSTs and I've cracked open the kernel sources and tracked down where the TCP stack can issue RSTs, and found a problem with TCP Timestamps and the PAWS algorithm and the way that our layer 4 hardware loadbalancers at the time were doing packet rewriting and preserving all the random TCP timestamps from the clients which was hitting very high velocity servers and when TIME_WAIT state sockets were hit with a 'backwards in time' TCP timestamp from a different client it would issue a RST and tear down the connection because of PAWS. You might be able to find that kind of problem by studying the TCP RFCs and books like TCP/IP Illustrated instead of opening the kernel sources, but its the kind of problem that you aren't going to be able to Google. And I don't really have the ability to write a [modern, multithreaded] TCP/IP stack (although I could certainly acquire it), but I have demonstrated the ability to read the sources and get real-life work done by doing so.
For all the candidates that I interview I want to see some indication that they can work without the Google safety net and show some ability to track down problems on their own.