Catching up, I see nobody addressed this post. On 2013-05-07 at 07:56 -0700, Corey Quinn wrote: > This is why I hate trivia questions as a gauge of skill.
If someone's asking trivia, they're making a mistake. If someone's asking something that sounds like trivia, there may be a communication mismatch. A good rule of thumb is that you should not interview for specific knowledge, but to find the rough bounds of the sorts of thing the person knows, whether they have a good idea of how much or how little they know (Dunning-Kruger effect) and whether they're honest about what they do or don't know. This of course just being one small part of a larger assessment, but even in a technical interview, figuring out if the person readily spews nonsense with a straight face or if they can be clear about what they know and what they guess will tell you a lot about how reliable they are to work with. > "What flag to date(1) will spit out time in seconds since epoch?" How does the date command work? What clocks does a modern Unix system keep? How do modern Unix systems keep their clocks synchronised? What is a timezone, how does this impact you? Do you keep your logs in UTC or in local time? > "What's the numerical file descriptor for standard error?" What are the uses of standard out vs standard error in Unix programming? How might you go about getting stdout from a command piped to a second command, while grepping out some lines from stderr to reduce known spam? That tells a lot about basic scripting ability. (But honestly, if someone claims 5+ years of Unix sysadmin and claims to have done some C programming, not knowing STDERR's fd number is a major warning sign. It's one of those things you can't help but know. It's only just below claiming C skill but not knowing that the program execution entry point is normally `main()`.) > "What port does DNS listen on?" How do hostnames work on the Internet? When would you use /etc/hosts or LDAP or DNS? What issues annoy you the most when maintaining DNS zones? Have you ever played with DNSSEC? What did you think of the tooling? > If someone gets a few of these wrong in a row, they start thinking "Oh > crap, I'm bombing this interview" and shut down. At that point you're > less and less likely to get anything useful out of them. I think that's part of the point that Tom was making. By starting off at a very broad and simple question, you get to drill down not by a script, but by interacting with the interviewee and discovering where they're strong, where they're week, and guide them to spot issues while not belabouring weak areas *unless* you're analysing how they deal with exploring something new to them, which you try to only start on once they've settled down a bit. For myself: I *really* like "How would you delete a file named -f?" That can be adapted based on how many years of Unix experience someone claims on their resume. If they claim two years, getting to a right answer is nice. If they claim ten years, but don't understand that the shell handles both quoting and globbing, how argv and getopt play into things, don't understand pathnames and so forth, then it's more of an issue. And if the answer given doesn't include quoting, saying "Other candidates have suggested quoting the answer; how well would that work?" can be really informative, separating out those who've learnt a rote answer for a popular question from those who understand the issues that lead some other answers to be wrong. -Phil _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
