Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12345»»»

Interviews Part 2 Expand / Collapse
Author
Message
Posted Monday, September 19, 2005 8:19 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, February 21, 2006 7:47 AM
Points: 35, Visits: 1

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.

Post #221132
Posted Monday, September 19, 2005 8:23 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, November 28, 2011 8:39 AM
Points: 110, Visits: 34

This article was very insightful as I'm fairly new to administering SQL Server.  As such I would think that taking a more humble, yet confident, approach to an interview as a candidate would make that particular candidate somewhat more appealing in that they're not a "know-it-all" and they are willing to learn.  Although I'm not sure that I would have dismissed the senior DBA candidate in the fashion that was taken, I'm sure that most everybody would agree that over-hyped resumes are an unfortuneate reality in today's world ... no matter what technology a particular candidate is interviewing for.

Secondly, I would encourage some of the more experienced DBAs, especially those of you that have hiring responsibilities, to author a few articles on the good-to-knows and the must-knows of SQL administration and what you look for in candidates.  This will help the rookies (myself included) learn the ropes much more quickly and hopefully in a more thorough manner.




Regards,

Steve K

Post #221133
Posted Monday, September 19, 2005 8:29 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, November 7, 2012 1:07 PM
Points: 222, Visits: 22

G'day all,

I would like to offer an observation without claiming it is either good or bad - simply an observation.  The term DBA has came to mean a lot of different things.  As was mentioned above, anyone who touches a database can claim to be a DBA with some level of experience.  What the term "DBA" lacks is a context.

There is a tremendous difference between someone who manages a production environment with a hundred servers, another person who may write and tune SQL procs all day as part of an application or product team, and a third person who operates as an architect primarily modeling at a conceptual and logical level.  However, it is also normal for each of these people to call themselves a "DBA".

I have worked in each of the above positions, and the title always included DBA, perhaps with some sort of modifier (senior, junior, bozo, whatever).  The skills that were freshest in my mind as a production DBA have little or no bearing on my work as a database architect.  A "DBA" supporting product development falls somewhere between these two.

The job description posted for an open position is usually so loosely written that a candidate may not know what the position actually requires.  I have made it a habit that I speak to someone inside a potential client who actually has technical knowledge before I agree to an interview.  Getting past the screeners is often very difficult, as it is a numbers game for them.  The screener plays the odds and figures that if he submits 10 or 100 times the number of required candidates then one of them may actually be a fit.

I implemented a solution at one of my prior employers by compensating the screeners in the HR department based on the ratio of hires to qualified candidates.  The more garbage they sent me, the lower their quarterly bonus.  This eliminated the numbers game completely.  Rightfully so, they required that I write clear job description in order to weed out the "DBA" candidates that would often have been submitted and rejected.

So what is my point?  There is a requirement for everyone in the hiring process to have a focus on the quality of the candidates - not on the quantity of the candidates.  If HR (internal, or the headhunters, or the bodyshops) is not sufficiently trained then we need to set their expectations and get them trained.  Rejecting candidates earlier in the cycle is far more proferable than sittign through the types of intervies described in this series of articles.

Random thoughts from someone who has "been there, done that".

Good day,

Wayne




Post #221136
Posted Monday, September 19, 2005 8:44 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, December 9, 2005 10:22 AM
Points: 102, Visits: 1
I remember when
Gold and Platinum credit cards used to indicate wealth.
The term "Executive" used to be a noteworthy career achievement
When going to University meant that you were bright.

I don't know where the fault lies, whether it is recruitment consultants talking up their clients or clients doing it for themselves. No-one goes into an interview and says "well actually I am just an assistant to an oily rag".

The entire profession has become a haven for would be used car salesmen. BOL has become the equivalent of sawdust and pantihose in the gear box to make it feel less baggy.

There was some hearsay about MS having trouble recruiting the quality of people it needs for development. My friends were attributing this to them being a victim of their own success. They have made tools so easy to use that no-one has the indepth knowledge necessary to write new tools!
Post #221143
Posted Monday, September 19, 2005 8:50 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, October 25, 2005 8:41 AM
Points: 54, Visits: 1

In the article you said that everyone inflates their resume and their assessment of their skills.  I make it a point to try and be very critical and even underplay my abilities some.  I do this because I would feel pretty stupid to get a job where they needed a level 9 DBA and I am only a 4.  I wouldn't be able to do the job and then everyone there would know that I'm not cut out for the job.  However, if I am at least trying to be accurate with my assessment of knowledge, and the HR pre-screening knows that everyone inflates their resume and self-assessment, then aren't they going to believe I'm even worse than I am?  Is there a way to be honest on a resume and have the HR team and hiring manager know to give you a chance?

Kalvin

Post #221145
Posted Monday, September 19, 2005 9:35 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, September 15, 2008 12:02 PM
Points: 1,318, Visits: 57

I agree that your email response to the candidate was unprofessional, and served no useful purpose.

Having been asked some very similar questions in a recent interview, I also did not know all the answers "off the top of my head". Granted your candidate had some very interesting (disturbing?) responses, but it should be clear that there is a distinction between obvious exaggeration or incompetence, and the useless ability to store everything off the top of one's head.

E.g. when a query is not performing well, and I see a Bookmark Lookup, or Index/table scans, I look it up again and resolve the issues. Unless similar issues creep up again elsewhere in a relatively short period, I am likely to forget the definitions, differences, etc.

Thanks for the article.

Terry

 

 




Post #221166
Posted Monday, September 19, 2005 9:37 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, December 9, 2005 10:22 AM
Points: 102, Visits: 1
Just for information purposes are bookmark lookups bad and if so how do you reduce them?
Post #221167
Posted Monday, September 19, 2005 9:44 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, September 15, 2008 12:02 PM
Points: 1,318, Visits: 57

Nice article on Bookmark Lookups. They are not always worth getting rid of.

http://www.sqlservercentral.com/columnists/RDyess/bookmarklookups.asp




Post #221170
Posted Monday, September 19, 2005 9:44 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, February 21, 2006 7:47 AM
Points: 35, Visits: 1
I don't believe everyone inflates their resume.  I don't.
Post #221171
Posted Monday, September 19, 2005 9:57 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 5:20 PM
Points: 1,276, Visits: 1,134

Personally I'd prefer the honest approach taken in this article.  As an applicant I would take the specific reasons why I was not selected and try to build on that.  That way I'd be better prepared for the next interview.  In fact, the applicant might well have used the opportunity to respond to the criticisms about his performance in a professional manner, and who knows?  He might have been able to turn the situation back around in his favor.

Post #221176
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse