RE: Designing a DBA interview process to validly measure candidate abilities.
Date: Wed, 15 May 2013 08:46:56 -0400
Message-ID: <01A5BB2CD1A5394C894C7D94EE4E6E49023472EE_at_mcusquanez28v.mcdsus.mcds.usmc.mil>
>I try to ask these, but now-a-days the most answer i get is " I go to the website " (perhaps which shall not be named) and see what I can find. Even asktom is getting down in popularity in answers >compared to google. OakTable is virtually unknown or never mentioned. As for recently read books" i normally get " oracle manuals", for the question "which authors or blogs do you follow"? normally gets >the answer "none, there are no good blogs, so I only read manuals ". I could even take StackExchange, but not even that.
Well, stating that you go to MOS or read the documentation is a safe answer. I might follow up with a question that would enlighten me to how familiar the candidate is with the manuals. Which manual do you think would provide you with information about "X?" The goal here is to find an exceptional candidate in terms of initiative and self-motivation. The flip-side of this is you might hire the DBA who won't recognize that he/she needs help from either you or other team members. I remember that Stephen Feurstein wrote a little bit about team management in (one of his) PL/SQL books awhile back where he said that he gives his team members 30 minutes to be stuck on a problem before they are encouraged to ask for help. I thought that was a good idea and a better idea to spell it out clearly so that team members don't have to guess whether or not they are going to get their heads bitten off for interrupting your game of solitaire <j>.
On the self-reliant front I worked with a DBA who had a software engineering degree who was very proud of having not asked a single question of the professor in 4 years of college. His reasoning was that the smart guy was the guy who wrote the book. Not the guy who was standing up in front of the class teaching from it. He gained all his knowledge of the subject from reading the book. I'm trying to remember if that guy ever asked me or anybody at our office for help or advice in seven years.
>Not done that, but if I would risk that, probably worth a try. I also like to ask a variation of this question to those who claim lot of experience in production support etc. " name one incident when >you screwed up something in production that caused problem/pain and how did you find it and fixed it? ". Most dbas worth their salt have one time or another have made a mistake, but recognizing that >quickly, and fixing that takes accountability and quick analysis. Sometime I do get answers, most times a blank stare. or best answer yet " all my scripts are so tested, this has never happened to me."
You are measuring a couple of things here. Honesty is one of them. You can't have anybody in this line of work who will lie about errors. So, I am somewhat reassured if somebody is willing to tell me about something they did on another job. If they can't discuss that then they probably aren't going to be able to explain what they did in the data center last night while working for you. The guy whose scripts never failed because they were so well tested may be a real person. I've met people who had a very low error rate. That comes at a cost as well. Can they complete their work on time? All that testing takes time. If they can deliver the goods with no errors then you've made a good hire!
-- http://www.freelists.org/webpage/oracle-lReceived on Wed May 15 2013 - 14:46:56 CEST