A few months ago I was conducting interviews for a Production DBA position that we were creating, and an interesting thing happened...I ran into a candidate who was much like me a few years earlier.  Unfortunately neither of us qualified.  Here are some lessons from that experience...

Perhaps I should provide a little background for new readers.  I have been a database application developer since about 1988 ranging from Info on minicomputers to Advanced Revelation and on to Oracle.  I started using SQL Server in 1999 on version 7.0.  I have a lot of experience in both the UI and database areas of development.  I can hold my own when it comes to the responsibilities of being a Development DBA.  A few years ago when I was doing a lot of contract work, I started looking for jobs with the title DBA in them.  One of my great frustrations was running into interviewers who, I thought at the time, were inflexible and unwilling to give me a chance to prove myself.  At the time, I figured that I was a fast learner and had done a lot of different things with SQL Server, so there shouldn't be much I couldn't handle or figure out (and hey, I always had my friends at SQLTeam to back me up, right?)

So as I was saying, a few months ago while I was conducting interviews, I ran into a guy who was just like I had been.  He had good credentials for database development, was a great guy to talk to, and I had no doubt that he could learn things quickly.  He was looking for someone to give him a chance.  And right then I realized that I was thankful for the past interviewers who would not give me a shot.

Sound crazy?  Well, if you have been reading carefully and you understand the terms, you know the problem.  This guy (as I had been) was a good candidate for a Development DBA position, but I was seeking a candidate for a Production DBA position.  While both are called DBA they have very different responsibilities.  Basically the Development DBA supports the application development lifecycle and is generally focused on things such as normalization, naming conventions, constraints and keys, stored procedures and effectiveness overall.  A Production DBA on the other hand supports the application after it has been deployed into the live (or production) systems.  He or she is often focused on performance, efficiency, and reliability; including backups, replication strategies, serialization, locking and blocking.  A Development DBA deals with the pressures of development deadlines, while a Production DBA deals with the pressures of C-Level executives screaming that every second it takes to fix a problem is costing the company umpteen millions of dollars.

So sometimes when you are out there interviewing, as frustrating as it can be at times, you need remember that the interviewer just might really know what he's looking for and you may not be the right fit.  In our case, we needed an experienced Production DBA and were not willing to let a guy learn how to do his job on our time.  We had an occasionally recurring nightmare that completely locked-up one of our mission critical databases causing about 50% of the company to come to a grinding halt.  We already had two highly skilled, but development-focused SQL guys on the team who could read Books Online.  We needed something different.

The good news for that candidate was that I recognized this while we were conducting the phone interview and I was able to help him see that I wasn't just being a jerk, but rather that I needed specific skills he did not have.  So take a look at what your skills are, and either search for the jobs that fit you, or if you don't have the skills for the job that you want, go learn them as best you can.  Maybe somebody is looking for a junior DBA that can join their team and grow into the position they want.