The 5 DBA Interview Questions You Have to Ask

Because the answers might surprise you.
An interview should be a conversation, not a trivia contest. I’m not looking to stump someone during an interview. I don’t need for my DBA to know obscure facts such as database mirroring is only supported starting with SQL 2005 SP1.
Memorizing such facts does not mean that you will handle the pressure of being a production DBA. The role does not require you to know the answer as much as being able to find the answer. And in order to truly be successful as a DBA you will need good communication skills. A good DBA will be able to teach, and train, others.
So how do you find such a person? The answer is easy: you talk with them. I always describe the interview process as being a lot like dating. You want to have a conversation, get to know someone, without assuming anything beforehand. Since people tend to embellish on their resumes, if you aren’t familiar with a person or their previous work then you are going to want to set a baseline. For me, that baseline are the following five questions that I have used over the years. I find that they help guide me through having a good conversation and by the end I know whether or not I want to call them again in the morning.

1. What is a database?

I always like to start with the basics. While it may seem silly to ask this question keep one thing in mind: there are no silly interview questions. No matter how ridiculous a question may seem to both the person asking it and the person responding, they will always serve a purpose. In this case you may find the candidate talking about MS Access, or Filemaker, or whatever they have been exposed to previously. Let their response be an indication of their fundamental knowledge of some RDBMS system. See if they can explain the difference between a data and a log file, for example.
Remember, people tend to embellish on resumes. If you have never met the person before, why not ask the most basic question you can, right from the start? The answer may surprise you, but the conversation is likely to reveal the depth of their experience right from the start.

2. Who is the most important user of a database?

This question helps you get an understanding if they candidate knows who the “stars” are. And who are the stars? Well, everyone. That’s right. Every connection to a database server is as important as any other. What’s that? You say it is only a development server, so it is not that important? Well, a development server is considered a production server to a developer. In other words, every person and every connection is important, no matter if they sit in the corner office or not.
I once had a candidate tell me that the CEO was the most important user, and they were adamant that they were right. Sadly, most CEO’s aren’t doing the day-to-day data entry that others are doing, so I found it hard to agree that such an absolute answer was correct.
If the candidate lists out only a handful of people or groups as important and fails to understand that everyone is important, consider that a red flag.

3. Which is faster: Inserting one million rows of data, or updating one million rows of data?

This could be one of the more technical questions you could ask a candidate. You are not looking for the correct answer (which is “it depends”). If they do answer correctly then examine the scenarios they lay out before you. It should be very insightful, you should get a real sense for how they think. Chances are they will guess at one or the other, which gives you the chance to talk with them. And when you do so, take the opportunity to see how the discussion goes. If they ask you lots of questions, that is a very good sign. If they just sit there, listen to your every word, accept everything you say as the truth, then consider that another red flag. No one is perfect, not even you, and you do not want to surround yourself with someone that just follows your every word. You need someone that is insightful enough to ask you more questions, you want someone that is always looking to learn.
I recall asking this question once and was told that it was a trick question because you couldn’t update (or insert) that many rows at once, you could only do them one at a time. Yes, that’s right, they told me that everything was done through cursors, and didn’t understand the concept of set-based updates.

4. If I asked you to learn how to make a query faster, what would you do?

Does the candidate look like a person that shows some ambition? Do they read any web sites with regularity? Have they ever opened a user manual, or the BOL? Who do they consider to be an expert? Do they have their own library of books, or their own toolbox of scripts? How do they typically attack a query with regards to performance tuning?
If you need a DBA that can help troubleshoot poorly performing code, and to do so quickly, then you want to make sure they aren’t the type to panic when the pressure is on. In short, find out how would they start to look for answers. Which also happens to be a great segue into the final question…

5. How do you troubleshoot problems in your current role?

The ideal candidate will be able to clearly explain their thought process in how they troubleshoot something. Developers will most likely discuss with you some piece of code that worked well on one server but not on another. A Windows admin might talk about a service that stopped and would not restart no matter how many times they clicked on that little arrow. In either case, you want to identify someone who is articulate to a certain degree, can explain themselves, stand up for their decisions, and also be open to the possibility that there was more than one way to solve the problem at hand.
You need to know more about their thought process when it comes to solving problems. If their troubleshooting skills consist of “call the vendor for help”, that won’t suffice. You don’t want someone with all the answers (and such persons don’t exist anyway), you want someone that has a clear and defined thought process.
In addition to the questions, and the conversation that ensues, you are also going to want to evaluate the candidate in other areas. For example, you can look for certain things that would have the candidate stand out among the others, or where they fail to measure up.
And there you have it, my five questions to ask of any DBA in an interview. You can alter these to fit your needs for whatever role you are trying to fill, just keep in mind that you want to frame everything in the form of a conversation. After these five questions you can move into more targeted questions with any candidate that has done well.
If you can follow this outline and have a good conversation then you are going to be able to identify the right candidate.