I have a similar list of basic questions I ask DBA candidates and am often surprised at the discrepancy between stated experience level and the answers given. Even worse is that I am not necessarily looking for the correct answer. If a candidate says that they do not know the answer and then proceeds to describe how they would go about getting the answer, that is as good as answering the question correctly. More often than not I turn to BOL, MSDN, SQLServerCentral or other resources to get answers to questions. An ability to critically think through the question and knowing where to find answers is every bit as good (if not better) than being able to spout the answer from memory.
Of course, some items should be ingrained: like the difference between a char and a varchar. Other things (e.g. how to fix a page break) can be easily looked up and one should know how to use the resources at hand. Even with 10 years of experience, they may be items that one has never encountered. A DBA could easily go 10 years without ever having to work with Replication, or clustered servers, or a number of other items. That is why I always ask candidates how the go about learning new techniques and where they turn to for answers (searching the internet is not acceptable as the only answer!).
My 2cents (South African cents = +- 0/16 p )
The "SEM" also through me. I refer to it as EM, or more frequently as Enterprise Damager ... (too many users have had access in too many places ... *sigh*)
I can add a few:
q> What is your opion of nulls?
a> (2nd time around, after asking if we could come back to it) they are used to enforce referential integrity.
This was from someone who had impressed the tech-manager by getting 90+% on the measure-up MCSE questions that we sue to pre-filter applicants. Needless to say, the interview went seriously downhill from here, but I did manage not to laugh in the interview itself, but it was a total guess session (and he wasn't good at guessing).
An excellent article!!!!
We've been doing some interviewing for SQL developers and about 1/2 the time I walk out of there saying hmmm..... well I guess we'll have jobs forever 'cause these people just don't get it.
Spouting facts is one thing but being able to actually walk the walk is more important - so the kinds of questions to ask are not what property does what, moreso situational like how would you fix the performance on an sp that does....
I believe some of these folks have worked for me over the years
Most sound like they might benefit from a tidbit of wisdom that Chip Foose (a very prominent custom car designer) said his father passed on to him: "The most important education I ever received was the things I learned after I knew it all". Too often people, especially professionals, seem to forget that education is an ongoing process that ends only when your days on earth end. They learn just enough to get the job and presume that they know everything they need to know.
Even more irritating is the management philosophy of "not actually knowing anything", but being able to BS your way to the top. Unfortunately, most folks I have reported to fall into this category.
I bow my head in shame...
As a DBA with 8 to 9 years experience, I flopped on the Page Fault question... In an interview, because I would have been thinking of physical pages on disk, not memory pages and swap files, I would have most likely given a similar, and just as faulty answer. And worse, I would have thought that I was on the right track... I just looked up the Page Fault and realized that though I intuitively knew about the Page Fault problem (I ran into it when I was using Table Variables with very large table sizes) I never linked that name to it.
To think, I've gone all this time in my career, from one small company to another, the only DBA guy in each company, so no one to turn to, teaching my self as I read from books to solve business questions and get my certifications, I hold a MCDBA in SQL 7.0 and SQL2000, and yet I didn't know something as basic as the Page Fault.
Now I know that... But that doesn't relieve my guilt and shame. I mean, SQL is so big, and I know that there are thousands of other things out there that I still don't get. I feel like such a fraud. So, I was wondering, should I turn in my MCDBA's? And how do I go about doing that?