SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Interviews Part 2

By Sean McCown,


I’m going to start this off with an announcement. Since the last article was so well received, I’ve started up a DBA Rant blog. You an access it at http://DBARant.blogspot.com come check it out. I’ll try to write in it once a week or so, and I'll try to be both entertaining and helpful.

Also, my InfoWorld blog is finally back online as well. It's been offline for a few months due to a switch in software that took a lot longer than expected. Anyway, it's back online now, and in that blog I usually try to keep you up to date on which software is worth your time, industry news, and even quite often code for performing DBA functions. I basically talk about pretty much anything in my InfoWorld blog. I usually do write in that one at least once a week, so check it out often because it doesn't stay the same for long. It's Database Underground at http://weblog.infoworld.com/dbunderground/

Ok, enough of the shameless plugs, on with the article!

Man, let me just say that I didn't expect that much response from the first part of this article. I'm glad you guys enjoyed it, now I'm hoping to continue the discussion based off of some things I didn't say before, and things that were added by you guys.

Should I Look at this Candidate?

Man, this is such a good question. What is a good resume? What should you look for? How do you screen potential candidates? Etc, etc. etc.

I noticed that was a large part of the discussion after the last article, and I even received a couple emails on the topic. Well, to answer the question honestly, I've pretty much stopped looking at resumes altogether. There is just so much garbage in them anymore, and everyone pretty much looks like an expert on paper. The same goes with having them take exams like ProveIT and Brainbench. I used to require my recruiters to screen all my applicants with one of those tests, and insisted on only seeing the ones who scored over a certain score. As it turned out, those tests only measured their ability to take a test. I got so many applicants who tested very high on those exams, and some even scored higher than I did, but when I got them into an interview they couldn't answer the simplest questions about SQL. So the tests aren't the answer. And while I agree that a DBA's ability to lookup information is just as important as having book knowledge, there's more to it than that. And there's certainly more to the types of questions I ask than that. The questions I listed in the last article were some of the best answers I've gotten, but my test by no means stops there. I've put a lot of thought into the problem of weeding out the guys who have only memorized a few facts or are really good at taking tests, and my interviews have many different levels.

I can often times tell by the way a candidate answers a question whether or not he really knows the topic or he just memorized the answer out of BOL. For example… if I ask someone about the difference between char() and varchar(), and he takes too long to answer, or answers it in a way that says he's trying to remember it, then I can tell right away that he doesn't have much experience with it. Also, if he answers with confidence it may just mean that he's actually memorized that one, so I'll usually ask a follow-up question. Something like… when would you choose to use one over the other? If he can't answer that one at all, or answers very badly, then that's a good indication that he's really just done a good amount of reading, and doesn't really know what he's doing.

Along with specific questions, and by the way, I don't believe in syntax questions… that's too easy to lookup, and to forget, so I just don't believe in putting someone in a room without BOL and asking them specifics on something I have to lookup myself. So anyway… along with specific questions, I also spend a lot of time just asking them about things they've done at other jobs. I'll ask them about specific projects and as they talk it's pretty easy to tell if they really did the work and understand it or not. That's one reason why I don't put much stock in resumes. It's a standard rule that if you've touched it at all, it goes on your resume… hell I even play that game myself. But if I ask them about a project they were on, and they talk about it with a fair amount of confidence and can answer specific questions about how and why they did certain things, then chances are they actually did it. However, if they talk about a replication project they worked on and they can't even answer the simplest questions about it, then it's pretty safe to say that they're trying to pull a fast one.

Are you Nervous at Interviews… Well, who Cares?!?

You know, I've thought about this one a lot too, and a lot of you talked about people not doing well in interviews because they're nervous. Truthfully, it's a factor in how well people recall information, but quite honestly I really don't care. IT is a very stressful field, and DBs even more so. And if you can't answer a few simple questions without falling apart then you really don't deserve to be a DBA. I've been in jobs where we've had massive failures that took over a day to recover from (once we were at work for 4 days solid without leaving) and there have been a few occasions that I've been awake for 2 days straight looking at the computer screen. At times like these you get so tired you can barely remember your name, but you know what… I could still remember the difference between char() and varchar(). I just don't accept being nervous as an excuse for not knowing the basics. Let us all remember that interviewing isn't a new thing. We've all interviewed for every job we've ever gotten. I've been asked plenty of questions I couldn't answer, and it wasn't because I was too nervous, I simply didn't know the answer. Put simply, I'm never so nervous that I forget the basics.

