Re: Interviewing experiences with novice interviewers

  • From: Subodh Deshpande <deshpande.subodh@xxxxxxxxx>
  • To: m.haddon@xxxxxxxxx
  • Date: Sat, 12 Mar 2011 14:26:28 +0530

thanks for sharing your experience..yes we are human and are bound to do
mistakes. A good team player can admit mistakes..Subodh


On 12 March 2011 13:44, Mike Haddon <m.haddon@xxxxxxxxx> wrote:

>
> Mark, and others.
>
> I have been following this thread with some interest because it is a
> subject which I have some experience on both sides. I feel that most people
> put too much into this subject.
>
> In my experiences as the person being interviewed I look forward to an
> interview where the questions are technical but put into the context of a
> situation that is indicative of a production or development environment. I
> often ask the interviewer to put their question into that context. This
> gives me a good idea of the interviewer's understanding of the question
> itself and tells me if he/she looked it up or if they will understand the
> answer. I also understand the importance of "knowing what I don't know" and
> if I don't know I will indicate the resources I would use to find the answer
> and I will also often ask the interviewer to answer the question
> himself/herself.
>
> As the interviewer, I will usually spend the first 5-10 minutes getting to
> know the person. Part of the criteria has to be whether the person will bond
> with the team or not. Then I will put my questions in specific context, I.E.
> "You receive a call from one of the application support team, he/she says
> that the system is slow, what do you do?". In my experience this is very
> common. I listen to their explanation of the process to isolate the issue
> and sometimes give them direction, for example, if they indicate the use of
> iostat, vmstat, top, ps, or some other method of isolating top sessions,
> tell them "OK you find a process taking all the CPU, what next". It is this
> experience that will tell you how deep the person really is.
>
> I know a lot of DBA's that are very very smart technically but get
> frustrated and lost when it really counts and they have 7 people standing
> behind them when the production environment is having issues.
>
> I would want someone with a good understanding of the architecture and the
> database, but I also want someone who is always ready to learn something
> new, knows what he/she doesn't know, willing to ask questions of the team,
> willing to take on a challenge, and honest when they may make a mistake.
>
> As a perfect example, in my past life I managed a team of production
> support db admins, system admins, and network admins. When hired, each
> person was given direction on the to do's and not to do's. One day, a system
> admin came into the office to explain that he violated one of these rules
> and corrupted the shadow file on all of our database servers. These servers
> were all over the globe from Germany to Toronto to London and Denver. We
> gathered the team, I explained the situation to the VP and we spent the next
> several hours correcting the situation. The next day he came into the office
> and stated he was ready for whatever action I thought was warranted.
>
> To make my point I explained to him that I would not take additional action
> because of two reasons. First, he came to me and the rest of the team when
> he made the mistake and didn't try to hide it. Second, I knew he would never
> make that mistake again. The rest of the team came together and we resolved
> the issue with little to no effect on the servers. This admin turned out to
> be one of the best on our team and always to supported anyone else on the
> team.
>
> I may have gone way off topic but the point is that it is the person, their
> ability to learn, and their understanding of what they don't know that is
> sometimes most important to determine during the interview process.
>
> Mike
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>


-- 
==============================
DO NOT FORGET TO SMILE TODAY
==============================

Other related posts: