If a DBA works for a single organization for many years and never works outside that organization then they will only have the tools that are required by that job. So a DBA can conceivably work for 15 years and not know all the ins and outs of being a senior DBA, though they are titled a Senior DBA. If a DBA works a few years here and a few years there, acquiring the skills each unique experience affords then, as well as working with various other database professional, they learn to use a wider variety of SQL tools and master more of the techniques required to perform at a senior level.

GSquared (10/15/2010)On the other hand, someone can be a very skilled DBA without being a skiller performance tuning expert. "DBA" covers WAY too much scope these days.

That's why I used to check CV for responsibilities before interview. If your CV states that you are a performance tuning specialist and don't know what an execution plan is or where to find it and have never heard of Profiler, there's a problem...

GSquared (10/15/2010)On the other hand, someone can be a very skilled DBA without being a skiller performance tuning expert. "DBA" covers WAY too much scope these days.

That's why I used to check CV for responsibilities before interview. If your CV states that you are a performance tuning specialist and don't know what an execution plan is or where to find it and have never heard of Profiler, there's a problem...

But Gail, I'm a performance tuning expert, and last I heard, profiling is politically incorrect....

I personally feel that I get discriminated against because of my time in grade as a SQL Server DBA. I have been exposed to a lot of facets in the world of SQL Server, and feel like I have a decent skill set. I've had a recruiter tell me that due to my 4 years experience, I did not posses the edge that the more seasoned (aka. 7+ years experience) SQL Server DBA's had. I told him to put me up against one of your seniors and I will show you what I can do.

I believe the industry as a whole may place too much emphasis on the years of experience, versus the actual aptitude of the individual they are interviewing. By putting the scenario exercise in place during the interview process, this bias can be erased from the industry.

In my little corner of the world, this has atleast been my experience.

Tim Parker (10/15/2010)I believe the industry as a whole may place too much emphasis on the years of experience, versus the actual aptitude of the individual they are interviewing. By putting the scenario exercise in place during the interview process, this bias can be erased from the industry.

Tim Parker (10/15/2010)That hits the nail on the head. I agree with you 100%.

I personally feel that I get discriminated against because of my time in grade as a SQL Server DBA. I have been exposed to a lot of facets in the world of SQL Server, and feel like I have a decent skill set. I've had a recruiter tell me that due to my 4 years experience, I did not posses the edge that the more seasoned (aka. 7+ years experience) SQL Server DBA's had. I told him to put me up against one of your seniors and I will show you what I can do.

I believe the industry as a whole may place too much emphasis on the years of experience, versus the actual aptitude of the individual they are interviewing. By putting the scenario exercise in place during the interview process, this bias can be erased from the industry.

In my little corner of the world, this has atleast been my experience.

Write articles for sites like this one. Once published, put it on your resume. You may be surprised how big an edge "being published" can give you, even with a dearth of years. Then prepare to dazzle with tech screening answers.

I just finished job hunting a few weeks ago. I got 6 interviews in one week, and every single manager mentioned that having published articles mentioned right near the top of my resume was one of the key reasons they wanted to interview me. Got me past a lot of people who would otherwise have rejected my resume because I don't have a degree.

And in every interview, I made sure I didn't give "stock" answers to the technical questions. Give memorable answers. (This works best if your memorable answers are accurate, of course.) Never brush off a question. Even the standard "what's the difference between table variables and temp tables" can make you memorable if you can quote some data about "there are DBA urban legends that table variables are faster because they're stored in RAM, but Microsoft says...". The other twenty people who interview will give the stock answers, half of them will give the wrong data. You say something accurate, memorable, and that shows a deep understanding of the subject, and you'll stick out in the interviewer's mind.

You don't have to be memorable on every answer you give. You just have to be memorable at least once. Marketing research shows that most people can only keep the top three brands in mind when asked about any given product, and it'll be based on "flash", not "substance". You are the product that you're selling, and your answers and conversation are your "flash". People will even misattribute positive qualities to the most recognizable/memorable brand name, even when clearly advertised about a less well-known brand. (Works conversely too. People will read a news article about a problem with an Apple product, and will answer that it was about Microsoft if asked about it the next day.) This doesn't work as well with people who are themselves experts on the subject, but still applies.

Engage the interviewer in a conversation, and not a dull, routine one. Nobody will remember the DBA interviewee who says that "there are three types of backups: Full, Diff, and Log", they will more likely remember the guy who says, "there are three main types of backups: Full, Diff, and Log. Did you know that SQL 2008 can natively compress backups, and that it's actually faster when they do that on most servers? I/O is more of a bottleneck than CPU, so the extra work the CPU has to do to compress the backup is more than made up for by the reduction in I/O bottleneck because you're writing less to the disk. Kind of cool, isn't it?" Even better yet, "Full, Diff and Log. Have you had a chance to try out the new backup compression in SQL 2008?" That lets the interviewer engage, instead of just listening to you ramble.

When they ask if you have any questions, at the end of the interview, ask "Am I leaving you with any questions or concerns about my ability to do the duties of the job?" Clear anything up at that point.

I followed those rules, and I got offers from all 6 companies I interviewed at. Your milleage will vary. But do try it.

Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.

Senior DBA is a title. That's all it is. Companies have job titles for each position. Regardless of whether it is called Senior DBA, Lead DBA, or Super DBA...it usually just means the one who's been at the job longest or the most knowledgeable. It only relates to that company and the co-employees.

However, it can give a starting place in an interview. I worked for a company where my job title was Senior DBA. Was I the senior DBA - yes - I was the ONLY DBA. Was I an experienced DBA, no way, it was my first job after I got the training. But I was a Senior DBA.

Just because someone's resume says their job title is Senior DBA doesn't mean their experience matches.

But another thing to consider, someone who has 7 years of experience could be a 'senior' DBA - it just might be in SS2000. So saying a person isn't a 'senior' DBA because they aren't a guru in SS2008 really isn't fair. Not every company upgrades to the greatest and latest.