Search This Blog

Monday, March 31, 2008

Article on DBA Interviews - SQL Server Central dot com

I was just looking through the session list at PASS this year and I noticed something a little different. There are professional development tracks. These are sessions on how to be a successful DBA, change management, etc. Personally, I'm really glad to see that someone is finally taking some interest in helping DBAs in areas other than just technical. Don't get me wrong, plenty of us could still use plenty of help in that area (more on that in a minute), but there's really more to being a good DBA than just sitting in your cube with the lights out watching Spotlight with a bottle of lotion in one hand, and a Kleenex in the other.

Today's DBAs are expected to give presentations to management, teach users, make recommendations based off of business requirements (not just technical), and be a shoulder to cry on when someone loses data. This is a huge responsibility and I urge a lot of you to take advantage of some of these sessions. I'll be there.

On the other side… it's time for a little fun. I promised you to talk about getting help in the technical area, so here it is. I'm in the process of finding another DBA and I recently finished another round of interviewing. Here are some of the answers I got from my esteemed interviewees. I'm not going to give you the correct answers, but compare your answers with theirs, and if you answer the same, similarly, or can't see why the answer is wrong, SEEK HELP RIGHT AWAY!! Ok, here goes:


Q: What is TempDB?

A: The database used for guest accounts. You give a guest user access to TempDB so that he can have access to your system without having rights to anything he could harm.

Experience: This DBA has 10yrs in a production environment.


Q: What's the different between char() and varchar()?

A: char() only holds letters while varchar() holds letters and numbers.

Experience: This DBA has 8yrs.


Q: What's the different between char() and varchar()?

A: char() only holds 1 character while varchar() holds as many as you like.

Experience: This DBA has 12yrs and considers himself an expert in writing SPs.


Q: What is fill factor?

A: Fill factor controls the size of the transaction log. The higher the fill factor, the longer the system waits to checkpoint.

Experience: This DBA has 12yrs and considers himself an expert in writing SPs.


Q: What is checkpointing?

A: Checkpointing is the point at which the system checks to see if the transaction log needs to be truncated.

Experience: This DBA has 12yrs and considers himself an expert in writing SPs.


Q: How much memory does SQL use on startup?

A: That's a trick question because SQL doesn't use memory, it stores its information on disk (I guess he got me on that one).

Experience: This DBA has 5yrs.


Q: What is an acceptable disk queue?

A: 15%.

Experience: This DBA has 10yrs in a production environment.


Q: What's a page fault?

A: A corrupt data page caused by trying to write something you shouldn't like writing int to varchar().

Experience: This DBA has 10yrs in a production environment.


Q: OK, then how do you fix a page fault?

A: I forget the name of it, but there's a DBCC for that.

Experience: This DBA has 10yrs in a production environment.


Q: What's the difference between a full and a differential backup?

A: A full backup fills up the tape, and a differential is different because it removes the data it doesn't really need to save space on the tape.

Experience: This DBA has 5yrs.


Q: How do you restore a single table from a backup?

A: I think it's DBCC PartialRestore, or TableRestore… something like that.

Experience: This DBA has 5yrs.


Q: What is the model DB?

A: It isn't used at all. I usually delete it.

Experience: This DBA has 5yrs.


Q: What is a bookmark lookup?

A: It's what SQL uses to keep track of the next query it needs to run.

Experience: This DBA has 10yrs in a production environment.


Q: What's the difference between delete and truncate?

A: Delete gets rid of the rows in the table for good, and truncate copies them all to a history table first in case you need to get them back.

Experience: This DBA has 10yrs in a production environment.


OK, that was fun. Unfortunately, all of those answers truly did come from candidates with the experience listed. I only wish I could make up fiction like that. The sad part is a lot of these guys are senior level DBAs in very important companies, and if I were to reveal which ones, you would pull your bank accounts, trade in your cell phones, sell your stocks, and shred your credit cards. It's honestly scary the complete incompetence of the people in charge of some of the most important aspects of our lives.

It's very discouraging when a guy who works in a very high transaction environment who claims to do conflict resolution several times a day, can't even tell me what a deadlock is. And this same DBA has never even heard of sp_lock. How is that even possible? I am, of course, just ranting now, but come on guys… pick up a book. We live in an age where information has never been more available than it is right now. When I started doing DBs there weren't that many books, and DBAs didn't part with information very easily. You had to learn everything through trial and error, or find an obscure resource that just happened to mention something. The deeper aspects of DBs and OS systems have been revealed over and over, yet some people just refuse to pick it up. Gone are the days where you can sit on what you know and just collect a paycheck… or are they? I mean, these people are not only making a good living, they're getting job after job. We're all competing against them for every position we go for. And the problem is that the hiring managers don't know the difference.

I don't expect anyone to know everything, but when a 10yr DBA doesn't know the difference between char and varchar… come on. What am I supposed to do with that? If you forget some of the subtle nuances of SQL and have to look something up I understand that… hell, I'm in BOL almost every day looking up something… but there's a base level of knowledge that we should all have. Not knowing some of these basics is like you telling me you've been a DBA for 10yrs and you can't explain to me what SEM is used for. Anyway, that's my rant for now… does anyone have anything to add, or any other interview stories?

No comments: