But I agree with what the others have said that learning Q+As will only get you so far, you are better of emphasising what you do know well and not trying to hide areas that you may be lacking knowledge in

I like your questions Grant. I usually just add in one more, it's actually usually my first (fail is and it's time to call it quits).

"What is normalization and why is it important?"

...amazing how many crickets you hear after that one....

----------------------------------------------------------------------------------Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

I like to throw in some good code and bad code samples. You pick out which one works better and tell me why. Or I will just give them some bad code and have them fix it. Amazing how efficient this is at separating the talent.

I also like to ask about set based v RBAR (thx Jeff Moden) to see if they understand the concept of using batches in SQL.

Jason AKA CirqueDeSQLeilI have given a name to my pain...MCM SQL Server, MVPSQL RNNR

A good one, which maybe is no so technical ... why are you leaving your current job? ... is tricky, is you say "salary" could lead you to trouble, like they will think you're not Loyal or money is more important than the job itself (of course, we all work for money but still) ... if you say salary was ok, they will re-ask "then why you are leaving your company" .... what I usually say (when I was looking for job) is, "I am looking for new challenges and looks like your company can provide that to me"

I like to throw in some good code and bad code samples. You pick out which one works better and tell me why. Or I will just give them some bad code and have them fix it. Amazing how efficient this is at separating the talent.

I also like to ask about set based v RBAR (thx Jeff Moden) to see if they understand the concept of using batches in SQL.

Depends if you are employing a production DBA or a development DBA, one DBA said to me once that all DBAs should be developers but in my experience the worst production DBAs are developers who are having a go at being a DBA but this is another discussion.

I've been a production DBA of many years, I've got an MCITP, I'm very proficient at what I do, I'm not an expert as no one is an expert (If you call yourself an expert you're obviously not as there is always more to learn which is another good subject for an interview question), I do some coding for the maintenance of the server and the odd bit of troubleshooting but if at an interview for a DBA role and I was presented with two pieces of code I think I'd turn the job down and explain that they were looking for a developer.

The interview should ideally be a practical test where the interviewee should fix a problem on a server coupled with a written exam and some tough interview questions. That's hardly ever the case though!!!

As the interviewee though you should be asking questions, you should also be interviewing the interviewer, ask them why they work there, ask them what they are looking for in an employee, at the end of the interview ask them if they have any reservations about yourself then you can clear up any misunderstandings, think of ten or so technical questions you can ask them, even write them down and take the questions with you, it shows you have been thinking about the company you might work for, don't ask all of them but ask the relevant ones. You might ask questions and the answers you get might put you off and save you from working from somewhere you won't like, treat the interview as an opertunity for all parties involved.

The one question I have always wanted to ask is: “Since you are obviously unqualified for this job, why do you want it?”

Answer... 'Why did you ask me for the interview in the first place then?' :)

Matt Miller (6/18/2009)I like your questions Grant. I usually just add in one more, it's actually usually my first (fail is and it's time to call it quits).

"What is normalization and why is it important?"

...amazing how many crickets you hear after that one....

I don't think I'd ask that on a screening question. I get WAY too many people that really and truly can't explain, don't know, don't understand, even after you point it out, that there is a difference between a block and a deadlock. It makes me more than a bit nuts.

I like to throw in some good code and bad code samples. You pick out which one works better and tell me why. Or I will just give them some bad code and have them fix it. Amazing how efficient this is at separating the talent.

I also like to ask about set based v RBAR (thx Jeff Moden) to see if they understand the concept of using batches in SQL.

Yeah, I love using a white board to do interviews (after the screening) where I'll put up structures & queries, some good, some bad, and make people walk me through them. Then I'll have them fix the bad stuff (where I put all sorts of odd stuff, it's fun), write their own queries, discuss the engine... I love interviews. I HATE screening before the interviews. We'll screen about 20 people for each one we interview. Legally we're required to ask everyone the same question. So even when someone doesn't have a clue, isn't even remotely qualified, is arguing with us about the answers to the questions or the applicability of the questions (why, oh why, do people think we need to program SQL Server code as if we were going to bounce it to DB2 tomorrow, Sybase next week, Oracle the week after that, and then back to SQL Server for a day or three?), we can't stop asking until we've gone through all 10. Pain doesn't begin to describe it.