THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

The Rambling DBA: Jonathan Kehayias

The random ramblings and rantings of frazzled SQL Server DBA

Rant: Overselling your ability on a Job Interview

How to Interview for a DBA Position and how to find a job as a SQL Server DBA have been hot topics in the community in the past year.  I've seen a lot of good information given out in blog posts and online editorials about how to make oneself more attractive as a job candidate, what information you should know for the interview, as well as questions that a candidate should consider asking during the interview process.  I think that it is great that people in the community like Brent Ozar, Thomas LaRock, and others take the time to cover these kinds of topics as a part of their blogs.  However, what I in today's fast paced, quick results culture and environment, I see people taking this kind of information and using to oversell their abilities.

First off let me say that a competent interviewer should be able to spot when this is happening, but in my own experience, I have found that most small to medium sized companies don't have a SQL Server DBA available to perform the interview, so someone can easily BS their way into a position.  I have conducted a few interviews in the past, and I have my required essentials (you'd better know about backups and recovery, end to end or the interview becomes a formality really fast), I have my general knowledge about SQL Server the different editions and changes from version to version, and I have my lets see if you will admit you don't know questions (very obscure almost impossible to answer questions that you probably won't know even if you are a senior DBA).  The last set of questions are there because no one person can know it all.  I don't expect someone to answer them, and they include topics that I have no idea about myself, just enough to know if you are trying to BS me on the answer.

For me one of the most important things for a DBA to be able to do, right after backups and recovery, is admit when something is beyond their level of knowledge.  It might mean that I don't hire you for the position, or it might mean that you get hired, but at a lower income level until you improve your skills, but if you sell me that you know clustering, and you can't initiate a failover from the active node to the passive node without asking how to do it online in the forums or comments on someone's blog post, then we are going to have a real problem.  If I hired you to manage a cluster, I expect you to know how to do so.  If I hired you to solve a problem with performance and deadlocking and you don't know the first thing about creating an index, or performance tuning code, again there is a problem.  Now there are always going to be problems that go above the basics, and in those cases if you can save me or my company some money by using online resources to find the answer, more power to you.

So what do you do if you are a hiring manager and you don't know what to ask or how to interview a potential DBA candidate?  Well to start with, there are recruiting firms that are out there that do the basic technical review for you and prescreen potential candidates.  The problem with this is that these firms get paid by placing applicants into positions, and in my own experience they do very little beyond read what is on the candidates resume and have a quick phone call to discuss the position.  A step above this, and one that I really like is to hire a consultant, either privately or through a firm, to handle the technical aspects of the interview process.  I've been hired to do this type of interviewing before, and in both cases, the company that was hiring ended up with a good DBA, but it can be a risky process depending on the consultants level of knowledge. 

If you are the candidate and you are thinking about overselling yourself, you'd better know your actual limits.  From time to time someone who has oversold their abilities as a DBA shows up on the forums, and asks dozens of questions a day frantically until a) they lose their job because they weren't qualified and couldn't produce results fast enough or damaged something, or b) they figure out enough to be able to work their way through the major hurdle and eventually learn the job.  More often than not, I'd bet that the first is what happens.  I have always tried to sell my abilities, but I am more than happy to tell you, I don't know if you go into something I don't know.  My philosophy is simple here, it is better to not get the job, than to get fired from the job and have to start looking all over.  My name and reputation means to much to me to have it tarnished.  In consulting I have landed work by bidding a lower hourly rate with the understanding that the work wasn't my expertise but I would be willing to learn it to get the contract.  Two good things have come of this, I generally get the work because I have underbid it, and I get to learn while being paid (as a note, I only do this for things I am interested in learning anyway, otherwise it can backfire on you). 

If you happen to land a job for a lower rate that allows you to learn your way into the position the various online forums are a great place to gain information.  Before asking a question take a moment to first do your own search on Google, Bing, Yahoo, whatever search engine you want so that you don't constantly ask 100 based questions that are already answered all over the internet.  If you don't find an answer after a few minutes, ask away, but keep in mind that forums and newsgroups are not a guaranteed method of getting help, and if the matter is urgent, saying so in the post doesn't make it any more urgent for people answering the question.  If the problem really is urgent in nature, you should be opening a CSS support case which has a better more predictable response time.  Take for example the week of PASS Summit in November, the forums crawl to a halt during the day because most of the people who answer threads there are usually attending the conference.

Some posts that you might consider reading if you are interested in the topic:

Brent Ozar

Thomas LaRock

SQL Server Central

Published Wednesday, July 22, 2009 3:27 PM by Jonathan Kehayias



Kyle Flowers said:

