To be honest, I am doing extensive UNIX shell programming for over 20 years now and as (far as I can remember) I never had to use “$?”even once (and “$!” maybe 5 or 6 times in all those years – I actually had to look both of them up right now to see what they are standing for…). Which of course means that – according to your test – I am not very experienced regarding shell programming, am I?
Asking for something which can be found out with a simple ‘man bash’ when I need it is IMHO not a good way to check how experienced people are, but how good their memorizing skills are. Most people mix those two things up all the times. In my personal experience most of the people who can memorize everything aren’t always the best programmers (I often found that quite the opposite is actually true, besides some remarkable exceptions), but of course YMMV…
The same is true when asking for some exotic options to well known commands (e.g. asking what the option “-h” of tar does – do you know it?). This doesn’t say anything about the programming skills of the candidate (or even his experience. It only tells you that he either memorized the manual page or had the problem with missing files in the tar file (which he sent to the customer) because of symlinked files once.
A good programmer has to know about algorithms and data structures and – especially for shell programming – and of course about the pitfalls of regular expressions (and the possible differences between sed, perl, awk, grep and others!), quoting and globbing. Which is why I think the question of the thread opener is much better to check if people really understand what they are doing or how to get things done. ‘basename’ is such a standard tool that everybody doing shell programming should at least know it (and if the guy knows the correct syntax with korn/bash shell parameter expansion “${parameter%word}” or “${parameter/%pattern/string}” instead of basename for this – even better! Which of course means you shouldn’t expect exactly the same answer you had in mind… TIMTOWTDI ).
I am always annoyed by quite stupid tests which could be easily solved by just calling “man”. To know for which command you have to call “man”, that’s always much more important. Even if he only knows that there is some command (or function) which does what he needs (but he can’t recall the name of it right now, because he only used it 10 years ago once) shows that he is experienced. To find out what the command or function was called again is a matter of his Google-Fu to look it up (which is btw. another skill which shouldn’t be underestimated!).
Telling the candidate things like “you have to search some csv files for a text string and need to print out the 5th entry for each line where the string is found” and asking how he would solve this is always a good way to tell how much experience he has (as we all know, you can use awk, perl, sed and even ksh/bash parameter expansion in combination with e.g. grep or even some more exotic things to do this task) and by doing so you directly see what he prefers and how he solves problems. E.g. if he remembers that the text could include another comma as well, so he has to check for quotes around the text fields in the csv file as well is always a good sign of long running experience. And only expect the really, really good ones to get the needed regexp correct in just one go without writing it down…
Regarding the last four questions you mentioned: You can use them to actually find out if the candidate ever used a UNIX/Linux shell at all. But IMHO those don’t tell you anything about his scripting skills (and I would call those the absolute minimum for even a level 1 person in the UNIX/Linux area).
But as others have said, what does this tell you about the candidate? It doe not tell you that they are good or ghow they think, it just tells you that they know the obscure stuff or you know more obscure stuff than they do. I am amazed that organisations such as this spend thousands recruiting for just one post and yet they dont take the time to train their interviewers in how to get the best level of information from their candidates. It is not just Morgan stanley, I have worked for a number of organisations and only 1 has bothered to give interview traingingt o hiring managers, and none of that involved asking obscure technical, or theoretical, questions that show you know more then the candidate.
Most interview decisions are actually made in the first few seconds, sometime you know before you get out of the lobby and into the meeting room. Once you have made that decision you should be reinforcing the decision by establishing what they have done in the past, is their CV accurate, do they know the tschnologies we are using (to be able to use it every day) and can I work with this person. Being able to work with somone, IMO, is far more important than do they know the answer to some of the questions that I have been asked at interview.
I do one night google/online study I may be able to answer some of the following questions if I am lucky enough. But it doesn’t really show you if the candidate is capable of learning things by himself. Many information can be retrieved from the man/info page when I need (man vms_define_subscription, info bash). Also I go to msgoogle/google when I need more background.
I was often amazed people came to the questions well documented on wiki pages. It is a waste of time going through the same again and again with different people.
And don’t forget http://faq.ms.com where people share so much useful info. I think the real capability I am looking for is self-learning
Honestly if I get asked weird or stupid questions in an interview I will be looking for a job with another company immediately – because if the company wants me to answer stupid questions in an interview already, I can be quite sure that this is not the type of job/position I want to do in the first place (because I have to fear that later on even more stupid things might come my way)…
Or more precise: If I am applying for an IT position and the interviewer asks me “How much water has Lake Erie?” I would simply tell him to look in up in an encyclopedia – that’s what they are for. And then I would ask him what this has to do with this IT position and if he can’t give me a very good and reasonable answer (something much better than “I wanted to find out how you react to unrelated questions”, because this would be the EXACT answer I sure don’t want to hear, because this would give me very poor prospects for the type of work and problems I might encounter when working for this company and tells me that the company most probably has problems with managing responsibilities because I have to expect questions which don’t belong to my job position/type of work), then I’m gone.