How do you interview a Database Programmer/ Admin applicant?

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.