在邮件列表看到个挺有意思的主题，关于求职者，面试管和面试流程

xhellfire

Forwarded conversation
Subject: Interviewing experiences with novice interviewers
------------------------

From: Imtiaz Merchant <merchanti@hotmail.com>
Date: Fri, Mar 11, 2011 at 23:58
To: oracle-l@freelists.org


Hello Group,

Just wondering if any of you have had experience interviewing with novice interviewers who manage to get canned DBA questions and answers off the net for interviewing experienced professionals?  These people judge you, not by your answers, but whether your answer matches the answer they have obtained from the net.

How do you deal with these situations?

- Imtiaz

----------
From: Paul Barrett <tinojam@gmail.com>
Date: Sat, Mar 12, 2011 at 00:32
To: merchanti@hotmail.com
Cc: oracle-l@freelists.org


If you find yourself in this situation, use buzz words - short answer.

----------
From: Martin Klier <usn@usn-it.de>
Date: Sat, Mar 12, 2011 at 00:46
To: merchanti@hotmail.com
Cc: oracle-l@freelists.org


Another cool strategy: Ask back when possible. Many situations allow the
experienced DBA to say "How is this parameter set on the assumed
machine" or "what is the last ORA error in the assumed logfile". Did
this in the past, with great success - with experienced and unexperieced
interviewers. If you do it right, both kinds can be impressed. If you do
it wrong, yu are the fool. :)

Imtiaz Merchant schrieb:
Regards
Usn
--
Usn's IT Blog for Linux, Oracle, Asterisk
http://www.usn-it.de

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



----------
From: Guillermo Alan Bort <cicciuxdba@gmail.com>
Date: Sat, Mar 12, 2011 at 01:39
To: usn@usn-it.de
Cc: merchanti@hotmail.com, oracle-l@freelists.org


A good read, if only for a laugh: http://blogs.msdn.com/b/ericlipp ... uld-feynman-do.aspx

Well, generally speaking, if a non-dba interviews a prospective DBA it means that there probably isn't a qualified DBA to ask the questions or that they are 'much too busy'. Either situation doesn't seem like an Idea working environment. I would instead ask to meet with the DBA team to see if they are worth working with. From personal experience, the technical interview in very large companies usually means very little. When I interviewed for IBM I answered every question correctly and included all the usual stuff they like (documentation, communication, processes, etc) They still told me I was a Semi-SR. I took the job anyway (the pay was better and I needed the money at the time) and later became friends with the guy that interviewed me and he told me that his boss had ordered him to never say anyone was 'Sr'. The reasons behind that are unimportant, but I was a little annoyed when I found out that I was earning the same as people who couldn't deal with a simple database restore... (One of the many reasons I left IBM for...)

I guess my answer is that you should probably ask yourself if that's really the company you want to work for (assuming you have the luxury of turning down a job).

Now as to ways to handle the interviewers, if they come out and tell you that they are not Oracle experts, then ask whether you will be given a technical interview by a DBA, and try to use short answers, don't be afraid to throw in some technical term or shorthand DBAs may use and ask if they'd like you to explain the concepts to them as you introduce them. Avoid any areas you may have trouble with... and throw in some buzz word now and again. (24x7, High Availability, reliability, performance, documentation).

hth
Alan.-

----------
From: mark teehan <teehan2020@gmail.com>
Date: Sat, Mar 12, 2011 at 14:55
To: oracle-l@freelists.org



Slightly off topic, but I am interested in interview technique.

Neither the candidate nor the interviewer wants to waste time and a structured, planned interview is one way to best ensure this.

Apart from a chatty preamble, I ask candidates the same questions and compare them on the answers to questions that they knew, answers to questions that they got wrong, and response to questions that they don't know.
I explain this to candidates up front, and tell them not to be disheartened if the questions appear unfair.

This is partly a response to increasing number of phone interviews where candidates have prepped answers to common technical questions (and are googling with Cone of Silence over the keyboard :-) )

The questions are intentionally increasingly obscure to push into i-dont-know territory. I like an explanation of the system       statistic transaction rollbacks for instance, enq: TM - contention, things like that.
Once there, you get a better idea of how someone deals with pressure and how well someone acknowledges that they don't know something; but know how to find out.

I judge the third ("I dont know, but....") most seriously; the breadth of what an oracle professional now deals with is huge, and I am very dubious of anyone that claims subject matter expertise on the entire product.

I also dislike technical jargon and any language that attempts to obscure clear meaning: whenever I hear the word "solution" I ask them to describe it using any other word.

Attempting to bounce technical questions back at an interviewer is counter-productive I think. Iit is not necessary for an interviewer to have more expertise on a topic in order to judge the quality of your response, both immediately and in retrospect while comparing with other candidates responses. If the interviewer does not appear to be recording your responses seriously then I'd feel free not to take them seriously either.








----------
From: Mike Haddon <m.haddon@tx.rr.com>
Date: Sat, Mar 12, 2011 at 16:14
To:
Cc: oracle-l@freelists.org



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

----------
From: Subodh Deshpande <deshpande.subodh@gmail.com>
Date: Sat, Mar 12, 2011 at 16:56
To: m.haddon@tx.rr.com
Cc: oracle-l@freelists.org


thanks for sharing your experience..yes we are human and are bound to do mistakes. A good team player can admit mistakes..Subodh
--
==============================
DO NOT FORGET TO SMILE TODAY
==============================