How to Interview for a DBA Position and how to find a job as a SQL Server DBA have been hot topics in the community in the past year. I've seen a lot of good information given out in blog posts and online editorials about how to make oneself more attractive as a job candidate, what information you should know for the interview, as well as questions that a candidate should consider asking during the interview process. I think that it is great that people in the community like Brent Ozar, Thomas LaRock, and others take the time to cover these kinds of topics as a part of their blogs. However, what I in today's fast paced, quick results culture and environment, I see people taking this kind of information and using to oversell their abilities.
First off let me say that a competent interviewer should be able to spot when this is happening, but in my own experience, I have found that most small to medium sized companies don't have a SQL Server DBA available to perform the interview, so someone can easily BS their way into a position. I have conducted a few interviews in the past, and I have my required essentials (you'd better know about backups and recovery, end to end or the interview becomes a formality really fast), I have my general knowledge about SQL Server the different editions and changes from version to version, and I have my lets see if you will admit you don't know questions (very obscure almost impossible to answer questions that you probably won't know even if you are a senior DBA). The last set of questions are there because no one person can know it all. I don't expect someone to answer them, and they include topics that I have no idea about myself, just enough to know if you are trying to BS me on the answer.
For me one of the most important things for a DBA to be able to do, right after backups and recovery, is admit when something is beyond their level of knowledge. It might mean that I don't hire you for the position, or it might mean that you get hired, but at a lower income level until you improve your skills, but if you sell me that you know clustering, and you can't initiate a failover from the active node to the passive node without asking how to do it online in the forums or comments on someone's blog post, then we are going to have a real problem. If I hired you to manage a cluster, I expect you to know how to do so. If I hired you to solve a problem with performance and deadlocking and you don't know the first thing about creating an index, or performance tuning code, again there is a problem. Now there are always going to be problems that go above the basics, and in those cases if you can save me or my company some money by using online resources to find the answer, more power to you.
So what do you do if you are a hiring manager and you don't know what to ask or how to interview a potential DBA candidate? Well to start with, there are recruiting firms that are out there that do the basic technical review for you and prescreen potential candidates. The problem with this is that these firms get paid by placing applicants into positions, and in my own experience they do very little beyond read what is on the candidates resume and have a quick phone call to discuss the position. A step above this, and one that I really like is to hire a consultant, either privately or through a firm, to handle the technical aspects of the interview process. I've been hired to do this type of interviewing before, and in both cases, the company that was hiring ended up with a good DBA, but it can be a risky process depending on the consultants level of knowledge.
If you are the candidate and you are thinking about overselling yourself, you'd better know your actual limits. From time to time someone who has oversold their abilities as a DBA shows up on the forums, and asks dozens of questions a day frantically until a) they lose their job because they weren't qualified and couldn't produce results fast enough or damaged something, or b) they figure out enough to be able to work their way through the major hurdle and eventually learn the job. More often than not, I'd bet that the first is what happens. I have always tried to sell my abilities, but I am more than happy to tell you, I don't know if you go into something I don't know. My philosophy is simple here, it is better to not get the job, than to get fired from the job and have to start looking all over. My name and reputation means to much to me to have it tarnished. In consulting I have landed work by bidding a lower hourly rate with the understanding that the work wasn't my expertise but I would be willing to learn it to get the contract. Two good things have come of this, I generally get the work because I have underbid it, and I get to learn while being paid (as a note, I only do this for things I am interested in learning anyway, otherwise it can backfire on you).
If you happen to land a job for a lower rate that allows you to learn your way into the position the various online forums are a great place to gain information. Before asking a question take a moment to first do your own search on Google, Bing, Yahoo, whatever search engine you want so that you don't constantly ask 100 based questions that are already answered all over the internet. If you don't find an answer after a few minutes, ask away, but keep in mind that forums and newsgroups are not a guaranteed method of getting help, and if the matter is urgent, saying so in the post doesn't make it any more urgent for people answering the question. If the problem really is urgent in nature, you should be opening a CSS support case which has a better more predictable response time. Take for example the week of PASS Summit in November, the forums crawl to a halt during the day because most of the people who answer threads there are usually attending the conference.
Some posts that you might consider reading if you are interested in the topic:
Brent Ozar
Thomas LaRock
SQL Server Central