Don't ask 'manpage' questions in interviews

One of the things you might see a lot on sites like LinkedIn is the recommendation to not ask interview questions for stuff that is easy and trivial to look up. For example, asking about command line options to a program. To an extent I agree with this. I always need to look up the “key field” options to the sort command (especially since they changed from when I learned the command!).

Indeed, when I interviewed for a job in 1999 one of the questions was “How would you count the number of times each shell was used in a NIS password map?“. Off the top of my head I said

ypcat passwd | cut -d: -f7 | sort | uniq -c | sort -nr

Well, what I really said was “ypcat password filtered through cut minus d 7 (umm, I think it’s field 7; I’d need to check the manpage) filtered through sort filtered through uniq minus c (shrugged shoulders) filtered through sort minus nr (to get them ordered by use)“.

And that’s the thing; I knew the commands and how to put them together; but a trivial detail like the right field of the password file is easy to look up (man 7 passwd) that it’s not really important.

When a joke taught me something

Back in the long distant past I remember a joke going around Usenet that the ls command had so many options to it that it was harder to find a letter that wasn’t an option. So I added a joke question to the list of questions I asked people interviewing for a senior security engineer role. This was for someone who was going to build code that would run on 60,000+ different machines across multiple different operating systems (primarily RedHat, Solaris). I’d already dug deep into their knowledge of PAM and NSS and SSH, so I thought to lighten things with an easy joke question:

This question is a bit of a joke; there’s so many options to the ls command, can you list 10 of them and what they mean? I don’t expect you to get 10 and don’t worry if you can’t; it’s just a joke question.

Now this breaks the “don’t ask manpage questions” guidance.

I thought it would be easy. After all I use 4 options (-lart) daily; easy to remember for anyone who had spent time in the Scary Devil Monastery (SDM) on Usenet. And since the early ‘90s I had alias ls='/bin/ls -F' in my profile. So coming up with 5 more would be easy.

I just went about it logically.

We start with

• -l - long listing
• which leads to -g for group information (bonus points for mentioning the historical difference between BSD and SysV implementations of -g)
• also leads to -L for following symlinks
• -a - all files
• which leads to -A for all files except . and ..
• -r - reverse sort
• Which leads to -R for recursive lists
• -t - to sort by modified time
• which leads to -c for metadata change time
• and to -u for access time
• and the -c takes us to -C for forcing column based output (e.g. in pipelines)
• which takes us to -1 for single column output
• Inhabitants of SDM might also have heard of LARTd (the LART daemon) so we have -d to show the directory and not the contents of the directory
• And I use -F to add a filetype marker (e.g. * for executable, @ for symlink) to the output

So, yeah, I could get 14 without really thinking, just by following a chain through a starting point. There are other options I’ve used in the past, but that’d take some thinking and, yes, checking the manpage to remember them :-)

So, sure, I thought 10 would be an achievable goal.

What I learned

Only 1 person was able to get 10. That surprised me.

One person mentioned an option I didn’t know (from GNU ls). Another used GNU long options (which was fair; I hadn’t specified traditional options).

What surprised me most was that some people didn’t understand that -al wasn’t an option, but was two options (-a and -l combined). That’s almost a basic convention of Unix; how can you go for a senior role without knowing that basic knowledge?

And what disappointed me was that no one took a logical approach; they just tried to remember stuff they’d used in the past. Where I took a “l leads to L; t leads to c leads to C leads to 1” approach, they just struggled.

When I mentioned some options to people (e.g. -A) and asked them what it did they didn’t know. Which, to me, feels like they didn’t know the functionality of the command and what it could do. This could have led to inefficient code or poor scripts where they had to work around problems that didn’t have to have existed.

Summary

It turned out that my joke question caused interviewees some stress, even when I emphasized the joke nature of it. But I did learn a lot from it!