Over the last couple of months I have been interviewing candidates for a Sr. SQL Server DBA position we had open on my team. And while we ultimately ended up hiring a great candidate who has all of the skills we were looking for, the process of finding that candidate was…enlightening.
I have to say that I was very surprised at the number of candidates that considered themselves Senior Level Database Administrators, but were nowhere near what I would consider a senior level. Now, that’s not to say that we didn’t actually have some senior level candidates, because we did, and it was a close competition there at the end. But these are some of the questions that I would ask in the initial interview, and some of the not-so-senior answers I would get:
When building a new SQL Server, how would you configure tempdb?
Most common answer: “Don’t put it on the C: drive.”
A few expanded on this and mentioned to put it on fast storage, but that was as far as it went. Only a handful of candidates said anything about multiple data files and how they would go about determining the number of files and sizing them.
When building a new SQL Server, what are some specific configurations you like to set?
Most common answer: “Set Max memory.”
This one really got me. I was very surprised at the number of people who just run the installer and don’t know how to configure SQL Server. Asking about things like parallelism or ah-hoc usage would sometimes lead to an awkward blank stare. Ladies and gentlemen, let me just say that if you do not know what MAXDOP is, you probably should not label yourself as a Sr. DBA.
What are some Trace Flags that you typically use, and why?
Most common answer: “What’s a Trace Flag?”
Very few candidates were familiar with Trace Flags at all.
How would you troubleshoot a slow query on a production server?
Most common answer: “Use Profiler to see what is happening.”
While not necessarily a bad answer, I was surprised at the number of candidates who did not even mention checking an execution plan.
How would you back up a 10+ Terabyte database that has multiple data files?
Most common answer: “On the weekends.”
I wasn’t that surprised by this one, as this isn’t something that all DBAs have had experience with. It wasn’t until recently that I started working with multi-file multi-terabyte databases. Almost none of the candidates knew that you could write backups to multiple files and speed up the backup, but a couple of them got really excited when I mentioned it and wanted to try it.
Then there were the “no-shows”. I had a few candidates that just didn’t answer the phone when we called for the scheduled interview. I had one that after several attempts from both HR and myself, we gave up on.
Looking back, I would estimate only about 1 in 5 candidates that I interviewed knew anything about things like sp_configure or tempdb. Some of the candidates seemed to be developers hoping to gain a pay raise by moving into a DBA role, thinking all they needed to do was run wizards and take backups. I’m not faulting them for that, as it’s exactly what I did a few years ago. However I knew enough to know that I wasn’t a Sr. DBA when I started looking for jobs.
In the end we wound up with 3-4 highly qualified candidates, and out of those came across one who was a perfect match for what we were looking for. It was a good experience for me, as I enjoy talking tech with others and hearing about their setups and situations.
Well written! To whomever gets the opportunity to work with Eric, you need to jump on it. His knowledge and personality make an excellent peer and mentor. Plus, he digs Star Wars and you just can’t say enough about that.
Thanks Bart!