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.

closed as primarily opinion-based by durron597, GlenH7, Bart van Ingen Schenau, user22815, gnat Jun 24 '15 at 23:49

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • That kind of shell training is cake for any person who already knows a programming language. Since when do people care if interviewees make the truth seem a bit more pleasing in their resumes? It happens all the time. Sounds petty to me. – Yam Marcovic Sep 29 '11 at 0:07
  • @YamMarcovic - When you say "make th etruth seem a bit more pleasing", are you saying "claiming levels of skill they do not have"? If you are, I'd say that's pretty relevant to find out during the interview. If they lie to get through the door, how can one trust them once inside? – Vatine Nov 23 '11 at 17:25
  • @Vatine Because at least from my experience, everybody over-exaggerates their skill-levels in resumes. If you disqualified those people, you're narrowed down to hiring dogmatically honest, or naive people. That's a lot less options. – Yam Marcovic Nov 23 '11 at 17:44

12 Answers 12


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.

  • Nice answer. What commands are used for starting/stopping system services? – Tim Jul 25 '17 at 20:13

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...)

  • 4
    I know about man and I use it whenever Google doesn't help, but I'd never bring it up on my list of commands... – Mehrdad Sep 28 '11 at 9:44
  • 3
    man is the most efficient way to learn about unix command line and C libraries when you are offline. By the way, I learned Unix when the most advanced tool for searching internet was telnet archie.cs.mcgill.ca – mouviciel Sep 28 '11 at 9:51
  • 1
    Obligatory xkcd.com/293 xkcd.com/456 xkcd.com/434 – Mehrdad Sep 28 '11 at 9:56
  • @mouviciel: It's also the most efficient learn to way about the unix command line when you are online, since most forums will 'helpfully' tell you to rtfm if you ask them details about the commands. This should be okay if the man pages weren't incredibly convoluted and hard to navigate documentation. Luckily there's stackoverflow! – Joren Sep 28 '11 at 11:22
  • I don't know about that. I use man pages excessively and I've never had any problems with it once I got used to it. It's a piece of cake to find what you're looking for. You have sections, you have "See Also"'s, and you can search the whole thing with the click of a button. You get a man page for every command and every syscall, and quite a few library calls. I'd say man pages are what makes me love UNIX so freakin' much. – Yam Marcovic Sep 28 '11 at 23:57

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".

  • It's an honesty check. If someone puts unix experience on their resume (which we don't really require), I want to be able to check what those claimed skills are. If you're just able to use cd and ls, you shouldn't be claiming unix experience imo. – Christophe Vanfleteren Sep 28 '11 at 14:53
  • Well, I'd then ask them what Unix systems they used and have them list differences between Unix systems and probably Linux/Mac – johannes Sep 28 '11 at 15:11
  • 1
    @Christophe - Well, here's the deal... it doesn't matter, because they probably won't work for you. It's a major red flag for an interviewee when the potential employer starts pulling silly stunts like this because they don't trust what's on the resume. Your "test", and your justification for it, is basically saying that you're trying to hire somebody to work a shit job at a shit company. I may be wrong, but I'm guessing that I'm not. However, if I am wrong, I suggest that you re-evaluate your "expectations". – Joe Internet Sep 28 '11 at 23:12
  • 1
    @Yam - It says it like this... if you're hiring and somebody sends you a resume that you believe is contrived, you just don't interview that person. What you don't do is create some silly test that a) you admit has no bearing on the position's requirements, and b) admit that is only designed to test the "honesty" of somebody's claimed experience. If somebody can't even get an interview at OP's company without having their "honesty" questioned because they said that they've used the *nix shell, what does that say about the company? To me, it says shit job at shit company. YMMV. – Joe Internet Sep 29 '11 at 1:54
  • 1
    @Christophe - If you're hiring capable *nix programmers, IMO it's fair to assume that they "that they know their way around the command line". If you're hiring capable other-OS developers, IMO it fair to assume that their *nix command lines skills are minimal. Group A doesn't need to be tested, group B gets an automatic fail, so why bother testing them, either? If your criteria for hiring a software developer is based on how well they use the command line, well, I think that your hiring process is flawed. It would be different if shell scripting was the main responsibility of the position. – Joe Internet Sep 29 '11 at 9:57

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")


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.

  • 1
    testing of vi commands, sheesh, I'd be more worried if they knew them all – NimChimpsky Sep 28 '11 at 7:08
  • 1
    well if the guy reaches for Google and starts typing in search field stuff like "vi Editor commands" then I'd consider testing passed 90% :) – gnat Sep 28 '11 at 8:09

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.


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.

  • 1
    but you interview candidates to do work not to learn. – NoChance Sep 28 '11 at 9:35
  • 1
    -1 @Emmad. So you have never learnt anything in any job you have had...? – user4234 Sep 28 '11 at 10:56
  • 3
    -1 @EmmadKareem all work is learning in some way. – Nicholas Smith Sep 28 '11 at 11:35
  • Yes learning is expected to an extent, however, unless the role is trivial I expect the candidate to be productive in about 2 weeks of hiring, on average in Canada this would cost me $3000! Unless the skill is rare, this is what I expect. – NoChance Sep 28 '11 at 12:24
  • Sounds like Emmad is a person I would not want to work for, along with the OP. – kirk.burleson Oct 16 '11 at 2:43

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.


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.


'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.


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.


Unix gurus have core commandline commands such as sed, grep etc. in one finger and can easily use them to achieve what they want, using all kinds of quotes, advanced regular expressions etc., so sometimes you see the script and think it would be easier to understand beeing written in Chinese ;)

You can expect that, independently from shell programming, they will know at least one additional scripting language, such as Perl.

They would know configuration internals of Unix system, so if you ask them to change keyboard layout (f.g. add some binding to right alt + ) they wouldn't be confused.

Managing installed packages also would be no problem. Installing Oracle, running 4 application servers, each with other JVM - also no problem. Virtual network configuration, advanced routing and port filtering, virtual machines etc., managing security - also goes there.

  • 2
    The question is about testing whether a developer has general Unix skills, not identifying guru sysadmins who have a particular focus on Oracle and Java. – Peter Taylor Sep 28 '11 at 12:41
  • JVN? What's the Jewish Volunteer Network got to do with this? – ocodo Sep 29 '11 at 1:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.