Dig In And Get Technical
Smartbear.com says employers are chomping at the bit to hire people with Linux and open source skills. If you have been in the industry for a while, you might forget some of the more academic questions that are asked by potential employers during technical interviews. Technical knowledge is perishable, and if you are not only keeping up with new trends and changes to the field, but also refreshing yourself on the basics, you might find yourself in a tough spot when you get the call.
No matter how confident you are in your abilities, it is always good to do some refresher training before an interview. For example, one question I have heard asked in the past is "how does traceroute work?" The answer, of course, is that it uses UDP packets with an incrementing time-to-live (TTL). When the packet reaches the first router, it's TTL is decremented by one, the packet is dropped, and the router sends back a notice that the max TTL was exceeded. Then the originating workstation sends another packet with a TTL of two, which the first router decrements by one and sends on to its default gateway, who then decrements it by one, drops it, and sends back a reply, and so on until the destination is reached. It is an interesting bit of trivia, and good to understand at a low level how the tool works, but if you are not needing this knowledge on a day to day basis it is easy to forget.
Another question I have heard is "explain what a file descriptor is". There are three file descriptors that anyone who spends a considerable time on the command line uses on a day to day basis: the integers 0, 1, and 2, which stand for STDIN, STDOUT, and STDERR. According to Wikipedia, "a file descriptor is an index for an entry in a kernel-resident array data structure containing the details of open files." And, " On Linux, the set of file descriptors open in a process can be accessed under the path /proc/PID/fd/, where PID is the process identifier." So, each PID will have an assortment of files under /proc/PID/fd, each pointing at a different file, along with 0, 1, and 2.
"Explain what happens if I type 'ping hostname' in the terminal from the time I hit enter till the time I get a response." This one is interesting because you need to break down a fairly simple task into separate parts to again demonstrate your understanding of the operating system. Remembering that the shell needs to find the ping executable in its path, and that it needs to resolve the hostname to an IP address is important, as is correctly explaining the procedure for resolving the host name. This is also a good time to explain how ping and the ICMP protocol works with echo request and echo reply calls.
My favorite question is one that is far less academic and more real-world. "You get a call from a user reporting that the server is slow, what do you do?" The answers can be fascinating, and provide a window into the applicants experience and depth of knowledge. Perhaps they will track down the issue to high I/O wait, or maybe they will just pop open top and not know where to go from there. Do they ask questions about hardware and infrastructure?
There really has never been a better time to be involved in the open source community either as a hobby or professionally. What will separate the chaff from the wheat is the depth and breadth of knowledge, and real-world experience of production Linux systems. Everything breaks at scale, and knowing the details and fundamental operation of a system can mean the difference between minutes of downtime, and hours.