How to Hire a Really Good Oracle DBA

Many of our customers have internal database administrators.  FACT:  Any remote DBA organization, and I mean ANY one of them, should be excited to work with a talented on-site person; in fact, part of good remote DBA support should be to help clients hire good DBAs when appropriate.  Without fail, a collaboration between solid, focused technical people makes better use of existing talent and finds better solutions faster.  Every time.

That being said, how do you find a good DBA?  For that matter, how do we at Blue Gecko find good DBAs?  It’s not easy, but here are a few tips for anyone hiring an Oracle DBA.  Follow these guidelines and your chances of finding a solid resource will improve:

1.  Have a DBA ask the questions.

I subscribe to the philosophy that the only way to hire a good technical resource is to have an experienced technical person talk to them.  Resumes anymore are geared more towards keyword matching and uploading to corporate and job-posting web sites; references are fine, but is the person providing the reference really in a position to evaluate the specific technical skills of their buddy/relative/ex-colleague?

The problem lies in the questions asked – if the person asking the questions has limited fundamental Oracle understanding, it’s easy for a mediocre candidate to BS their way into a job.

If you’re serious about hiring a great DBA, then make sure you have the right talent evaluator.  HR won’t cut it.  Neither will a manager unless they are technical and understand Oracle.  Want to find a good Oracle resource to give a technical interview?  Call us.  Call another DBA firm.  Google Oracle DBAs online and find someone providing great solutions on their blog.  It’s not perfect (although we are happy to screen any candidate and provide detailed feedback) but if you have no idea what to ask a DBA, it will be better than nothing at all.

2.  Don’t rely on certification.

I don’t mean to offend, but I’m sure I will on this one.  Many great DBAs are certified.  It takes time and discipline (not to mention some cash) to pass the exams.  If you are a certified DBA, congratulations, you should absolutely take pride in your achievement; however, certification alone is not a substitute for real-world experience.  If a candidate is placing all their eggs in the certification basket, be extra skeptical.  There are many fantastically talented and experienced DBAs who are not and have no intention of becoming certified.  That doesn’t mean you don’t want to hire them.

3.  Don’t ask syntax questions.

Oracle syntax is easy to look up and many commands have hundreds of permutations.  I really don’t care if someone can remember the exact command for something – I care that they know what they’re looking for.

4.  Anything on the resume is fair game.

We see resumes all the time that list general skills like “performance tuning” and “backup and recovery.”  If we see it, we’ll ask about it.  For example, if someone lists performance tuning, they should not only know what a wait event is, but should be able to rattle off the most common wait events and know what they mean and give some examples as to what causes them.  We’ll ask about specific tuning experiences and how they got their information, what their troubleshooting process was, and what tools or queries they used.  We’ll ask “what if” questions and expect to see the tuning thought-process at work.  We’ll ask, “Why did you do that?” a lot.

5.  Ask them to describe a project.

If a resume says they implemented enterprise monitoring, ask them about the implementation.  What was the goal?  What were the challenges?  What tools did you use?  They should speak fluidly and be able to answer any question at all.  If they can’t?  They might not have played as great a role as they’re letting on, which is a big red flag.

6.  Don’t ask about a specific add-on features unless it’s part of the job.

If you use Streams and need someone who understands Streams, by all means, grill them on the technical details of Streams.  If you don’t use Streams, does it matter of they know it well?  No DBA is going to know everything, but if you hire a good one, they will learn quickly by leveraging their overall Oracle knowledge.  There’s no need to unnecessarily make them uncomfortable in an interview; you may accidentally chase away a great candidate.

7.  Ask them how to do it in your environment.

Red flag:  “I did that with Grid Control.”

Red flag:  “I use a script for that.”

Really?  Who wrote the script?  Can it be used anywhere?  What are its shortcomings and limitations?  Is Grid Control used here?  What if Grid Control was down?

A good DBA knows how Oracle works and doesn’t need a tool to do their job.  They may choose to use a tool because it saves time, but they always know what the tool does and where they need to use something else.

8.  Ask technical questions that require fundamental Oracle knowledge.

I saved the best for last.  Asking technical questions is a bit of an art.  I believe you can reliably identify a great DBA with 10 technical questions or less.  Requesting clarification on any question is fair and so are a couple of followups.  A good DBA will be able to design a short series of questions that will test the candidate’s fundamental knowledge of Oracle.  Here are some examples:

1.  What does the error “snapshot too old” mean?

This is one of my favorites and I always ask it near the top.  If the candidate says it means you need more undo or bigger rollback segments, you can stop the interview right there.  I may provide a few hints to get them to describe read-consistency, but if we don’t get there, that’s all.

2.  Pick a wait event and tell me what it means.

Every Oracle DBA should know what wait events are and how to find out what a session is waiting on.  At a minimum.  If the candidate insists they are a performance tuning guru, they should be able to describe many wait events, what they mean, how they are calculated, what the parameters mean, and regale you with detailed tales of tuning conquests.

3.  How do you associate a server process/thread at the OS level with a session/user in the database?

You should be able to feed any DBA candidate 3 helpings of Thanksgiving dinner, place them on a comfy couch in a warm, dimly lit room, and wait until they’ve just about nodded into tryptophan hibernation, then gently whisper this question into their ear.  As their eyelids and body sag deeper and deeper, they should automatically regurgitate the answer to this question in SQL.

4.  What does a checkpoint do?

It’s OK if they can’t tell you everything.  But you should look it up in advance and see that they don’t make stuff up.  “I don’t remember” might be OK depending on how they did on the rest of the questions.

5.  What is the difference between dynamic performance views that begin with v$ and those that begin with gv$?

If they claim to know RAC, this answer should be short and sweet.

6.  Name a new feature of Oracle 11g that interests you.

I like to add one question like this at the end of every technical interview.  I like people who are curious and have an enthusiasm for technology.  If the candidate hasn’t worked on 11g yet, that’s OK, but have they read about it?  If they can’t tell you anything about 11g on January 7, 2010 (even if they haven’t worked on it because their last employer just refused to upgrade) no knowledge at all suggests a bit of apathy – shouldn’t a good DBA at least be familiar with the new features so to suggest improvements?

If the candidate answered all of these questions fluidly and completely, including any followups or clarifications, they probably have an excellent fundamental understanding of Oracle databases.  Obviously you should ask questions that make the most sense for your systems, but the general idea is to ask questions that test fundamental knowledge, not memorized details.

I hope this has been of some value.  If you have a minute, please post some of the best technical interview questions you have asked or been asked!