Preliminary Interview for GNU/Linux System Programming Candidates

As part of my job, I have to take interviews to fill in positions in my own team. One of the skill set that we expect in the prospective candidate is GNU/Linux system programming. Instead of right away launching into the nuts and bolts of the system, I prefer to have an initial set of questions to gauge the level of experience the user has with the system. Here is a small subset of the questions that I tend to ask often to the candidates. I have also provided the rationale for asking those questions.

What are the books that you have read about GNU/Linux operating system? What online resources do you use to keep yourself upto date with the various developments in your profession?

Rationale: I always believe that knowledge is there in the books. If someone is claiming to be knowledgeable in a particular topic then he must have read atleast one book in that particular topic. If the candidate have read more books it shows how much interest he has in that topic. Also proper utilisation of online resources would be a definite plus for a candidate. A person who spends time reading newsgroups and mailing lists of a particular topic would definitely keep learning new stuff all the time.

Name a few utilities of GNU/Linux operating system that you commonly use.

Rationale: This question will definitely help you to know how much experience the candidate really has with the operating system. If he can name more than 10 utilities without having to think hard, then he has used the system sufficiently. If any of the tools that the candidate mentions is of any particular interest to you then you can spend a few minutes discussing about it. Just to test the waters.

What are the IPC mechanisms available in the GNU/Linux operating system?

Rationale: Any person who is serious about programming in GNU/Linux operating system must be aware of the various IPC mechanisms available. At the minimum he better know about pipes, shared memory and sockets. Mention of memory mapped files can be considered a plus (I say that because many candidates seems to not know about it.) And this question can carry significant weightage depending on the kind of project for which the candidate is being evaluated. Depending on the project requirement a few more questions on selected IPC mechanisms can be considered.

You must be aware of programming errors like memory leaks, free memory reads (FMR) and free memory writes (FMW). What tools would you use to detect such errors in your program?

Rationale: The question tries to find out how much debugging experience the candidate has. Infact, the above question can be generalised into asking about the various debugging tools the candidate have used. Any mention of tools like valgrind, electric fence or others is a definite plus. Many times memory related errors in programs are hard to find using the debuggers alone.

How do you send signals to other processes? How do you catch or handle the signals? Can you handle all the signals?

Rationale: The relevance of this question can depend on your project. But even otherwise, a small discussion about signals can reveal a lot about the candidates programming practices. For example, the knowledge of basic signal handling (think SIGINT) to do proper cleanup before exiting the program is a good practice. Also if the candidate knows about signals that cannot be caught and if he can discuss about why it was designed that way, then he is definitely above average.

Many more questions touching upon debuggers, visual debuggers (DDD), documentation system, editors, source browsers, build system and shell programming can help to assess the ability of a candidate to fit into the role of a GNU/Linux system programmer. Ofcourse, there might be other requirements for the project, like knowledge of some particular domain. The above is just a few sample questions to show how one can go about screening all those prospective candidates.

One should always remember to assess the candidate against the project requirement. There is no point in testing the ability of the candidate in a certain skill, when that skill is not required for the project for which he is being interviewed.