I spent almost 2 years interviewing "DBAs" for a senior DBA position.  This was for SQL Server and MSDE 2000, supporting 1,800 servers.  I was appalled by the lack of knowledge of every single candidate presented to us.

We went through 6 DBAs in 2 years.

I am not a DBA; I'm a data modeler and project manager.  I don't claim to be a DBA, let alone an expert DBA.  Every single candidate rated themselves somewhere between an 8 and an 11 on a scale of 1 to 10.  We were specifically looking for DBAs that could help with performance tuning and designing a deployment and data retention strategy for getting these database into 1,800 stores.  During our interviews, we could not get correct answers to the following questions. Even though I am not a DBA, I could answer all of them.

1) What is a clustered index (this was chosen as a question to weed out DBAs who were not familiar to SQL Serer)

Answers: "They are optional indexes", "It's another name for primary key", "I think it has to do with performance". "I've never heard of them".  Not a single interviewee out of more than 60 we interviewed, knew the answer.

2) Here's a simple table structure:  Student ---0< Exam Taken >0----- Exam (we added simple, obvious columns to this).  Write query to pull the *names* of all the students who scored more than 80% on any exam and one for the students who scored more than 80% on all the exams they've taken.  Since it is one a white board, we will not be overly concerned by syntax, just concepts.

Answers: "Uh, I'm not a developer, I'm a DBA", "I'm not a developer", "I don't know SQL, just SQL server".

2a)  Uh...er.. OK.  Write a query that gets all the students who have taken exams.

Answers: "Uh, I'm not a developer, I'm a DBA", "I'm not a developer", "I don't know SQL, just SQL server".

2b) Wow.  Ok, write a query that gets all the information about all the students.

Answers: "Uh, I'm not a developer, I'm a DBA", "I'm not a developer", "I don't know SQL, just SQL server".

Some DBAs attempted to write some SQL, but it was so incorrect that it was clear that they'd never written a single SQL statement in their lives.

3) Tell us about your experience in working with data retention strategies.

Answers: "I recommend you keep all your data".  "I've never done that.  I guess I'd write a script to delete all rows created prior to x date". "I think there's a function for that already in SQL server" (remember, all rated themselves really high on this concept).

4) Have you worked with a data modeling tool before (showing them a sample of one of our models)?

Answers: "Yes.  Have you considered using submodels? (Me: yes, that's what all those words  in a tree are on the left frame of the model)", "Yes, I've used all the modeling tools extensively (Me: Which ones have you used) "Oh, I can't remember their names" (Me: Ok, can you remember who the vendor was?) "No, I can't" (Me: Maybe you could just describe what one of the toolsets looked like) "Oh, no.  It has been too long since I used one" (Me: how long has it been) "At least 10 years" (Me: You've rated yourself an 11 on our tool.  Do you remember which tool you've used so much that you could rate yourself as an 11) "I've never used that tool" (Me: then why rate yourself an 11) "Because my recruiter told me you were looking for an expert in it".

5) Give me a table-only design (don't worry about columns) that would support a parking garage function.

Answers: "Uh, I've never designed a database".  Another candidate jumped up to the whiteboard and started drawing a process model.  Another drew a single table and labelled it PARKING.

Because as the project manager I kept rejecting candidates, my client worried that I was being too strict, that perhaps I was looking for perfect when good enough would do.  So they asked the manager of the Oracle DBAs to sit in on the interviews.  He was astounded that candidates knew so little about databases.  He had come, as I did initially, with a list of advanced questions since we were hiring a Senior DBA.  He (and I) had to dumb down our questions so much it was sad.

I have hundreds of similar stories.  We never did find a good SQL Server DBA, which made me wonder why.  We were interviewing in a region of the US that had one of the highest IT unemployment rates in the nation.  My client was willing to pay six figures for a good DBA, so I don't think it was salary.  It was an exciting industry, not just orders and invoices.  I just don't get it. I'd worked with piles of good DB2, IMS, and Oracle DBAs.  I'd never run into the types of mis-informed DBAs that we'd interviewed. Not in 20 years of working in the data field.  I've come to the conclusion, rightly or wrongly, that this has something to do with the fact that many of these candidates were self-trained DBAs who had never been exposed to a proper enterprise discipline that we old farts had seen with mainframe technologies.  

Almost all of the SQL Server DBAs we talked to were self-trained in all things IT, not just SQL Server.  Many got into the DBA business by buying a book that had a CD and practicing.  They had never heard of any type of separation of authorities, methodologies, advance topics of data design, etc.  Many could not describe the reason why a certain approach would be beneficial.  For instance, one of our real problem DBAs split the tables and indexes onto separate filegroups even though we had only one hard drive on the server (don't ask).  He had just gone online, read that using multiple filegroups was good, and did it.  This was also the same DBA that read that surrogate keys were better, so he deleted all the former key columns and replaced them with surrogate keys.  He didn't make them non-key, he deleted them because "when you use surrogate keys, you don't need business keys".  He didn't realize we still needed the data in those columns.  He deleted the Area Code column for a customer because "you can just look up their phone area code from their ZIPcode".  Even when we pointed out that a ZIPcode can have many Area Codes and an Area Code can exist for many ZIPcodes, his only response was "but the document I downloaded says that this works".  BTW, this guy is still teaching database concepts at a local degree granting institution.

Also, very odd, only one out of the 7 DBAs we hired would actually do work after 4pm.  Even though during inteviews they said they understood that this was also a production support job and that they'd be on call, they didn't not respond to calls. Only one.  I know being on call is a b*tch, but why be a DBA if you don't care if your database is completely down? 

In Canada, and I have no reason to think that this would be different in the US, the average number of years of IT experience for a Data Architect is 14 years.  For a DBA it is 9 years.   That means that most DBAs have had nearly a decade of experience with IT, probably starting as a progarmmer and moving in to data stuff after a few years.  However, most the SQL Server candidates we looked at started in IT as a SQL Server DBA, with no exposure to config control, operations, planning, or design.  We went through a similar thing with PowerBuilder developers in the late nineties.   Self-trained in toolset does not necessarily make for self-trained on the proper application of those tools.

I have to say, though, that I have worked with MANY self-trained IT professionals who are wonderful.  They have managed to train themselves, educate themselves and they know enough that they understand the more they learn, the more they know how much they don't know.   I just don't know why so many of the SQL candidates we interviewed appeared to have absolutely no knowledge of databases.

Some of the tools I work with I've used from more than a decade.  I've written add-ons and extensions for them, I've lived with the work arounds for them, I've trained people on their use, I've worked with their vendors to make them better.  However, even though I am confident that I can use them at the professional level for any client, I'd still only rate my expertise with them at about a 6.

These days, if an interviewee rates himself anyting higher than a 9 on a toolset, I'll start wondering if he's even used it.