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?