> I have my lets see if you will admit you don't know questions (very obscure almost impossible to answer questions that you probably won't know even if you are a senior DBA).  The last set of questions are there because no one person can know it all.  I don't expect someone to answer them, and they include topics that I have no idea about myself, just enough to know if you are trying to BS me on the answer.

Can you post an example or two of this?

July 22, 2009 2:47 PM

Joe said:

since most small and medium size companies, ie, with 1 dba position out of several IT positions, cannot do a proper dba interview, perhaps some should offer this service

July 22, 2009 3:42 PM

Jonathan Kehayias said:


That would completely defeat the purpose of having that kind of question in my pocket.  However, an example would be something like:

How does the maximum number of workers affect memory sizing and configuration for a 32 bit server? 64 bit? Should you increase the amount of RAM the server has if it has more logical CPU's?

July 22, 2009 4:12 PM

Adam Machanic said:

I do tech screens for my clients when they're hiring DBAs/DB devs. If anyone reading is interested in some help in this area, let me know :-)

July 22, 2009 4:13 PM

Jonathan Kehayias said:


I know quite a few consultants that provide that kind of service.  Shoot me a contact if you'd like me to pass your information along to one of them.

July 22, 2009 4:13 PM

Armando Prato said:

I think you have to strike a delicate balance between what the needs of the company are and the questions asked.  Currently, I'm hiring for a senior level DBA to help me at my company.  The position is heavy on modeling, stored proc development, and query tuning.  As a result, I ask questions of varying degrees of difficulty revolving around these areas.  It helps me gauge what level the candidate is at.  

Not being able to answer a question does not necessarily penalize a candidate.  I don't know everything and I'm admittedly weak myself in some areas (such as storage and clustering which are not my day to day focus) and I don't expect someone coming through the door to either.

July 22, 2009 8:11 PM

Mike C said:

I always start with a very basic skills test for developers - 10 basic questions that every SQL developer with 6 months experience should be able to answer (2-table join, NULLs, basic performance tuning, etc.)  No trick questions at all - I figure we can get to that later if they know the basics.  I'm always surprised by how many candidates don't seem to even know the basics.

July 22, 2009 11:38 PM

AaronBertrand said:

Yes I have some horror stories.  One guy claimed to have 8 years of RDBMS experience, mostly in design and performance tuning.  When asked to design a mock-up of the schema for a book store, they had some crazy ideas about the design process : OrderDate in the Books table, PubishedDate in the Customers table, clustered index on Customers.LastName, etc.  That was a fun interview but unfortunately it did not last long.

July 23, 2009 10:35 AM

AaronBertrand said:

(This guy would have been overselling if he merely stated, "I can *spell* SQL.")

July 23, 2009 10:36 AM

Adam Machanic said:

Perhaps he was thinking of one of those exclusive, membership-only rare books stores, where only one copy of each book is ever acquired or sold, and in order to join you must also be an author? In that case the design is perfect... Other than the fact that those stores don't exist. But practicality is nothing more than an implementation detail, right?

July 23, 2009 1:12 PM

Jason said:

I had guy tell me that you put a clustered index on a table so it can fail over. The interview got brutal at that point.

July 23, 2009 1:27 PM

Alexander Kuznetsov said:


I think it is possible to come up with such a workload that "clustered index on Customers.LastName" is the best choice.

July 23, 2009 2:16 PM

K. Brian Kelley said:

On the horror story front, we were interviewing for a senior system administrator position which required a strong working set with Active Directory. One of the smart-alek Citrix administrators came up with a surprisingly successful weedout question: "Can you tell me the different between a forest, a domain, and a tributary?"

Only one candidate realized that a tributary has nothing to do with Active Directory. However, all the others tried to answer it and one even said, "Oh, man, I just read this on MSDN! I know this one!"

The one candidate who got it right was the one he hired. He basically said, "I don't know what a tributary has to do with anything AD or Windows related. A tributary has to do with rivers." BTW, he was also the only one that understood RAID 5.

July 23, 2009 2:36 PM

AaronBertrand said:

Alex, maybe, but it was the only index he mentioned in the entire design.  And did I forget to mention he also put a little key icon beside it?  :-)

July 23, 2009 3:23 PM

Brent Ozar said:

Great post.  When I'm writing about interview questions, I try to avoid giving the answers.  I've found that DBAs (and development managers) don't need to read the answers, because they usually know the answers already.  They're just not sure about what questions to ask.  That's why I don't post technical questions - anybody can come up with a list of technical questions, but the tougher ones show that the candidate can think fast on their feet and handle the political problems of database administration.

July 23, 2009 10:39 PM
Anonymous comments are disabled

This Blog


Privacy Statement