jfm3> _

1. Hire System Programmers instead.

There was a time when an engineering or research group could afford only one multi-user computer. It then made sense to have a full time "system administrator" manage it. The system administrator was responsible for managing user accounts, installing new or updated software, performing backups, and troubleshooting. Now everything is different. Modern analogous installations have hundreds, if not thousands of computers, and the number of infrastructural concerns includes tens of new jobs, including monitoring, networking, sizing, budgeting, provisioning, reliability engineering, logistics, security, and so on. These concerns are now as complicated and important as the applications. Yet commonly, the role of "system administrator" persists as somehow subordinate to programmers in most organizations. This leads to interview processes that tend to rate system administrator candidates on the amount of trivia about system software that they know (e.g., "what does the fping command do?"), as opposed to their aptitude as engineers and programmers. The "certification" process, by which operating system vendors drill system software trivia into candidate's heads, also suggests hiring someone by finding out whether or not they need to refer to the manual. Of course, there's nothing wrong with refering to the manual more or less constantly, and given the rate at which software changes, having someone who is unafraid of learning new things is a great asset.

Hire someone who is as good at programming and engineering as any of your other software developers. Consider changing the job title to "system programmer" or "system engineer."

2. Interview about what is happening now, good and bad.

During the job interview, there should be a great deal of back and forth over what the candidate is doing presently, and the work they are a candidate for. Compare the two, and talk about both good things and bad things. This will give you a very good sense of how the candidate works as an employee, and a picture of the breadth of their knowledge. Even recent graduates will have done some related work non-professionally, but recently, which you can talk about.

3. Get a presentation.

Ask the candidate to prepare a 15 to 30 minute presentation on relevant topic. Something like "file system performance tuning" or "transport layer security with SSH" is the appropriate topic size. "Networking" is too vague, for example. "Apache configuration" is too specific. Leave time for some vigorous question and answer at the end. Communication and negotiating skills will be clearly tested. You will also get a good sense of how deep an understanding the candidate is capable of reaching given some time to prepare, which is a good simulation of how things will go on the job.

4. Contract to hire.

Before deciding to hire them, you want to at least see the candidate solve a problem. The trouble is you can never contrive a problem that captures all the elements of real problems. Things like tenacity, handling stress, political skill, and aptitude for learning new things all get factored out when you ask a candidate to solve a problem during a job interview. In fact, you can't even fit a reasonable problem solving exercise into the six and seven hour marathon job interviews that are currently popular at technology companies.

The solution is to contract the job candidate for two to three months before you hire them. This is great for both the candidate and the company, as everyone gets to see how things will go in a permanent position before any real commitment is made. For purely cultural reasons, a lot of companies and candidates shy away from these kinds of arrangements. They can certainly be misused, for example if a company really has no intention of hiring but thinks they'll get better work out of a contractor if there's the promise of full time employment. But assuming nobody is acting maliciously, it's good for everybody.

Labels: linux, system administration, unix