AW: [english 93%] RE: How do you conduct technical interviews ?

From: Georg Feinermann <>
Date: Thu, 14 Aug 2008 21:24:47 +0200
Message-ID: <005901c8fe43$6d71d620$48558260$@de>

Maybe, I've been misunderstood. My question about checkpoint is not a memorization. I would like to hear the basic idea behind it. If the answers is "it's about synchronization" - I'm already happy. The perfect answer would add something like checkpoint frequency too low - maybe a recovery time problem. Checkpoint frequency too high - maybe a performance problem.  

That's all. In fact I would not like to hear anything about SCN, file headers and so on. I've asked this question about 10 times. One time I got the correct answer. Many times I got the correct technical answers (but using many technical words). One or two times they said, they have no idea what a checkpoint is. Well, time for a new DBA candidate. I have never asked a developer about checkpoint - they don't have to know about it.  

The same story is about the processes in the database. I don't want to hear too much details. Just give me an impression, you have understood the basics - and I'm happy.  

Von: [] Im Auftrag von
Gesendet: Donnerstag, 14. August 2008 19:33 An:; Cc:
Betreff: [english 93%] RE: How do you conduct technical interviews ?    

Yeah if memorization was the answer I would be out of a job a decade ago. Indeed that is one of my problems learning foreign languages. I'm waiting to live there and I know it is easier then. I have looked up and read about Checkpoints every year or two for 15 years, and yet I'm thinking - done forgot although the simple one liner is in the back of my mind. so for the interview, yes I would look up the frigid response so I don't look so stupid to people expecting answers to 'simple basics'.  

Being the only DBA, now for two companies for four years, (no I've only been a DBA for four companies), I find it mind boggling how much there is to know. I have so many scripts that I know my library, and practically everything I do is documented and categorized so I can 'find' it again. Rotating logs for the OEM Application Server, Learning Grid, Rman, materialized views, streams, data pump, AWR, upgrading all types of databases . like peoplesoft (geez, I meant peoplesoft where the tools version has been frozen back in time).  

On and on and on. For #@$ sake, why would you memorize everything. It just changes in a year or two anyway.  

Take Einstein's MO when asked his phone number (that he didn't know). Why memorize something I can just look up? Touche. Interviewers have a hard time, and I've been there, but interviewees have a hard time also because of pre-conceived notions. Heck I do the job, by myself, . you give my my library and your database and I'll give you the answers or the solutions (eventually depending on how hard the issue). .. I can look inside my script for the answer - oh yeh! (I put it there), but I don't necessarily type everything every time and so don't remember. Like was it DBA_USAGES_STATISTICS, or DBA_FEATURES_USAGE_something.. Use it once a year, don't need to remember it. Know where it is, and in fact I would run or automate a script that uses it for years until I needed to know it again.. After which time I would promptly forget it again..  

Like that checkpoint thingy.. Flush it, log switch, io get it together, database restore .. . Face it, I can look it up and get the pat answer in no time right from Tom's Expert Oracle database architecture book (which is another I would review).  

So. yes some of these questions that are meant to 'filter' out the candiates can server to 'filter' them out a bit to fast.  

From: [] On Behalf Of Andrew Kerber
Sent: Thursday, August 14, 2008 9:24 AM
Subject: Re: How do you conduct technical interviews ?  

You have to draw a line somewhere on the memorization piece. I might ask the interviewee to name a few background processes in the Oracle database on *nix, but I wouldnt necessarily expect him to go into detail about what each process does.

A general answer would be sufficient, for example pmon monitors processes running in the database. If the candidate needed highly detailed information, I would expect (and want) him to look it up. In my opinion, the ability to find an answer to something that he doesn't know the answer to, or to check on what he thinks is the answer before he does something, is vital.

On Thu, Aug 14, 2008 at 8:10 AM, Dba DBA <> wrote:

I never said they need those skills. What I want is the right type of personality where they will try to solve a problem in stead of surfing the internet and waiting for someone else to do it.  

On Thu, Aug 14, 2008 at 1:47 AM, Pedro Espinoza <> wrote:

It is kinda hard to get candidates who have networking, sysadmin, db skills. There is no one to blame for such state of affairs except for the industry. Nowadays, employing a person is like buying a commodity, so that companies can easily replace(buy) commodities (an oracle dba with another; a db2 dba with another; solaris admin with another solaris admin).

On Wed, Aug 13, 2008 at 9:01 AM, Dba DBA <> wrote:


The kind of people I don't like are the cancer type. One thing goes wrong. They completely stop working. They send one email and then surf the internet. Make little to no effort to follow up. Someone gets back to them, its not perfect. One more email and back to surfing the internet.

There are alot of people like that. How do you find pro-active, smart people, with positive attitudes ?    

Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

Received on Thu Aug 14 2008 - 14:24:47 CDT

Original text of this message