I've been doing the inestimably exciting job of helping my client find a replacement for me when I leave this summer. They apparently want to hire someone in-house, so I've been doing the technical interviews.
Right at the moment, I program Java, administer Oracle, and handle Unix administration. I'm a decent Java programmer, a competent Oracle DBA, and an expert Unix administrator. The main role they want to fill is Unix administration. This job, more than any other I've ever worked, hits the edge cases. We've seen a lot of "gotcha" situations. I frequently see, for example, df and du report different free space on a filesystem. So when I interview these guys who are wanting to replace me, I ask them about the real-life problems we face daily.
Now word is going around that I'm not a very good interviewer, that I'm more interested in showing off what I know than I am in finding out what the candidate knows.
It's probably true I'm not a good interviewer: I might well be the worst interviewer anyone's ever had to work with. But let's consider some anecdotal evidence:
- One candidate couldn't figure out how to start a service on RedHat EL from the command line ("I've always used the gui.")
- Another insisted that if df reports a full disk, but ls disagrees, df is wrong.
- One guy insisted you can only have two plexes on a RAID 1 set.
- So far, no one interviewing to administer Oracle servers can tell me what a tablespace is.
So while I may be the worst interviewer in history (and I probably am), it's no stretch to suggest the candidates they've been throwing at me aren't qualified to administer Linux Oracle servers for uptime-sensitive applications where down-time is measured in tens of thousands of dollars per hour.