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_at_feinermann.de>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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> *Im Auftrag von *Dba DBA
> *Gesendet:* Mittwoch, 13. August 2008 19:29
> *An:* oracle-l_at_freelists.org
> *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.
>

--
http://www.freelists.org/webpage/oracle-l