Interviews Part 2

,

Announcement:

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. 

Cheers,

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?

Rate

4.5 (2)

Share

Share

Rate

4.5 (2)