Re: How do you conduct technical interviews ?

Actually I think this is a core question and quite important. Memorization? 
Unless you are hiring a very Junior person, you better have some kind of idea 
how this Oracle thing works. A perfect example is a question asked earlier 
today on Oracle-L. Real DBA's are faced with Real problems. Knowing where redo 
goes, what latches are and when they are taken, understanding the impacts of 
disk IO, blah blah... all of this comes out with a question like Tom is asking. 
If I'm paying someone $100 or $150 an hour, I expect that they know these 
things, because time is money and at that rate, I'm not paying to train 
somebody.

Also, a candidate who is *really* interested in the job would take the time to 
brush up on these kinds of things. When I setup interviews, I tend to indicate 
the area that the questions will be in. As a part of the interview, I'm very 
interested in how prepared they are... especially after I've given them a clue 
about what I'll be asking about. If some guy comes to the interview and STILL 
can't tell me about DBWR or LGWR, then I'm not interested.

Want to hire a medocrie DBA? Then ignore the basics. Sure, maybe they installed 
RAC... Anyone can follow instructions. Tuning, for example, is a dark art and 
it really requires a deep understanding of the product. If you don't know the 
basics, how can you hope to possibly tune the thing to any degree. 

I've also played with the idea of a practical exam as part of an interview. 
Setup an environment, give them a situation and let them have at it for an hour 
or two. A great way of seeing how the problem solve, and how fimiliar and 
confortable they really are. I've not done this yet, but I'm considering it.

Cheers!!

RF




 Robert G. Freeman
Author:
Oracle Database 11g New Features (Oracle Press)
Portable DBA: Oracle  (Oracle Press)
Oracle Database 10g New Features (Oracle Press)
Oracle9i RMAN Backup and Recovery (Oracle Press)
Oracle9i New Feature
Blog: http://robertgfreeman.blogspot.com (Oracle Press)
The LDS Church is looking for DBA's. You must be LDS to apply (please don't 
write to me and tell me I'm breaking the law. A church can choose to hire 
members of it's own faith. Look it up if you don't believe me).



----- Original Message ----
From: Dba DBA <oracledbaquestions@xxxxxxxxx>
To: oracle-l@xxxxxxxxxxxxx
Sent: Wednesday, August 13, 2008 4:10:34 PM
Subject: Re: How do you conduct technical interviews ?


I actually don't like the tom kyte question. Does anyone else like this one ? 

"

I can remember Tom Kyte  let the people explain what is inside
the instance. What is SGA, which oracle processes do we have and what is their
task. It's the same kind of question. Let the technical people try to
explain some technical stuff. They often cannot. "
it is too much memorization. I see no reason to make someone memorize every 
background process (which is what Tom wants when he mentions it). I think 
general understanding of a database and an instance and how oracle works is 
more important. I have trouble keeping track of the difference between the SMON 
and the PMON myself and don't bother to keep that in my head. 




On Wed, Aug 13, 2008 at 5:51 PM, Georg Feinermann <georg@xxxxxxxxxxxxx> wrote:

Usually I start interviews with very easy questions like "why
do we have transactions" or "can someone else see my modified but
not commited data". People coming to an interview are excited and some
basic questions help them to quiet down. In fact this is the hardest part of
the interview test because I need solid basics. Everything else people can
learn – if they have the right soft skills. If I hear a wrong answer on
the basic question – well then the interview is finished.
 
Then I start to check the ability to explain. My favorite question
for a DBA is: "Imagine, I'm a director without any oracle
knowledge. Try to explain to me what a checkpoint is". Even most of the
DBAs really know what a checkpoint is they cannot leave their technical world
and explain it in other words.
 
I can remember Tom Kyte  let the people explain what is inside
the instance. What is SGA, which oracle processes do we have and what is their
task. It's the same kind of question. Let the technical people try to
explain some technical stuff. They often cannot.
 
Just to finalize my impression I let the candidates talk. I use
open questions like "Tell me about your most horrible project and what do
you believe were the reasons why the project was not successful." I
simply want to hear what was important from their point of view. I have enough
experience to sort the answers out. Can they focus on the big points and 
distinguish
from details?
 
It's really hard to find a good staff. And it's not a
question of money you would pay. Even if you offer much more than average there
is no guarantee you will get a good one.
 
Georg Feinermann
 
 
Von:oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] Im
Auftrag von Dba DBA
Gesendet: Mittwoch, 13. August 2008 19:29
An: oracle-l@xxxxxxxxxxxxx
Betreff: [english 95%] Re: How do you conduct technical interviews ?
 
as far as compensation... I have worked with people who make
well over $100/hour who still don't have this type of personality. I have
worked with hourly contractors pulling down this type of money who will sit and
surf internet because its not a problem for their narrow domain and then expect
to be paid for surfing the internet and waiting for a problem to be solved. I
have worked with people who have 30 years experience who do this. I have worked
with people who refuse to do anything unless its totally perfect.

I have hired people who nail every answer in a technical interview, but then
when you get passed the textbook to actually doing stuff and having a decent
personality are useless. I think I have gotten alot better of screening out
people who give good textbook answers to lots of gadget questions and people
who can actually implement. 

I think its hard to find the right personality. This type of personality is
more important on a smaller team, but is useful on larger teams. I also know
that in some environments you can get in trouble for being pro-active because
its outside your domain. I have had a manager who would not allow us to check
out code and had to do it for us. She would expect us to surf the internet for
weeks waiting for her to individually assign stuff to us. I prefer the
opposite.

Lets face it. DBAs and to some extent administrators in generally have alot of
people in the profession who are just plain difficult to work with. It seems
like alot of them are autistic. You tell them one thing. They hear what they
want to here. You say something and they over react. Send an email to 15 people
and CC 3 different VPs to show you up. Or play the passive aggressive game.
Where you talk to them and they just blow you off and don't respond or say they
will do something and won't do it. These are people that know all the gadget
answers, but are just jerks. 

You know the type. They worked with some java developers on a previous project
who were idiots. Therefore all developers are now idiots and they are all
treated this way. The kind that complain about everything. Some times you just
don't have the schedule for something to be perfect, but we have deadlines and
if we want to keep getting paid we have to make do. 

I have worked with people who have great attitudes. Its just really hard to
screen them out in an interview. One thing we started doing is asking them to
describe their organization, project, and what they do at the high level. What
value do the users get out of the applications they work on? What value do they
add to management? Most of them can't get passed Oracle speak. Some are very
articulate and can explain more about what they do and how their organization
works. I find articulate people like this are often better. They can more
easily explain things to non-technical senior management and to non-oracle
techies. 

Other related posts: