During the interview, I ask basic database design questions. Normalization (When-Why) is one of my concerns when it comes to database design. Some scenarios I site that involves synchronized servers and what/why/how they take consideration of related issues; security issues and so on.

  1. Would you ask them from the context of a particular database system (e.g. Oracle) that they prefer?
  2. What sorta technical questions would you ask them?
  3. What scenarios would you site and what would you be looking for as answers to those scenarios?
  4. How would you find out if they are knowledgeable in handling security issues?
  5. Other related questions. (e.g. DB Restore/Backup)

Thank you.

6 Answers 6


Here's my top 10 interview questions for senior database administrators, and here's Tom LaRock's top 10 questions for junior DBAs.

I've noticed other people suggest that the candidate should troubleshoot a server. If you take that approach, use a virtual machine with a snapshot. Set up a server a specific way with certain config or performance problems, take a snapshot of it, and then after every interview you can roll back to the snapshot.

If you do that, confine the tasks to the kinds of tasks you'd actually have them do. Don't ask a production DBA about normalization, and don't ask a development DBA why one node won't join the cluster.

Production DBA tasks might be:

  • Set up jobs for backups, index maintenance, and DBCCs. See if they ask you how often you want the database backed up, and if you want it backed up locally or across the network. Don't ask them how to configure a particular tape backup software unless it's already on their resume.
  • Find out why Johnny can't log in and run his query.
  • Someone's complaining of a slow query. Show me where you'd look to find out what's going on. Then say they just called up and said their query finished, but they want to make sure it doesn't happen again.
  • Restore a single table from last night's backup.

Development tasks might be:

  • Debug this stored procedure.
  • Interpret this execution plan.
  • Create a view to join customers to invoices.

Use the AdventureWorks schema. Odds are they haven't played with it recently, but at least it's easy to explain.

  • 3
    Really? That junior DBA question list is ridiculous. Those are questions I would get correct answers from developers after their first term in college. I like the Sr. DBA questions a lot more, except for the "I’m a developer. Explain why I need a unique key on my table." I guess it's because I want to believe developers already know that. I'm a developer and don't know any that can't take on at least a Jr. DBA role :o
    – Gromer
    May 25, 2009 at 18:35
  • 5
    You'd be surprised. I've interviewed dozens of DBA candidates for six-figure jobs who didn't have the answers to Tom's questions.
    – Brent Ozar
    May 26, 2009 at 10:55
  • 2
    Ditto to what Brent said. Having conducted numerous interviews, I've had quite a few candidates come in who couldn't answer those junior DBA questions, despite a resume that said they had 10 years of Oracle and 5 years of SQL Server and an OCP and MCDBA cert. May 27, 2009 at 14:40
  • 3
    I'm also getting a chuckle out of Gromer's remark about wanting to believe developers already know they need a unique key on their tables. If I had $1 for every consulting engagement where I walked in and fixed performance problems just by adding primary keys - oh, wait, I do, and it's a lot more than $1. ;-)
    – Brent Ozar
    May 27, 2009 at 20:30
  • 1
    Remember, we're talking about screening out developers you DON'T hire. Sure, you're around smart developers - but only because you didn't hire the losers. These questions filter out the losers.
    – Brent Ozar
    May 28, 2009 at 12:17

In my software team as part of the interview we test for Databases understanding.

We present - a very poor design (think CRM type application) and ask them to improve the design, after around 30 mins of thinking time.

We then ask them more questions based on what they talk about.

We are probing for understanding of

  • Performance V Normalistion
  • Key Design and Referenital Integrity
  • Places for improvment -ie Alternative DB Structure - Triggers, View, Procuedures
  • Areas that are weak in the design - how to overcome many to many relationships
  • How this affects the server - maintaince
  • Data Security Issues
  • Application Security Issues

We as a team have then thought about what we would consider to be Junior/Senior/Architect type answers to these types of questions.

So for - Performance v Normisalation -

would see the issue in the first place and be able to discuss why (Junior)