A New Dawn of DBA Testing

One thing I do sometimes is separate my testing process into 2 different sections… the oral and the practical. What I do is setup a laptop with SQL and after they complete the oral exam, I'll put them in a room with the laptop and a list of 10 tasks to complete. These tasks range from the pathetically simple like creating a user account and giving it certain permissions to a database – to resolving blocking conflicts when I generate a small user load against that box. Needless to say I was quite disheartened the first few times I give this portion of the test. The first was a miserable failure. The guy spent 30mins on google looking up how to create a user account, and then just left without saying anything. He just disappeared and never completed even one objective. This guy actually scored in the mid-90s on Brainbench… whatever dude.

Without Fail the Absolute most Pathetic Candidate EVER!!!... OK, the 2nd Most Pathetic.

I have a very fond memory of this one guy. He wrote me an email afterwards that I'll post in its entirety for your enjoyment. Let me give you a little background before we get into his interview. First of all, his personal skills assessment given to him by the recruiter asked him to rate himself from 1-10 in the different areas of SQL. So DTS was a 9, Scripting was a 9, Administration-9, etc. Everything was a 9, and he had almost 15yrs of solid DB experience on his resume, and was a senior DBA at his current position.

OK, that's the background.

When I got him in the interview I asked him point blank what level of DBA he considered himself, and he said he was a senior by several years. I said, ok, let's get started. So I started asking him my usual easy questions like the ones listed in the first part of this series. He got so many of the easy ones wrong I didn't really want to go on, but I was morbidly curious at that point and decided to see what he actually did know. We got to the section about query tuning, and I prefaced it by asking him how much query tuning he had done. He stated with a very large amount of confidence that he was an expert query tuner and had never found anyone to match his skills. I said then told him that I felt sorry for having to ask him the easy basic questions, but we would just hit a couple of them and then get right down to the meat of it. He motioned me to continue and I began. This is how the conversation went:

Q: What's the difference between an index scan and an index seek?

A: I know there is a difference, I just can't think of it right now.

Q: Ok, what's a bookmark lookup?

A: I don't know. I don't really use those.

Q: You don't use bookmark lookups?

A: No, I don't need them. They serve no purpose.

Q: They serve no purpose? What does that mean? You said you don't even know what a bookmark lookup is, how do you know they don't serve any purpose?

A: Because I don't use them to tune queries.

Q: A bookmark lookup is a standard operator in execution plans, and you mean to tell me that you've never seen one?

A: Oh yeah, I've seen them. I just didn't use them.

Q: Ok, so do you want to keep bookmark lookups in your execution plans, or get rid of them?

A: Oh you definitely want to keep them. That's why I don't even bother because most plans have them already and if they don't it's almost impossible to get them in.

Q: So let me get this straight… you've been a DBA for over 10yrs. You're an expert in query tuning with nobody in sight to match your skills, and you can't even answer the most basic questions about execution plans. What's worse than not knowing what a bookmark lookup is, is that you have been looking at execution plans for over 10yrs and it's never even crossed your mind to find out what a bookmark lookup is. Not only that, but you don't even know the difference between a scan and a seek. What are you basing your expert knowledge on? You don't even know the basics of execution plan operators.

A: There's more than one way to work with indexes. I've always done quite well and my company is very pleased with the improvements I've made.

OK, so that's the important part of the interview. It actually ended pretty quickly after that, and needless to say we ended our mutual love for each other then and there… or so I thought. Before he left he asked me how he did, and I told him politely that I would have to go through my notes and that I would let him know.

The email chain that follows below is honestly unedited. This is the actual correspondence we exchanged. The names have been taken out to protect the not-so-innocent.

Before I get to that though, seriously… people have such an over-inflated opinion of their skills it's not even funny. Someone in the previous discussion most astutely said that it's a product of SQL being so easy to get going and administer. Not only was he dead on, but I've been saying this for years. The sad part is that this is something SQL DBAs have had to put up with since SQL 7.0, but Oracle is going to start having these growing pains with the advent of 10g. Oracle, who has prided itself on keeping idiots out of the database by insisting on a certain level of difficulty, is now going to suffer from the growing pains associated with making a wizard-driven DB.

