Interviews Part 2
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sMcCown/interviewspart2.asp
Watch my free SQL Server Tutorials at:
http://MidnightDBA.com
Blog Author of:
DBA Rant – http://www.MidnightDBA.com/DBARantMinion Maintenance is FREE:
-
It’s all relative.
I have met my fair share of so called DBA’s.
Due to the position I was hiring for, I was looking for someone who knew SQL well.
Not to put a title on it, senior or junior, but they needed to know SQL well as there was no one above them.
One “Expert” with 8 years of experience I interviewed was truly amazed by a LEFT OUTER.
In 8 years he had never seen one. He called himself a senior DBA. The reason being, he was the only DBA at the company. Truthfully, that would make him the most senior DBA, by the same token, a Senior DBA.
As far as the performance tuning questions go, I to have had some interesting ones.
A guy claimed to be brilliant at performance tuning. It became clear that when he inherited the system, there were no indexes. He started adding indexes to tables until things speeded up. When asked what his criteria for an index was he said trail and error. When asked about how it impacted data modifications, the look on his face said “I am confused” but he replied, with confidence, “Why would it affect inserts? Indexes speed things up”
Yes, relative to what he had, he was brilliant at it.
With some, note some these people, there is hope. You can’t crucify someone just because they have been stuck in a small company as the senior DBA. Granted, if you looking for someone who knows, fine, but I am all for seeing potential in people who claim to be senior and are not.
If the arrogance of the perceived position is to great for them to want to learn and correct their ways, they will always remain a large fish in a small bowl.
Cheers,CrispinI can't die, there are too many people who still have to meet me!It's not a bug, SQL just misunderstood me!
-
My boss showed me some questions that they used when they were recruiting for my position.
Aparently they had a lot of candidates that didn't know the difference between a unique key and a primary key.
Off the top of my head I couldn't remember what ACID stook for even though I knew what the acronym meant.
I can remember a previous IT director complaining that 90% of people got where they got by bullshit and therefore assume that everyone else did too!
I can feel a "users from hell part 3" coming on
-
Ya, it's true and unfortunate but happening in most of interviews.
I think it is better idea to have a series of articles on this, as Mr.McCown mentioned. This is going to help atleast to the people who "really" want to become good DBA.
-
Or atleast give the chancers an idea on how to bullsh1t their way through interviews better...
Cheers,CrispinI can't die, there are too many people who still have to meet me!It's not a bug, SQL just misunderstood me!
-
Wow! Thanks for the article. I think I will have my wife read this one. She's always giving me advice about how to write my resume. I just tell her I'd rather keep a mediocre(read lower-paying) job than lose a great one.
But, seriously, as an actual junior dba, I would love to hear more on this topic. Thanks!
-
To be honest, though you were right to grill this person from a technical standpoint in the interview, I believe you crossed the line in your email back to this person. To be honest, your tone and tactlessness was unprofessional in and of itself.
Simply put, you could have simply said something more hr like. ...
While we reviewed your skills, we have selected a different candidate who was a better fit for the position. Good luck in your job search.
That would have sufficed. . .
-
people have such an over-inflated opinion of their skills it's not even funny.
http://www.phule.net/mirrors/unskilled-and-unaware.html
-- Stephen Cook
-
Any woman in any nightclub could tell you that
-
I've been told I am to modest
Cheers,CrispinI can't die, there are too many people who still have to meet me!It's not a bug, SQL just misunderstood me!
-
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.
-
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.
-
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
-
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!
-
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
Viewing 15 posts - 1 through 15 (of 68 total)
You must be logged in to reply to this topic. Login to reply