would recommend 4/5 NF but understand the issue with performance would they denormalise and understand how to articulate the issue(Senior)

would they recommend a different type of design eg Star Schema and discuss the implications on many levels(Architect)

  • Key Design and Referential Integrity

Would see the ref integrity is needed to enforce data relationships and be able to discuss this but would not see the issue with Key Choice and Design (Junior)

Would discuss issues to do with data volumes and data types v looking for natural keys in the data and would be able to discuss why they are looking at these - and the issues that follow with referential integrity (Senior)

Could argue various viewpoints to do with Keys and Integrity and be able to come up with various actual models for fast design (Architect)

You get the picture.

If you want me to add more then post comment and will detail what we think about the rest but just included the first two to give you the idea on what we thought.

The point is to think about the 1. the questions 2. We as a team have then thought about what we would consider to be Junior/Senior/Architect type answers to these types of questions.

I emphasis the team as the candidate and the team have to be confident in the skills of the person coming in, and if they have come up with what they see as answers to different levels the person coming in will hopefully fit with team better. It also gives the team the ability to influence the candidate choice. They also nominate a person to be on the question panel. Helps a lot with team buy-in.


You could make up a fictional database in which there were a few normalization problems, potential security glitches but that in general looks pretty typical, like an employee database. You could then start by asking the interviewee simple questions along the lines of how they would go about getting certain data in the database through joins, working your way up to harder questions about the normalization and secutiry issues.


See Smart and Gets Things Done

... and ask them what books they've read lately, what blogs they read, and what podcasts they listen to. And ask if they participate on stackoverflow.com and serverfault.com ;-)

  • 1
    And do a criminal background check too, if they are going to be dealing with sensitive data. You DON'T want somebody who is smart, gets things done, and is evil ;-) May 27, 2009 at 19:47
  • 1
    See Steve Yegge's blog post about Joels book: steve-yegge.blogspot.com/2008/06/… May 28, 2009 at 14:01
  • Thanks - Yegge's post was fun and thought-provoking. I especially liked this: "You want someone who's superhumanly godlike. Someone who can teach you a bunch of stuff. Someone you admire and wish you could emulate, not someone who you think will admire and emulate you." May 30, 2009 at 12:40

This isn't necessarily database related, but things I like to add to an interview are hands-on problem solving and a design scenario.

For the hands-on issue, have a system or systems that the person can access and have them troubleshoot an open ended issue. My personal favorites here are performance issues, as it not necessicarily something that can be reproduced on demand for an interview and there is rarely one correct answer. Instead, you can watch the candidate run through their troubleshooting process and they will also need to open a discussion with you to get further information about the environment. The key is to for the interviewer to be honest about the problem and not turn the scenario into an easter egg hunt for the one misconfigured setting or something like that.

For the design scenario, I give the candidate a general outline of a new project (i.e. no legacy dependencies) and ask them to come up with a general design in their particular area (whether DBA, systems or network) that meets the project goals. The key is to keep the project small enough that someone could keep the whole scenario in their head and it doesn't take more than a few minutes to explain.

An example I use here for my systems and network people is to describe their design for a small branch office being set up, given certain constraints of our business. On the DBA side, maybe use a small/obvious CRUD application. In either case, you aren't looking for a detailed design but more of an overview and see if the candidate looks for the common problems that come up.

The important point for both of these scenarios is to open a discussion on the topic, and let the candidate lead the discussion with their own questions. It should be clear that you are not asking for an exact answer to either.

As you can imaging, I greatly dislike trivia in interviews, and I think this gives me a much deeper understanding of the candidates abilities.


let her/him talk. ask about past experience, ask what problems did [s]he encountered and how ware they handled. what was the motivation to choose this or that to solve common problems [ backup? monitoring? scaling out, scaling up, security ].

i think you can tell a lot about the person by just listening.

surly then if you are looking for specific expertise in given area ask detailed questions - suggestion from Stefan Thyberg is very good.

Not the answer you're looking for? Browse other questions tagged or ask your own question.