Has anyone found some good pre-screen questions for DBAs? Less on the development side and more on the administration side. Ideally they'd be multiple choice.
We're mainly trying to weed out people that inflate the resume but understand the basic concepts.
Any links? Or questions you could post?
I'd be interested in that too.
Here's a thought, dunno if it has any "legs" though:
"You've been here a month, you are on-call, and you get an alert that a server:
What do you do?
What would you expect exists (DOCs, Scripts, other stuff)?
Assuming that the stuff you expect exists what would you be doing and in what order?"
If I got a really good answer I'd employ them and get them to write those DOCs and Scripts (and stuff 
) and save me the bother !!
I guess most qs could be multiple choice, although I'd want some that weren't. For example:
1 Code the general format of the command to alter a table's column from char(30) to varchar(50).
2 Code the general format of the command to back up a database, specifying backup compression.
Those are really too simple to recognize in a multiple-choice format.
I suppose you could use:
A. ALTER TABLE table_name ALTER COLUMN column_name FROM char(30) TO varchar(50)
B. ALTER TABLE table_name ALTER COLUMN column_name varchar(50)
C. ALTER TABLE table_name ALTER COLUMN column_name varchar(50) NULL --or NOT NULL
D. another_example_command_here
One main idea there being if they don't issue ALTER commands, but instead change column types (solely?) thru the gui (yikes!), you'd want to be aware of that before you hired them, if you were still willing to hire them. To my mind, no "real DBA" would commonly, if ever, use the gui to alter a column's data type.
Naturally the qs would also vary considerably based on the level of DBA you're looking to hire.
I'll try to think of some more qs that would fit within the framework of "multiple guess".
I'd have that as one fo the multiple-choice questions, so that I could weed out applicants who chose that, or at the least ask them "How do you deploy (consistently) from DEV to QA and then QA to Production if you use the GUI method?"
Actually, personally, I often do this stuff IN the GUI, but then SCRIPT it, abandon the GUI, and then run the script instead (and save the script using our house-style filename convention so that it becomes part of the Release Scripts (to QA and then to Production etc.)
But I suspect you're not a DBA, so that's an OK method.
If someone purporting to be a "DBA" did that, I wouldn't accept it. If a DBA can't instantly crank out:
ALTER TABLE dbo.table_name ALTER COLUMN column_name new_data_type NULL;
then they ain't really a DBA to me.
Yup, good point.
I'm dyslexic and I struggle with the correct choice of all the elements when changing something like that, so I find it easier to use the GUI to produce the script for me. Perhaps I just do simple changes like that often enough to have committed it "error free" to my brain (but I could say the same thing about common words that I can spell differently 3 or 4 times on the page and they all look fine to me,at the time, when I proofread it !!)
My other justification would be that mostly? (and for the rest of the time "lazy"!!) the changes need a replacement table with all the yards of scripting that goes with that. I wouldn't want to write that by hand ...
But you are definitely right, if a DBA didn't know the syntax for a simple data type change that would be worrying!