Re: How do you conduct technical interviews ?

  • From: Robert Freeman <robertgfreeman@xxxxxxxxx>
  • To: roman.podshivalov@xxxxxxxxx
  • Date: Thu, 14 Aug 2008 12:48:57 -0700 (PDT)

I expect them to understand that Oracle does not do dirty reads (unlike, DB2 or 
SQL Server by default). That user a will not see user b's changes until user b 
commits said changes. I'd expect them to describe the purpose of UNDO as a part 
of this process.

I'd like to know how you think the answer to this could be wrong answers in 
general? Dirty reads do not exist in Oracle, period.

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: Roman Podshivalov <roman.podshivalov@xxxxxxxxx>
To: georg@xxxxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Sent: Thursday, August 14, 2008 1:37:54 PM
Subject: Re: How do you conduct technical interviews ?


Hi,
 
I wondering - what answer do you expect to hear for the basis question like 
"can someone else see my modified but not commited data" ?
 
Do you expect person to tell yes or no (BTW both will be wrong answers in 
general) or you expect candidate to explain you all possible preventable 
phenomenas and how do they map to transaction isolation levels according to 
SQL92 standard and explain what isolation levels Oracle supports in what 
version 8-) ?
 
thanks
--romas


 
On 8/13/08, 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: