Interviewing someone for general unix skills

Question

How would you test a developer that claims to have *nix shell experience (just to be clear, we don't want to test if someone can develop on *nix, only that they know their way around the command line).

I was thinking about making them solve a problem of getting information out of log files, which would involve some basics like cat, grep, cut, ... combined with piping.

What other basic knowledge would you ask for? Once again, this isn't for interviewing someone who will develop for *nix systems, and also not for *nix system admins, but just for regular developers that sometimes need to do some work on a *nix system.

Answer 1

From my personal experience developer working on an *nix system needs to know:

• shell variables (how to set/get + knowledge about special ones like PATH)
• shell redirection (capturing output of an program)
• pipes (extracting some information from log file is an excelent example)
• process control (ps, nice/renice, kill)
• file access rights (ls/chmod/chown/chattr)
• users (but mostly in context of files/processes, ie: is this process able to access this file? why it can/can't?)

...and as a bonus:

• starting/stopping system services

Such a skill set allows to do most developer related tasks with ease.

Answer 2

From my experience with my numerous colleagues since I started to work, nobody wants to fake Unix knowledge: either they "know their way around the command line" or they simply say "no way!".

Just ask if the candidate is willing to work on a Unix workstation and let him tell you how far he can go through bash. He will eventually name some commands; the most obvious ones are cd, cat, more or less, vi or emacs, grep, awk, sed. Listen carefully whether he mentions man.

If it is for developing, he should be familiar with make and Makefiles, and some source control command line interface (svn, git, cleartool, hg, cvs...)

Answer 3

Why do this?

The *nix shells (and other OS shells, fwiw) are very deep and broad working environments. It's possible for somebody to spend years working there and use only a very small % of the shells' capacity.

If you don't expect the person to a) shell program, or b) administer the system from the shell, then why does it matter? Anything that gets done will be at such a basic level that a handy *nix cheat sheet will more than compensate for the "lack of skills".

Answer 4

Out of the top of my head I would probably ask them two things:

1. When you used the *nix commandline before, did you encounter a case, in which a well thought-out command saved you a lot of time? If so, elaborate.

2. Please explain the major differences between the *nix commandline and a standard Windows desktop. What are advantages and disadvantages of each?

Clearly, the first will give you an indication of how deep the applicant's knowledge about the commandline goes. If he worked for years on a *nix, he won't just tell you that he was proud to have run a grep. Don't expect them to remember the exact commands of course (there's always manpages for that), but the general idea of what they did.

The second question instead checks if they understand what the commandline is really good at and for what it's not a suitable tool. It's easy to learn to use a hammer, but much harder to switch to another tool in case the hammer is unsuitable. So this question gives you a good indication of the applicant's view outside of the *nix box, plus it is open enough so that he can (and should) score with his knowledge. (Nothing worse than answering something like "uh.. windows has those windows")

Answer 5

Depends of what you want them to do.

For getting information out of log files your suggestion for cat+grep makes perfect sense. I'd add ls, cd and less/more to that.

If you expect them also to do some minor edits (say, in config files), then it would make sense to add testing for vi and/or emacs and for stuff like cp/mv/rm/mkdir.

Answer 6

I'd recommend that they know emacs or vi/m, tar, sed, e/f/grep, the various compilers, some shell scripting. Perhaps run a test where they have to use these tools to grab some code from one file without opening it, insert it into another program; then compile the program which will break on some trivial error. They then need to use a text editor to go in and find the error, get the code working and archive the binary. Then mail it somewhere whilst giving permissions to the recipient to run it.

Answer 7

I don't know about you, but I'd get kind of annoyed if my interviewer asked me and I didn't know how to work on Linux.

You shouldn't really care about what they know right now, but what they can learn if given the chance. Learning *nix tools isn't too hard but it takes a little bit of determination -- you should really test for the ability rather than the knowledge.

Answer 8

It depends on what level of experience you want them to have. IF this isn't for someone who will develop for *nix systems, and also not for *nix system admins, but just for regular developers that sometimes need to do some work on a *nix system, how much experience do they actually need?

Anything such a developer might need in *nix shells (ls, chmod, cat etc.) could probably be written on a single page cheat sheet. If so, requiring *nix shell knowledge where it is not required might eliminate some good candidates.

Answer 9

I usually pick a simple task and ask the person to write a shell script on a whiteboard.

"You have a directory "foo" and a backup directory "foo_backup". Write a shell script to see what has changed in "foo" since "foo_backup" has changed.

Answer 10

'Explain the login process in Linux, with as much detail as you feel comfortable' is a good question. The login process happens to involve switching users, permissions and ownerships, and lots of general Unix philosophy. If they can clearly explain the how and the why there's a /etc/passwd and /etc/shadow, and how a non-prived user can change their own password but not others', that means they 'get' Unix.

Another good one is anything with log parsing, or quick security audits. If they can add up total bandwidth served out for a particular vhost out of an Apache log, or find if there are any other users in the system with a uid of 0, they're handy on the commandline.

And one thing to NOT do to them: do not make them do it on paper/whiteboard. Give them a live system (but no internet because that's almost cheating), and watch them go. If they know their way around man pages and can build multi-pipe expressions on the fly, that's a good sign. If they need google for everything, then their skillset is questionable.

Answer 11

why make them write a functional program ? what's wrong with saying "tell me the difference between grep and sed, or what does X command do ? etc . that way, you can lead them around a little.

if they fumble on the specific assignment you give them, you might not think they're smart. but if you ask general questions, you give them the chance to show you what they do know, which may be substantial but in a different way than what you were wondering.