Database Administrators – especially competent ones – can be difficult to find, validate technically, and hire, as they are rare and in high demand.
This article discusses finding, scoping, and acquiring your new DBA
Finding a DBA
Where do DBAs hang out?
Larger companies may hire a staffing firm. This may be expensive (staffing firms will charge a significant percentage of the DBA’s income), but you’ll likely get a warranty of a sort (let the new hire go within 3 months and we’ll find you another for free, for example). The staffing firm may or may to be able to perform a technical interview, you’ll want to double check this yourself. Generally, this is just a good way to get overloaded with resumes.
Here are a few other ways to look for DBAs…
Put a note in one of the forums.
The DBAs you are looking for likely participate in many online forums, and will notice a “for hire” note if one is posted. Make sure that you have specific requirements in your ad; for example, “Need expert-level SQL Server DBA, must have Always-on experience, prefer local, will relocate the right candidate; H1s OK. Team player essential; no cowboys (or cowgirls) for this one.” This makes it easy to simply ignore any resume that doesn’t have your requirements.
Put a note up on linked in.
This site has a very high number of IT professionals of all sorts, and many of them are cruising here for a job. You can also post a formal job requirement here for a fee, but I’ve never needed to.
Go to a local event (SQL Saturdays work for SQL Server, for example).
This is a great place to network with DBAs, and ask around… “Are you available? Know anybody who is good & looking?”
Interviewing your Candidate
On the technical side, we do NOT put a lot of faith in exams or certifications. Many people take a class (which is geared towards certification), get the certificate, and have no practical experience or any idea what to do with the technology once things hit.
Also, do not put a lot of store in a specific minimum number of years of experience.
We start with two interview questions, almost regardless of technology:
- Given a new storage device, how do I associate that storage device with a specific database object I’d like to put on it?
- This question requires a bit of thought, a need to follow a process to logical steps, and an ability to answer a complete question (some folks forget the final step, which is placing an object on a specific device after it’s been associated to a database)
- Tell me about a recent performance issue you’ve had to solve
- Here, I’m looking to see how the problem was identified; how root cause analysis was done, how it was tested, and how it was rolled into production, as well as the final results. Again, we’re looking for a process more than a specific win.
We can generally learn a lot about the person by the way those questions are answered. Of course, if you have specific requirements, ask about those as well.
There are a couple of non-technical questions we ask our applicants as well. These may seem obvious, but the answers we’ve received have been occasionally startling and interview-ending.
“Tell us about a mistake you made and how you handled it.”
The worst answer we ever got was, “I HAVE NEVER MADE A MISTAKE.” That candidate was dropped from our list as soon as we ended the interview. No, we don’t hire people who are used to making a lot of mistakes but this is the answer we got from one of our best hires: “I try hard to prevent mistakes by creating safe gaps and quality controls as best as I can along the way, but one time I made a mistake and the first thing I did was to report to my manager, the users and anyone affected. While communicating I was already reviewing the mistake, fixed it and then prepared solutions to prevent the mistake from happening again, and lastly shared how the issue was resolved and the prevention steps newly created.” The reason we ask this question is to verify the person’s integrity. Your DBA needs to responsibility for his work. Also, it’s important to know if he will they hide the mistake or immediately share the information with their peers and management in order to ensure that everyone effected that (SHOULD KNOW) right away that there is a glitch.
“How important is communication to you?”
Some of this answer is revealed on the answer to the prior question, but we will ask if we don’t get the full answer or to give the person a second chance in the interview. The worst answer we got was, “Communication is important.” A person applying for a 6-figure salary needs better than a pat answer to impress us. The Best answer we ever got from a hire was: “Well without proper communications, specs and cross sharing of ideas, how can I know what I’m supposed to do and also know when I have completed the work properly? I tend to over communicate, share ideas about the work, I share my progress as the work moves along and I ask questions and share concerns if there are problems with the team or the requirements as we all work together.” There is a lot of information here when you get this question answered correctly: Ensuring that he understands the work requirement, working with the team to build relationships and create the best product. This person not only cares about doing the job right but makes sure he is involved with his teammates.
Personality traits of a successful DBA
You’ll also want to determine the following about your DBAs…
Your DBA candidate should be:
- Always learning (not convinced that he/she already knows everything)
- Full of Constructive Paranoia – anticipation of potential issues
- A fan of automation
- Communicative; and understands the reasons why this is important
- Involved online
- Understands continual improvement – “How can I do this better?”
Retaining your DBA
DBAs are like everybody else; they want to be appreciated, and have the opportunity to stretch their capabilities.
There’s a separate article on this site, “How to burn out your DBA” … look at that for a list of things NOT to do. DBAs expect to work long hours, and the occasional weekend; but probably not every night, every weekend, or any desire to get calls while on vacation.
Author: Jeffrey Garbus
© 2017 Soaring Eagle Consulting