I think the most important part of the article has been overlooked by those rightfully aghast at yet another seemingly “interview question” article. Here’s the quote. The emphasis is mine.
Remember also that [font="Arial Black"]this test is just one factor in your hiring decision[/font], and that resume, past experience and [font="Arial Black"]in-person interviewing skills [/font]should also inform your hiring decisions. In my consulting practice, I have found that people who score 10 or above on this test are very [font="Arial Black"]likely [/font]senior SQL developers or supporters with several years of full time SQL experience; whereas people who score 5 or less are likely junior SQL “beginners”. Scores between 6 and 9 lie in an uncertain nether land where you may need to use other questions or interviewing skills to make a determination.
“Likely” doesn’t mean “Is”. In other words, this test is a pre-interview or phone-interview filter to separate known chaff from potential wheat and I thought the author was clear on that. The author did not intend this simple test to be all to end all in the interview process for a valuable and very expensive asset. You MUST conduct an in-person interview with questions more fitting of a “Senior Level SQL Staff”. This test is just a simple and very quick method to avoid wasting real interview time on “posers” and “wannabes”. That’s all.
Another point that the author was trying to make that may have been lost on some is how to write a test. If you notice, there are no esoteric or “trick” questions, which serve only the ego of the writer of the questions. Instead, these are basic questions that good developers will surely know the answers to most. The other important part is there are no multiple-guess possibilities to most of the questions and, when there are, there are enough possibilities to limit guessing to only 12.5%, as the author cited.
I’ll also add that if you use such a line of questions on a phone-interview, keep track of how long the person takes to answer. These questions are simple enough so that if a person doesn’t start to answer almost immediately, then they’re frantically Googling for an answer because you can’t see them.
Shifting gears a bit, I’m glad that these are essay-style questions so that I could write in what I believe is a more correct answer in for question #4 (the one on 4 part naming for distributed queries). IMHO, no Senior Developer worth his or her salt would ever make the mistake of “deciding” to use the 4 part naming convention in their code. Yes, you need the linked server to avoid the 4 part naming but you should never use 4 part naming in your stored procedures, views, or other code objects other than the script to make the linked server. If you don't know how to avoid 4 part naming or the reasons why you should do so, then you'll need to look it up or ask a Senior Developer to help you because I try not to post answers to interview questions. 😉
Thomas, great article. I hope that people will read beyond the questions you included because there are some powerful lessons to be learned here.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
"If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
"Change is inevitable... change for the better is not."
When you put the right degree of spin on it, the number 3|8
is also a glyph that describes the nature of a DBAs job. 😉
How to post code problems
Create a Tally Function (fnTally)