Last night I held lecture 06 of my graduate CS class Advanced Programming in the UNIX Environment at Stevens Institute of Technology. With the topic "Process Groups, Sessions, Signals" this has, over the years, become one of my favorite lectures, as it lends itself well to illustrate a number of important concepts in the Unix world.
As I was finishing my slides, I tweeted in reference to the function prototype of signal(3):
Now you may think such a seemingly obtuse "trick question" is pointless, asked only for the glorification of your massive ego (as many interviews are), but I actually think this is a wonderful interview question. Here's why:
First of all, we get to talk about the programming language itself. When not immediately identified as the signal(3) function, this prototype will require at least some hooing and haaing and thinking-out-loud from most people. As they do, you can ask if they can simplify the prototype, perhaps by using a typedef (as is suggested on some platforms in the signal(3) manual page):
typedef void (*sig_t) (int); sig_t signal(int sig, sig_t func);
This allows you to start a discussion about typedef and macros ("Could you use a macro?", "What's the difference between a typedef and a macro?", ...), which are a great segue into how a compiler works: since macros are pre-processor directives, you can discuss the multiple stages a compiler chain executes and veer off into any direction from there.
Next, you cannot avoid talking about function pointers in this context, which gets you to a general discussion about pointers. You can start asking how a function can return an "array", or whether or not "strings" exist in the C programming language. From there, more advanced topics such as how pointer increments and sizeof work or operator precedence can lead you to How Not To Use Pointers.
On the other hand, if you want to move beyond just the programming language, you can dive deep into Unix process management. Once the function is identified as signal(3) you can find out how much the candidate knows about signals, leading to questions about what types of signals exist, what generates them, what permissions you require to send a signal to a process, what signals cannot be caught or ignored (and why), how to kill entire process groups and of course the common question of how one can verify the existence of a process by PID in a single command/syscall (answer: by sending a signal value of 0, ie kill -0 $PID; see kill(2), though that's more one of those "either you know it or your don't" kind of things).
You can talk about process groups, sessions, job control in the shell (which also gets you to controlling terminals, I/O redirection, ulimits and all that jazz) or you can dive deeper into how a process executes: you can talk about reentrancy and idempotence, you can draw pretty pictures of function frames on the stack and you can move on to setjmp(3)/longjmp(3), which then nicely gets you to a discussion about exceptions and program logic.
Each signal opens the door to another topic: SIGHUP leads to dæmon processes, SIGPIPE to blocking I/O, SIGCHLD to parent-child relationships and zombies. (My favorite signals: SIGTSTP and, for long running unix tools, SIGINFO.)
As you can tell, it really doesn't even matter whether or not the candidate expects this question and immediately blurts out "Hey, that's signal(3)!" Either he or she actually recognized the prototype, in which case I've established more than just a very basic knowledge of the programming language; or, he or she memorized this exercise (as it's a fairly common question, I think), in which case the various directions into which I can take the discussion will quickly reveal this.
So yes, if you put "C" on your resume, chances are that I would ask you to explain this prototype and expect you to be able to have an intelligent discussion about some of the topics I hinted at above. (And if you actually put "C/C++" on your resume, so help you god.)
For great justice.
October 10, 2012