RE: Hiring DBA's
- From: "Freeman, Donald" <dofreeman@xxxxxxxxxxx>
- To: "'cjnewman@xxxxxxxxxxxxx'" <cjnewman@xxxxxxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 15 Aug 2008 17:05:33 -0400
My story is the same ex-military with limited useful technical skills. I 'm a
DBA manager now. I got into my DBA job with a bit of Oracle knowledge and a
couple years of SQL/PL SQL coding. I definitely couldn't have passed a real
DBA interview. About 90% of what my team does is pretty routine stuff. If we
have a really hard problem we put a ticket in and post here and work our way
through it.
Donald Freeman
Database Administrator II
Commonwealth of Pennsylvania
Department of Health
Bureau of Information Technology
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Newman, Christopher
Sent: Friday, August 15, 2008 11:18 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Hiring DBA's
I thought the below post was pretty good. Having been both a DBA manager and a
DBA, I can tell you that the ideal mix of folks is people who are super techie,
and folks who are great people. The folks who are super technical will teach
the others, and, in turn, they will learn better people skills, resulting in a
solid team. If you look for first for good work ethic and motivation when
hiring, you'll be in good shape.
I'm ex-Army, and I got my first tech job with really no technical skills and a
BA in History. If I'd have been given a tough technical interview, I might not
have had the chance to show what a great hire I'd be.
- Chris
From: caseydyke@xxxxxxxxxxxxxxx
Date: Fri, 15 Aug 2008 09:28:52 +1000
Subject: Re: RE: How do you conduct technical interviews ?
It's rare that I get to keep up w/these list these days but the mail still
flows and occassionally i have a peek. i'm responding to this thread b/c as a
manager of a group of dba's, it's quite important to me and something i am
pretty opinionated on.
we work in a reasonably high end environment for a very visible entity here in
Australia. lots of big systems, big projects, big pressure and so on. we are
highly projectised and delivery focused. we work in between networks, storage,
OS and development groups. that's probably like quite a lot of groups out
there, nothing out of the ordinary.
but what i feel as a hiring manager is it is *very* hard to find (i think
reflecting the sentiment of the original poster) _that_ dba. you know, the one
that goes the extra mile, doesn't faff around, gets the job done, takes it
seriously.
over time i've managed to build an eclectic team makeup that meets our needs.
but it hasn't been easy. i've turfed a number of dbas (we're all contractors
so "turfed" (or boned in local nonmenclature) simply means no renewal) b/c
their performance wasn't what i and the business required.
and so often i find people in interviews that are db "administrators"
only. a lot know nothing about modelling. a lot really know nothing about
development, storage and even core OS issues. certainly not all, but a lot. i
also find some really just not good enough in a generic IT sense. limited
peripheral knowledge.
mind you, some people that had that broad mix, simply did not perform.
lots of good peripheral knowledge, but man o man delivering a project on time
was just impossible. another example is of fantastic out of left field
technical knowledge, but hopeless time management. leaving me picking up
project pieces w/my head in my hands, yet reluctant to rant b/c i know the
individual has "that idea" just waiting in the back of their head. i had one
quite unique situation where i was told "my 4 hours are worth 8 from others".
so late arrivals, long lunches and early departures were the norm. you're
joking right? nope. boned.
maybe i am describing standard mgmt, but the main point is -- there is no
silver bullet. it takes time to build a team and even the best hiring
questions/practices might not be enough.
what i do look for is years in the game, peripheral knowledge and/or interest,
detailed knowledge (yes, for what we do -- i expect this), SDLC understanding,
programming of some nature, source control (!! geez i've banged my head against
the wall b/c people just "bung" code in) opinions (opinions are very important
to me), OS, storage and network knowledge. and a sharp troubleshooting
ability/ethos. that's key too.
lastly, commitment. define it. what does it mean to you. people w/out
commitment don't work too well in our shop and i dare say we're not unique!
quite often in interviews i go on gut feel. i rarely go in "prepared", i just
fire away. we never do less than 2 interviews. and i always let other team
members have a say. and more and more i am less dba question oriented (tell me
about the FRA) and more peripheral question oriented (ie: describe, in
reasonable detail, the ideal network setup for a 3 node rac cluster).
OCP doesn't play much of a role for me. it's *very* easy to determine what OCP
means to a candidate. if someone looks me in the eye and says, "look, i got
the OCP to challenge myself and ensure i kept up w/11g new features". bingo.
that's it. very very very easy to determine whether it means anything. i've
always been amazed at the hollow debate it initiates. to me it indicates
motivation in the *right* candidate.
little else in "other" candidates.
dunno if that helps and it's pretty long-winded so if you've made it down here,
maybe it did. best of luck.
Chris Newman
Database Specialist
AITS, University of Illinois
217-333-5429
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
