Re: Questions for a Jr. DBA
- From: Kellyn Pedersen <kjped1313@xxxxxxxxx>
- To: niall.litchfield@xxxxxxxxx, sfaroult@xxxxxxxxxxxx
- Date: Mon, 7 Feb 2011 11:14:40 -0800 (PST)
I've tried to follow this thread, but yes, I'm really bad at that these days
with the amount of hours I'm putting in, so I'll just jump in here and cross my
fingers... :)
I'm going to add to Niall's...
In all DBA interview situations, the team should be of high consideration, too.
Although we can't be psychologists, I always ask these questions to myself
during the interview process:
1. How does the candidate's personality and skillset complement the current
DBA's in the group?
2. Are their personality conflicts that could be detrimental to the group?
3. How in the long term will this person find the position, (challenging,
stifling, i.e. short-term fit, etc...)
Personality and mindset is as important as the person's skills in how they will
fit into the team.
Kellyn Pedersen
Multi-Platform Database Administrator
www.pythian.com
http://www.linkedin.com/in/kellynpedersen
www.dbakevlar.com
________________________________
From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
To: sfaroult@xxxxxxxxxxxx
Cc: cicciuxdba@xxxxxxxxx; oracle-l-freelists <oracle-l@xxxxxxxxxxxxx>
Sent: Mon, February 7, 2011 7:31:05 AM
Subject: Re: Questions for a Jr. DBA
One thing that seems to me to be missing both from the question and the
responses is what it is the person that is to do. I'm not sure that there is
common enough agreement on what a "Junior DBA" actually is. (Or a Senior one
for
that matter :) ). In addition its not clear - for more obvious reasons - what
the rest of the hiring process is.
The core purpose of the recruitment process is, surely, to discern which of the
available candidates is likely to be the best option for the team. The
technical
interview so it seems to me has 2 distinct purposes within that. First does the
candidate seem likely to have the skills required for the jobs that you will
initially assign to them. Second will the candidate enhance the value of the
team to the enterprise. In some places the tech team gets no say over the
second
part of the process (and probably you don't want to work there anyway unless
you
are pathologically uninterested in what the business of your enterprise is).
Assuming you aren't there then I think there is great value in Tim's approach
(though I'd relax the *requirement* to draw it all out but have the interview
in
a room with a whiteboard and pens) - generally I wouldn't want to hire a bad
communicator anyway but that's mostly my bias. But I also think you'll want at
least some of the things that want explaining to have direct relevance to the
tasks that you want them to do. That might include OCP style questions - but
the
best way to recruit someone who can answer OCP style questions is to require an
OCP. Usually when I say that people say something like "ah, but we found that
the OCP candidate couldn't do Task X, which we expect all Junior DBAs to do,
but
which isn't on the OCP curriculum". In that case of course asking about Task X
would probably have been more profitable.
One thing that I have used in the past, though for "senior" positions rather
than "junior" ones are Fermi problems. These are great at giving an idea as to
how, if at all, people are prepared to think and apply knowledge they do have
to
areas in which they have no direct knowledge. The classic example "How many
piano tuners are there in Chicago?" can easily be restated for example as "How
many DBAs are there in London". Incidentally the classic reasoning
(http://www.grc.nasa.gov/WWW/k-12/Numbers/Math/Mathematical_Thinking/fermis_piano_tuner.htm)
giving an answer of ~150 turns out to be pretty good
really
http://blog.wolframalpha.com/2010/09/28/how-many-piano-tuners-are-there-in-chicago/
.
So I'd probably say in summary
* decide what you want the person to actually do
* decide what role the interview plays in the process
* for "what do you know" type questions ask open ended "how would...
what
does... " type questions
* include specific questions if you have specific tasks in mind
* for "how do you think" type questions ask reasonable but somewhat off
the
wall questions.
* I have no idea at all how to pre-judge if someone will fit into a
team :( -
you likely really need an HR professional for this.
On Mon, Feb 7, 2011 at 1:52 PM, Stephane Faroult <sfaroult@xxxxxxxxxxxx> wrote:
I've read all posts so far in this thread; I really like Tim's approach
("explain to me how all this works"), although I agree there is some truth in
the argument that some good candidates may be too nervous or impressed or
simply
bad communicators and give an impression that doesn't truly reflect their
abilities. Although as Martijn pointed out, communication is key. I know a DBA
(not a junior one) who is quite competent but who, when meeting developers,
only
talks about cache buffer chain latches and scattered read events - someone is
always required for translating what he says into something that developers can
relate to their code. As far as issue solving is concerned, someone less
competent but who communicates better may be more useful.
>
>I think that your list looks too much like what I have seen of OCP questions
>and
>the like - where you are supposed to provide THE good answer (and I must admit
>that very often I have no idea of what kind of "good answer" is expected). I
>think it would be more to the point to confront candidates to some kind of
>practical situations, and ask them how they would solve them (and I think that
>they should be made aware from the start that "I call a senior DBA" is an
>option
>- it's important to know one's limits before you make things worse).
>
>To review your list, I think that rather than your first question I'd rather
>tell a story of much slower performances since an event (table used as a FIFO,
>reader process was down for x hours), and see whether the candidate comes to
>anything looking like a HWM issue. Even if he or she has a patchy knowledge of
>Oracle internals, seeing how a candidate thinks and diagnoses is interesting.
>Or
>something about chaining. And I would definitely give good marks to someone
>who
>would honestly tell me they don't know enough yet to diagnose.
>You often learn more about someone's abilities by their questions rather than
>their answers.
>
>For your question 2, I'd rather say "you need to create an account for Ms XX
>who
>needs to have the same privileges as her colleague Mr XY" - and see if roles
>come spontaneously on the table.
>
>For 3, I'd go for the "Cannot allocate extent in tablespace ..." and ask them
>what they would do. And so on.
>
>Backups are a bit special. But you can ask them to discuss hot and cold
>backup,
>what you can hope to recover in such or such case and so on.
>
>But as others have said, it's more the appetite to learn and the readiness to
>search the docs that count ...
>
>My € 0.02.
>
>
>Stephane Faroult
>RoughSea Ltd
>Konagora
>RoughSea Channel on Youtube
>
>
>On 02/07/2011 12:06 AM, Guillermo Alan Bort wrote:
>So, I am in the process of reviewing resumes from several JR and SSR
>candidates
>for the team. The question I came up with is, what kind of questions
>(technical)
>should I ask during the interview. I can't use the same questions I'd use with
>a
>Sr. DBA.
>
>>
>>The questions i've come up with so far are the following:
>>1. Difference between EXTENT and BLOCK
>>2. Difference between USER and ROLE. When would you use each?
>>3. Command to extend a Tablespace (tricky question? should it be datafile?)
>>4. Command to backup controlfiles (all you can think of)
>>5. Steps to switch archivelog on or off.
>>6. Minimum requirements in order to take a level 1 online backup (tricky
>>question?)
>>7. What are the minimum required files to be backed up in order to be able to
>>recreate the database from scratch in the event of complete media failure?
>>
>>I may come up with more, but that's what I have so far...
>>
>>thanks in advance
>>Alan.-
>>
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
