Re: Questions for a Jr. DBA
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: sfaroult@xxxxxxxxxxxx
- Date: Mon, 7 Feb 2011 14:31:05 +0000
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 <http://www.roughsea.com>
> Konagora <http://www.konagora.com>
> RoughSea Channel on Youtube <http://www.youtube.com/user/roughsealtd>
>
> 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:
