Interviewing DBAs: Check their Business Decisionmaking

When interviewing a database administrator, it’s not enough to check their knowledge of technical skills: we have to check their ability to make sound business decisions. DBAs are in a position to make a lot of architectural decisions with long-term ramifications, and in smaller shops with just one or two DBAs, these decisions won’t come out into the open until it’s too late.

I interviewed a DBA candidate recently who demonstrated why this was important. His technical skills were solid: any technical question I asked, he was able to cover. He didn’t necessarily have all of the skills we were looking for, but hey, who does these days? SQL Server is a massive product with thousands of niche features, and nobody can be expected to know everything. On a technical basis, I knew this candidate would get the job done.

The problems arose when I started asking business-oriented questions like, “It sounds like you’ve got a lot of SSIS and DTS packages, plus a lot of Agent jobs. How do you monitor all of them?” He responded by saying that they each sent an email at the end of the job, and every morning he checked his email to see what happened overnight.

Ouch. I don’t know about your shop, but at my shop, that’s too late, and it’s too single-point-of-failure. In a situation like that, I know that DBA can never take a vacation, and that’s bad for both the DBA and the shop. It leads to early burnout, and it sounded like that was the exact reason the candidate wanted to bail out of his current job.

There was nothing technically wrong about his answer: SQL Server Integration Services does have some pretty good error handling and alerting. The issue is that in a shop with only one database administrator, hand-coded error alerting is going to be tough for the next DBA to interpret. He’s going to turn in his two weeks notice, and the company won’t be able to hire a new DBA fast enough to do knowledge transfer. I feel sorry for that new DBA.

I’ve been on the other side of this, too: in my job hunt last week, I interviewed with a company and had the good fortune to be able to talk to their exiting database administrator. I asked him the same question, but this time as a candidate: “Tell me about your alerting systems.” The DBA proudly talked about his hand-coded monitoring systems that checked every server for things like blocking queries, CPU use, etc., and stored it all in tables we could query.

Grrreat. You mean to tell me that out of the dozens of server monitoring packages out there, not to mention the ones targeted specifically at SQL Server, you couldn’t find a single one that did the job? And not only do I have to take over your database servers hoping you were a decent DBA, but I have to take over your code hoping you were a decent developer? I made a note of that, and had I taken that job, I would have made it contingent on immediately buying a third party server monitoring system that I wouldn’t have to maintain. Starting as a new DBA is tough enough.

In both cases, that’s a bad business decision. A good DBA has to look out for the company’s interests, and has to do it with the knowledge that nobody’s double-checking the DBA’s work.

So when interviewing for a DBA position, whether you’re a candidate or the manager, ask not only how the SQL Server jobs are managed, but how the next person should expect to take that over.