When hiring a DBA, test their skills

During my recent job search, I noted a few things about the hiring process for DBA’s, and I figured I’d make a few blog entries out of them. This first one covers technical skill testing – finding out whether a candidate has the experience they claim.

DBAs can be tough people to screen because the skill set is so narrow, because your current in-house programmers don’t have the skills to test a DBA’s technical knowledge, and because with just a little studying, a lot of people can wing it through an interview. If you don’t have a DBA (due to the current one leaving or due to this being your first DBA) you will find it really hard to know for sure that a prospective DBA actually knows their stuff, or if they’re just bluffing.

I’ve interviewed with managers who came to the interview armed with a few generic SQL interview questions they found on Google. These managers need to realize that if they found these questions in ten minutes, the candidates have probably found them as well, and the candidates can parrot out the exact answers.

On the opposite side of the difficulty spectrum, I also interviewed with managers who brought out the toughest technical SQL challenges they’d encountered in the past year. One of the questions involved linked queries against a Sybase server – minutes after I’d specifically said I had zero experience with Sybase. Another question involved heavy, heavy, heavy use of temporary tables by way of select-into, and the developer asked me whether I’d implement multiple TempDB files. TempDB was the heaviest used database in the entire server, to the point where the company implemented clustered database servers thinking they’d get faster TempDB’s. The developer asked how I’d solve it, and I tried to delicately say that I’ve never encountered queries written quite that poorly, and that I’d need to research solutions, but that the real solution is to stop doing select-into with temp tables. She was stunned that I didn’t have an answer off the top of my head, and started asking me about Microsoft’s best practices when implementing multiple TempDB files spread across a cluster. I was just as stunned that she expected me to memorize that scenario, something no DBA should ever have to encounter.

Only one of the companies (out of about half a dozen that I actually interviewed with) gave me a technical test in the form of a Brainbench. As a candidate, I abhor Brainbench tests because they’re so abstract. However, I haven’t seen anything better to test SQL aptitude, it’s better than nothing, and it’s way better than asking ridiculously hard or ridiculously easy SQL questions.

It’s still important to interview a DBA to make sure they get along with the managers and developers, but don’t expect these people to judge a DBA’s technical skills. After all, if they had the technical skills, they’d probably be a DBA – not a manager or a programmer. DBA life is pretty darned good.

More Articles on How To Hire and Interview DBAs

Previous Post
It’s official: Apples run Windows
Next Post
Show candidates their work areas, and get their reactions

8 Comments. Leave new

  • Hey Brent, great article!! I found it actually quite informative seeing as though the company I work for is about to hire a DBA and we were looking at different ways of testing a DBA’s skills.
    I’d like to thank you for posting a link to the Brainbench technical test for DBAs as I’m a programmer and was given just that task of setting up a test for 2 prospective DBAs.

  • I am with you, but would like to clarify something… the job title DBA is almost totally meaningless. Most people with that title are NOT administering the database. They are writing SQL code. This may include writing the odd database or five and suggesting optimizations to existing databases, but there is often little or no involvement in ‘pure’ administration.

    Things like replication, backup strategies and building database servers from scratch should be handled by an expert, hired as a consultant if needed. They are not the day-to-day business of most DBAs.

    The reason this annoys me is that many interviews I have had involve questions about the low-level administration that require specific knowledge of the system concerned and often of parameter settings. Frankly, I don’t know the answers and would never need to. I’d look them up in the installation notes on those few occasions that they were needed. Heck, it’s such a rarity that the best DBAs would do that even if they thought they knew the answer because that’s the sort of stuff that changes from one release to the next.

    I do have one question for you. I have a team member that I think would be suitable for teaching SQL to. She has little or no programming knowledge so testing her actual skills is pointless. Instead, she seems to think the right way and so I am looking for a test of how her mind works.

    In my experience, SQL requires a brain that can cope with the idea of doing parallel queries. Most programmers think in steps… do this, then that and then the other. When these people learn SQL, they tend to use Stored Procedures as much as possible because that allows them to retain the same structure. However, someone who is really good at SQL can usually write the same functionality in a single SQL statement which runs faster and more efficiently.

    Any ideas on where I could find some sort of test to look for this capability ?

    Thanks.

    • While you are correct that most DBAs will spend a large majority of their time optimize existing queries, fixing existing databases, and just overall improvement of existing setups. This is the norm of a DBA, if you find a job where all you do is basid admin of the server, then you're a server admin, not a DBA, and I wouldn't consider you worthy of a DBA job role.

      This is like a programmer walking into a job and complaining when he has to rewrite/improve/expand existing code. Writing stuff 100% from scratch is not the norm, having to work in or with other people's code is.

  • Hi, Siggy. Your comment about the job title of DBA is something I’ve even written about. There’s a difference between a development DBA and a production DBA. You’re talking about development DBAs, which do indeed spend most of their time writing code.

    Production DBAs (like I’ve been for the last couple of years) only write code once in a while, and it’s usually for maintenance jobs or performance checks. Production DBAs do actually handle replication, backup strategies and building servers from scratch on a daily basis. I just got off two phone calls about building new clusters in the next week, for example.

    About the test – that’s an interesting question. I’ve found the best tests were the ones written by very high-end consulting firms using knowledge from previous projects. They describe a business challenge, and then ask the DBA for as many solution ideas as possible, and to choose the best one. That way, they can see the DBA’s thought process and see if the DBA would pick the same kind of solution that the consulting company ended up picking.

    That kind of test doesn’t evaluate the ability to write a query in the way you’ve described, but frankly, I’d rather have good decisionmaking skills. That way, you know the programmer will come up with the right ideas once she’s had enough training.

    Hope that helps!

  • Hey Brent I would like to your advice on how to go from helpdesk support-to-dba. I have programming background in Pascal,Cobol(very ole school)I need a chage of pace, I’m not happy with helpdesk.

  • Hi, Ron. Thanks for your question. What I’m going to do is publish a new blog post about it instead of adding the whole thing in a comment here, because I bet you’re not the only person who wants to do that. I’ll post it shortly. Talk to you later, and good luck!

  • Megan Von Wald
    October 1, 2008 11:08 am

    Brent,

    You mentioned in your 5/14/2008 response that the best tests are those written by very high-end consulting firms. Any suggestions on which firms to use or anyway I can locate one in Denver?

    Thank you,

    Megan

  • I’m hesitant to name company names in my blog, since I don’t want to be seen as endorsing one consulting company over the other. I may not have been phrasing that answer right, though: what I meant to say is that these high-end consulting companies use really tough interview questions in order to filter out their own applicant pools. They don’t sell the questions to outside companies, but rather just use them on their own prospective hires. Hope that makes more sense!

Menu
{"cart_token":"","hash":"","cart_data":""}