May 12, 2009 at 12:19 pm
exactly. From an administering and supporting SQL perspective a person that is passionate and a very capable Troubleshooter will go far further than someone who can pass a multiple choice test. Really you would be evaluating their Troubleshooting skills. If they will be a developer you will want to include more focus on efficiency of code as well as troubleshooting. focus on their job role.
May 12, 2009 at 1:00 pm
(Steve: Feels kind of weird to be responding to this editorial... 🙂 )
The point of a VM test like this isn't to be a one-shot-interview-with-100%-success. The point is to pretty much replace an on-paper exam as part of the hiring process.
I've seen lots of people, in lots of fields (not just technical ones), who could talk-the-talk, but who couldn't do the job. That includes people with degrees and exam certs and all kinds of things like that.
The guy who replaced me at my last job, was trying to make modifications to a proc that I wrote, and he ran into a complete brick wall, because one of the "tables" in the From clause wasn't a table and wasn't a view. It was a synonym for a table on a linked server. He has certs in SQL Server, Oracle, and DB2. If I'm not mistaken he has a degree in CS. But he was completely stopped by this situation. Couldn't even think of how to figure out what the object was. Apparently, he'd never heard of querying sys.all_objects, or highlighting something and using Alt-F1, or any number of other solutions. And yes, he'd been using SQL 2005 for a few years.
Does that make him incompetent? No. But it sure says that he doesn't really understand what he's doing, he just has a set of pre-programmed skills and memorized data.
I've run into many database devs who either don't know about execution plans, don't know how to read them, or limit themselves to looking at the "estimated cost" of the operations. Again, they can pass written tests, they can handle basic issues, but they really can't do performance tuning except at a beginning level.
I've run into at least one database dev who would write a covering index for every query he wrote, whether there was a need for one or not, and whether or not there was already an index in place that would do just as well. Again, he had certs and had passed exams. He would probably look fine on paper, his resume would be "attractive", and he would probably even do fine in oral technical interviews. (The fact that he had a job as a dev and was doing this says that he got through such a process.)
With a test database with pre-built problems in it, you can test for real. Whether they are administrative problems for a DB Admin (missing backups, poorly built maintenance plans, log files on the same drive as data files, autoshrink issues, etc.), or performance problems for a DB Dev (poor indexing, cursors, etc.), or design problems for a DB Architect (violations of normal form, lack of naming conventions, etc.), or where you can ask for functionality to be added (devs again) ("build me a proc that...").
The whole idea is, tell the person what you'll be doing. "We've got a test database that we'd like you to take a look at. We'll discuss issues and proposed solutions. What's a good time for you to come in and do something like that? Are you comfortable with doing this through Management Studio?" When they come in, present them with the database, tell them "go for it", and watch them work. Ideally, the person will either dive in and start taking notes, or he'll ask, "Hey, this index looks like it's junk, and I don't see it in use, should I suggest removing it?" Let them know that asking questions about it, looking things up in BOL, even going online and asking for help on SSC/MSDN/whatever, are all fine. They'll probably be doing all that in a real job, so why not in a test?
If the person is a dev and asks about layout and naming standards before he starts to write a proc, that's probably a good sign.
If they're applying for a job as a DB Admin, and they notice right away that the disk the log file is on has no room left, and they immediately fire off a truncate command and a shrink command, without hesitation or question, that's probably not a good sign. If, on the other hand, they turn around and ask, "This drive, is it supposed to be an allocation on a SAN, or is it a fixed drive? If it's an allocation, can I ask the server admin to give us a little more space while I research the possibility of shrinking the log and do some tests?", that's probably a really good sign.
If you're looking at a possible architect, and he notices that there are tables named "[Table 1]" and "[Table 2]" and "[CustomerNamesAndAddressesAndPhoneNumbersAndEmailsAndPetsAndHobbies]", and he says, "This one, with the long name, should probably be renamed 'Table 3', so it's consistent", you don't even bother to finish the interview. Unless he's obviously joking, of course.
If any of them sits there, sweating, occassionally looking over his shoulder at you with a nervous grin, and displays adequate technical competence, that's very different from the guy who takes a bunch of notes from what he observes of the database, then confidently starts talking to you about suggested solutions, asking questions about company standards for naming, layout, etc.
Another key thing about it, is don't expect someone to find everything wrong with the database/server in a few minutes in an interview. Judge by what they find and what they miss, not by some sort of, "Joe found more things that Bob, so Joe must be better".
The whole thing is a starting point, not a whole interview all by itself. It just goes a long ways towards separating "I can spell SQL but I've never restored a backup", from the real thing.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 12, 2009 at 3:59 pm
Gus, nice post, and thanks for the details of how you use this in an interview.
Viewing 3 posts - 31 through 32 (of 32 total)
You must be logged in to reply to this topic. Login to reply