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
- (SQL Server) Size Matters – how to determine if a DBA’s experience is right for your company.
- Testing DBA Decisionmaking – DBAs need more than just technical skills: they make business decisions all day long.
- Tips for Hiring a DBA – my thoughts after going through the interview process at a few companies.
- Show Candidates Their Work Areas – and watch their reactions. It’ll help you gauge if they’re a good fit for you, plus give you insight about your environment.