When I started in SQL, you had to know the commands for everything, and we still had query-based optimizers instead of the much smarter cost-based optimizers we have today. Anyway, the guy that wrote that was right on, and I honestly think this is a product of the extremely fast evolution databases have enjoyed. There have been far too many advances far too fast, and most DBAs can't keep up with them. He was also right in that you had to really learn what you were doing or you simply couldn't do it. It wasn't like today where you have a wizard to help you be as stupid as you want.

I actually have more to say, but this is getting quite long, so here are the emails…

This first one is a follow-up email I sent to him. The names have been changed to protect the stupid.

John Doe,


We compared our notes, and though it's true we had to rush and didn't get to do a full interview, we feel we have a pretty good idea of your skillset.  One question I have for you though is in your level of actual experience.  You told me flatout that you were an expert in query tuning, and you didn't know the simplest things about execution plans.  To remove a table scan operator is fine, but it goes so much deeper than that.  You've been doing DBs for a long time now, and it never even crossed your mind to ask what a bookmark lookup is, or what the difference between an index scan and an index seek is.  You know what the definition of fill factor is, but you couldn't tell me in the least why you would use it, or how you would check that it's even needed.  You just apply 90% across the board in every company and pray that it's enough I guess.  I have to ask what makes you an expert with query tuning… what criteria are you judging that by? 

There were other things that we felt you should know as well…  things that are fairly basic for DBAs, especially for someone who describes himself as a senior level DBA, and put 9s on his skills assessment for most areas.  You know practically nothing about monitoring NT performance, or SQL performance.  You don't know the simplest concepts of NT like page faults, or the difference between logical and physical disks.  These are very basic NT concepts that a senior level DBA would know without having to blink.  You demonstrated a very poor knowledge of basic backup commands as well as basic principles of standard backup practice.  Your knowledge of basic configuration parameters of SQL is also lacking… you didn't know the simplest of basics like ansi padding, or what SP3 does. 

I don't mean to be so harsh, but I believe in being honest, sometimes brutally so.

So if you honestly consider yourself a senior DBA how do you justify this rank, and since you don't even know the simplest of concepts in DBs what have you been doing all this time?

We may want to meet with you again, but I consider you a junior in most areas, and you may not want to take such a cut in position. 

Signed, blahblahblah

OK, good so far… this was his reply:

Well it is obvious that I am not going to work with you.  Thanks for your time anyway.  Sorry I cannot ramble every little piddling thing about SQL Server off the top of my head.  Someday when you have to manage an large enterprise environment, perhaps at a super-cap company like myself, you will find there are other important qualities than rambling definitions. 


John Doe


This is the problem with DBAs today. Everybody thinks they're Ken Henderson without anything to back it up. So what he's telling me is that he's such an expert in SQL, that he doesn't have to demonstrate the most fundamental knowledge… he's transcended knowledge. Hell, in that case, my mother's Ken Henderson, Kimberly Tripp, and Kalen Delaney combined, because she doesn't know the first thing about SQL, or even computers for that matter. I mean, what a stupid thing to say… I know so much I've forgotten the basics. And yes, if you didn't catch that in my original email, he applies 90% fill factor across the board, and couldn't even begin to tell me how to check for fragmentation. That in itself isn't a crime, but advertising yourself as a super-DBA and not knowing it is.

Anyway, that's all I've got this time.

I'm really thinking about putting together a series on interviewing… how to prepare, what to know, what not to know, etc. It seems kinda like a no-brainer, but the more I interview people, the more I see more people need this than I thought. Anybody interested?

Total article views: 12108 | Views in the last 30 days: 6
Related Articles

70-445 Questions and answers

70-445 Questions and answers


Basic SQL Interview Questions

We decided to add blog post that covers only basic SQL Interview questions and answers. The blog cur...


SQL Server Interview Questions And Answers

This Topic I want to initiate for SQL Server Interview Questions and Answers which people faces in t...


Series of basic index and performance questions

looking for brief answers to a series of different questions


Azure DWH part 1:Common questions about Azure SQL Data Warehouse

This article compiles some common questions and answers about Azure SQL Data Warehouse.