One of the things I do at my present job is interview candidates for my team, and occasionally other teams too. I estimate I’ve seen ~150 people over the last 5 years. Of those very few that I do say “hire!” based on 2×1-hour interviews, talking in a meeting room rather than watching them actually do work, the vast majority turn out pretty well, as in, they do turn out to be highly productive. The strategy I use for this is something I call the leap of logic. Firstly, I establish that a candidate knows some basic facts, then I ask a question requiring them to synthesize some new knowledge.

Here is an example from a recent interview, for an Oracle DBA position. First, I asked the candidate if he knew what was an SCN was, and he did. Next I asked about incremental backups, and he knew what those were too. Thirdly, I asked him if he knew what a physical standby was, and again, he did. All good so far, but these are just facts that can be recited from memory, or looked up on Google (as I did to make those links!). A better measure of a candidate is a realistic problem to solve, so next I described a scenario in which a standby database is stuck on WAIT_FOR_GAP and All defined FAL servers have been attempted, and the archived redo log is no longer on the primary (e.g. deleted by a naive cron job† that catches everything older than a day). He replied that the only way to solve this problem was to completely rebuild the standby, as if setting it up for the first time. I reminded him of the previous three facts we had discussed, and asked again, and got the same reply.

Now a strong candidate would have thought about this (out loud):

1. I can easily find the SCN of the standby database
2. A physical standby database is a block-by-block copy of its primary
3. I can do an incremental backup of the primary from that SCN and apply it to the standby.
4. Then resume log shipping (having stopped deletion on the primary if the previous step would take longer than the retention period)

Of course, in that particular case, it is a documented technique, tho’ if you hadn’t happened to have read it, it’s still obvious, particularly when you have established all the underlying facts already. In fact this is true about most things in IT: if you grasp the underlying principles then, even if you don’t know the specific command or syntax‡ off the top of your head, you can probably figure out the solution, or at least, be able to re-frame the problem in a way that someone else can jump in and help with just the piece you’re missing. At least you know what to ask or what to look for. There was obviously more to the interview than just that, but with a few other other scenario questions, a clear pattern emerges, giving an accurate picture of the candidate. That’s the point of thinking out loud, and freezing up is the last thing you want in a DBA when there is a production outage! Those are the kinds of people I look for, and this experience sets me up very well when I am on the other side of the table.

I wrote a few months ago about a slight sense of ennui with my present role; the time has come to do something about that, so next month I join the dangerous, glamorous world of algo trading. The people that I’ve hired will get along just fine without me (tho’ some of them should have been paying more attention over the last few years to learning Python!) and so will the organization… if it manages to hang onto them.

† Unfortunately, even in these days of RMAN, those are still common
‡ For this reason, I almost never ask candidates to write code on a whiteboard, tho’ sometimes I will have them draw a diagram