Re: Job interview questions

Date: Thu, 4 Jun 2015 16:35:59 -0400
Message-ID: <>

Yes, I think a good interviewer will do this -- as a precise technical question as an "ice breaker", rather than in search of a precise technical answer.

A recent example was "What parameters do you set to adjust the size of the SGA?". In my response I mentioned -- vaguely -- several of the relevant parameters, and explained that I stopped trying to memorize "trivia" like parameter names years ago, because I can almost always find the *correct* value in 5 seconds, with a google search or equivalent. (In this case, the parameters I am interested in probably already appear in the SPFILE.)

I also mentioned that the parameters themselves and the way they interact with one another can change subtly from version to version, so before doing anything radical I usually consult the documentation to refresh my memory. 5 minutes invested up front can save hours of embarrassing downtime!

In some places, my answer would have been considered "wrong", or even ended the interview. In that case, I was offered the position.

On Thu, Jun 4, 2015 at 2:34 PM, Tim Gorman <> wrote:

> I'll take a whack here too...
> I think the intent behind asking obscure technical questions is to
> initiate a conversation on a very specific technical topic. With luck, the
> seemingly trivial question can reveal not only that the candidate is fluent
> on the whole topic, but also something about how they relate to other
> people and how they might fit in.
> For example, asking a question such as "*What is the common nickname for
> an 'inconsistent' backup?*" (answer: "*hot*" or "*online*" backup) can
> lead to several great follow-up questions about how backups are captured
> and why they're recoverable. For example, if they get that right, you can
> then ask if simply restoring an "inconsistent" backup is sufficient to open
> a database successfully, or whether additional steps are necessary (i.e. "
> *no*" and "*recovery rollforward with redo logs*" are good follow-up
> answers). If you have a suspicion that the candidate is snowing you, then
> you can ask whether datafiles are "locked" against writes while they're
> being backed up or not, and find out if they have some whopping
> misconceptions about how Oracle works.
> Getting these answers correct or incorrect is not really the point; lots
> of good people get them wrong. In real life, people can google for these
> answers.
> But how they interact with you during this conversation is very
> revealing. Whether they know this stuff or not. Whether they freeze up
> when faced with a complex problem, or whether they grow more engaged and
> animated at the challenge. Whether they actually get angry when confronted
> with their failure.
> If they know their stuff and answer correctly, again it is illuminating.
> Some get cocky and rattle off the answer in an almost arrogant fashion.
> Some are undoubtedly arrogant about it. Some are just matter of fact and
> cool and collected. Maybe you want arrogant. Maybe you don't.
> Of course, the follow-up questions can go another way, into personal
> experience and war stories. "*What is the scariest situation you've ever
> encountered?*" Every infrastructure person has been scared stiff at one
> point or another, and if they haven't, then they haven't done anything.
> It's not fair to ask someone about their failures during an interview, but
> I think it is quite kosher to ask someone about when they were most
> frightened.
> So, an interview isn't merely a series of trivia questions to be scored,
> summarized, and averaged. No doubt scoring correct answers is useful, but
> there's much more. Good questions encourage the candidate to reveal
> something about their own characters.
> On 6/4/15 12:02, Iggy Fernandez wrote:
> Dear TJ,
> I absolutely loved the blog post recommended by June and read every word
> of it.
> I remember the interview at which I could not answer the question "how
> do you enable block change tracking in a database?" (The answer is "alter
> database enable block change tracking,") I don't want to work for Yahoo any
> more.
> I remember the time when I could not get hired at Google because I could
> not solve a riddle.
> I don't want to work for Google any more.
> I remember the worst interview of my life when the hiring manager walked
> me to the door when I correctly answered a simple question about redo logs
> (he was wrong).
> I don't want to work for [let me protect the guilty] any more.
> Personally, I don't think the absence of particular technical skills
> matters that much. They can always be learned by a motivated learner. I
> would prefer a motivated learner rather than a really knowledgeable person
> with a bad attitude or who never got anything done.
> The person's work history and the opinions of his/her previous
> co-workers and managers is the information we need but we don't have it.
> Only some LinkedIn accolades like "his unique skill taking on abstract
> blue-sky corporate objectives and converts them into specific actionable
> goals".
> The company takes a big risk by hiring me (how can anybody really
> evaluate me in a few hours?) but the bigger risk is the one I take in
> joining a company. The question I want to ask (but never do) is "Who am I
> replacing? Why did they leave? What did they not like about the job? Can I
> call them?" Also, "Do you believe in work/life separation?" Also, "Do you
> ruthlessly lay of employees like [let me protect the guilty] in order to
> achieve the quarterly earnings target?" Also, "how crazy is database
> administration in your company; is it as wonderfully wonderfully
> (wonderfully) smooth as eBay and Intel or as crazy and terrible as [let me
> protect the guilty]." Also, "Do your team members go to NoCOUG conferences
> and, if not, why not?" Excuse my NoCOUG plug.
> I would hire a young person or experienced person and teach them all I
> know but companies don't like to do that. They do like to complain about
> the shortage of good DBAs though. I once hired a person with very little
> Oracle or DBA experience and asked him to work on certification. He
> completed certification (8i) in nine months and, 15 years later, is still
> with the same company as a glorified Oracle architect.
> For every technical hard-to-answer question somebody asks me that I
> cannot answer (e.g. how do you fix wait event "X" on Exadata 12c Release
> 2), there is a technical harder-to-answer question that I can ask them that
> they can't answer. My favorite is "What is serializability of transactions.
> Does Oracle provide it?" (the answer is "No").
> with
> two additional links at the bottom.
> I have never met a DBA who could answer the question "what are the
> deliverables of the DBA role?" to my satisfaction. How likely is it that
> I will work on the deliverables if I cannot articulate them? Installing
> security patches is not a deliverable, but a task. I would hire a SQL
> Server DBA who could give me even a partial answer and was a quick learner.
> .
> I have often been rejected for jobs because I was not competent enough *at
> that time*. I have achieved all those competencies by this time but,
> strangely enough, I no longer want those jobs any more. There are jobs out
> there that I want but they won't hire me because I am not competent enough *at
> this time*. C'est la vie.
> Just some random thoughts of course. Kindest regards and best of luck
> finding and retaining great people.
> Iggy.
> ------------------------------
> Date: Thu, 4 Jun 2015 18:29:19 +0200
> Subject: Re: Job interview questions
> From:
> To:
> CC:
> Hi,
> an interesting post I recently read:
> Regards
> On Thu, Jun 4, 2015 at 5:50 PM, TJ Kiernan <> wrote:
> For those of you who have conducted job interviews, what sort of
> questions have you found to be effective in evaluating a candidate’s skill
> level? I’ve started a list that consists of some Oracle trivia and some
> open-ended work habit/personality type questions.
> Incidentally, I know of a Oracle DBA job opening in Omaha, NE. Please
> contact me off-list if you’re interested in knowing more.
> Thanks,
> [image: NPS.png]
> T. J. Kiernan
> Lead Database Administrator
> National Pharmaceutical Services
> P.O. Box 407 Boys Town, NE 68010
> Direct: (402) 965-8800 extn. 1039
> Toll Free: (800) 546-5677 extn. 1039
> E-Mail:


Received on Thu Jun 04 2015 - 22:35:59 CEST

Original text of this message