[svlug] Interview questions?

[Akkana Peck]

lordSauron writes (re keyboard shortcuts):
> They really don't, but it's the people that don't know and refuse to
> learn that should be kicked out.

Well, certainly they'd better know basics like ^C (as Bill K. says,
that's like knowing which one is the brake pedal). But keyboard
shortcuts in general? As a major fan of keyboard shortcuts myself,
it's fairly clear to me that a lot of people (even established
developers) don't use them much at all, and rely on the mouse. It's
a matter of taste, and someone not knowing ctrl-alt-backspace or
ctrl-alt-keypad+ wouldn't necessarily make me think they didn't know
Linux.  (I only use ctrl-alt-keypad+ myself because it's sometimes
handy when using a laptop to connect to projectors.)

However, you could test a candidate's comfort with man pages
using uncommon problems like this, e.g.: Someone asks you what
ctrl-alt-keypad+ does. Where would you look to find out?
What if you couldn't use the web? You can find out whether they use
apropos and man intelligently, or, alternately, whether they know
where the man pages are located and know how to use grep. Either
answer demonstrates knowledge, and it might be interesting to see
which approach they take.

Some other useful QA questions:

I like the kill/ps questions that have already been mentioned.
You could add some additional questions to test their understanding
of what they're doing, such as: What's the difference between ctrl-C
and ctrl-backslash, and how would you do the equivalent using the
kill command? (If they don't know the signal names or numbers
offhand, that's okay if they know where to look them up.)
How would you stop a process temporarily, then continue it?
A program seems hung and you want to kill it: what do you do?
What if your first approach doesn't kill it: what next?
What if you don't want to kill it, but instead want to find
out where it's hung: is there anything you can do?

How would you get a stack trace from a program that's crashing?
What other useful things might you do while you were there?

How do you record the output of a program, in case you want to
refer to it later?

Bonus questions (not strictly needed for QA, but does test mastery
of Linux) might test how comfortable they are with pipes and
redirection on the command line. Maybe a sample problem that
involves using grep | sort | uniq or grep | sed. But I've known
lots of competent QA people who might not be able to answer that,
so I wouldn't refuse to hire someone based on lack of shell
pipeline knowledge.

	...Akkana