Re: Hiring DBA's

Couldn't agree more with both of these posts.

I'll just add my (devalued) $0.02:

• what I've found over the years is that good dba teams are rarely "found". They're "made".

Yes, sure: once in a blue moon you might be lucky and get hold of a guy/girl who's just "got it" and will make an absolute cracker addition to your team.

If you're waiting for it to happen or sifting the sand for it, good luck: it'll take a looooong time to build that team.

IME, good dba teams are made. Not found. Takes too long to go finding. OCP or no OCP, attitude or no attitude, you're relying essentially on pot luck.

To me it's the task of the manager/team leader/whatever, to recognize the *potential* good dba in one already in-house, who will also be worth investing the time to bring up to task.

Extremely rewarding, when your dba becomes an essential member of the team as a result of your personal investment in helping them develop their knowledge and experience. Catch: it's gotta be their commitment, you can only help them develop the rest.

And the pinnacle is to pick someone who is *not* good dba material and over a reasonable period see them turn into one. That indeed is the most rewarding moment.

-- 
Cheers
Nuno Souto
DBA Team Leader, Aus/NZ
in sunny Sydney, Australia
dbvision_at_iinet.net.au


Newman, Christopher wrote,on my timestamp of 16/08/2008 1:17 AM:


> 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_at_optusnet.com.au

> 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.

> 


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