RE: Designing a DBA interview process to validly measure candidate abilities.
- From: "Freeman CTR Donald" <donald.freeman.ctr@xxxxxxxx>
- To: "rjamya" <rjamya@xxxxxxxxx>, "ORACLE-L" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 15 May 2013 08:46:56 -0400
>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!
--
//www.freelists.org/webpage/oracle-l
Other related posts:
