ProfessionalSQL

So, today, I was working on a case interview for a new Production DBA position. For those who have no idea what a "Production DBA" is, think of it as a somewhat typical implementation of the DBA (A as in Administrator in this case), only it is supporting database implementations of a specific application suite for a large number of customers (say, 75 of them). The case interview is one where we step outside of specific technical questions, and instead focus on problem solving and analytical skills.

 How does one figure out if someone is a good DBA?

I'm not going to give away the particular problem that is posed in this particular case interview (lest any of the interviewees happen to read this post and get a pointer), but I was struck at the relative difficulting in asking a DBA a good, well rounded question that tests their ability to do more than manage a checklist of "things to do" (i.e., backups complete, tapes changed, procedures tuned, defrags run, etc.). The problem is fairly simple - being a DBA means wearing quite a few different hats, and someone that is not so great in one area may be stellar in another.

Fortunately, the idea behind the case interview doesn't necessarily require expert knowledge in any specific area - instead, it is all about figuring out what questions need to be ask and forming logical conclusions based on that question. For example, if I posed a question about troubleshooting poor performance, I would expect a set of questions that followed a set of logical steps. In technical interviews, I frequently hear people mention profiler first, but, in practice, I would expect the average DBA to ask several questions before deciding they need to fire up the SQL Server profiler. For example:

• What exactly is "poor performance" in this case? What kind of problem do I think I have? Is it a blocking issue, an amount of work issue, a deadlocking issue?
• Is the problem already specific? That is, is it a specific part of a process or particular report that is performing poorly, or is my whole system bogging down?
• Does the nature of the problem indicate that it is a database issue at all (I can't tell you how many poor performing reports or web pages have had more to do with the complexity of what's being painted on screen than getting data)?

Profiler is a somewhat cumbersome tool in my not so humble opinion, so why run to grab a hammer and nail when you might only need a push pin?

This gets to the point of the case - are they able to analyze a problem or need logically rather than jumping to a conclusion or simply guessing based on an area they are comfortable with? Furthermore, do they have enough confidence in their own ability or thoughts to stand up and explain their reasoning if they are challenged?

A DBA is often faced with problems that don't fit a checklist or problem solving tree - they have to think. They are also often asked for opinions (should I do it this way or that way? How often should I back this up? Do I need offsite storage?), and they need to be able to analyze and resolve non-standard issues.

What kinds of questions do you ask administrator or development candidates? What questions have you been asked that caused you to think: "Wow, that's a great question?"